Est-ce que VARCHAR ressemble totalement aux années 1990?

Question

1. VARCHAR ne stocke pas les caractères Unicode.
2. NVARCHAR ne stocker des caractères Unicode.
3. Aujourd'hui, les applications doivent toujours être compatibles Unicode.
4. NVARCHAR prend deux fois le montant de l'espace pour le stocker.
5. Le Point 4 n'a pas d'importance parce que l'espace de stockage est extrêmement bon marché.

Ergo: Lors de la conception de bases de données SQL Server aujourd'hui, on devrait toujours utiliser le type de données NVARCHAR.

Est-ce son raisonnement? Est-ce quelqu'un en désaccord avec les locaux? Existe-il des raisons de choisir le type VARCHAR sur NVARCHAR aujourd'hui?

Answer 1

Vous faites correspondre le type de données avec les données qui seront stockées dans la colonne. Par un argument similaire, vous pouvez dire pourquoi ne pas stocker toutes les données dans des colonnes NVARCHAR, car les nombres et les dates peuvent être représentés sous forme de chaînes de chiffres.

Si la meilleure correspondance pour les données qui seront stockées dans la colonne est VARCHAR, utilisez-la.

Answer 2

Le point 4 n'a pas d'importance car l'espace de stockage est extrêmement peu coûteux.

ce n'est pas seulement du stockage, mais de la bande passante - cpu, mémoire, sauvegarde, restauration, transfert. Conserver.

Answer 3

Je dirais qu'il y a toujours des raisons valables de ne pas utiliser de type nvarchar.

• L'espace de stockage est à une prime, comme sur un partage de l'hôte ou de la base de données est vraiment énorme.
• La Performance est critique.
• Réaménagement des sites urbains contaminés (c'est à dire la base de données les tables existantes qui utilisent varchar).
• L'intégration avec un autre ancien système qui ne connaît qu'un octet et/ou varchar.

Toutefois nouveau développement doit probablement utiliser nvarchar esp. depuis les systèmes 64 bits sont en train de devenir la norme. Aussi, les entreprises (même les petits) sont maintenant plus couramment mondiale.

Answer 4

Vous devez choisir le type VARCHAR sur NVARCHAR pour de nombreux types de colonnes, et le choix serait, colonne par colonne.

Typique des colonnes qui ne nécessiterait pas une charge supplémentaire de type NVARCHAR engage serait:

ID colonnes de type: plaques d'immatriculation, SSNs, Patient identifiants etc.

Code colonnes: International les codes des monnaies (USD, UKP, etc.), ISO des codes de pays (US, UK, etc), des codes de Langue (fr-us, etc), la comptabilité de segment de codes, etc

Le code Postal et le code postal de colonnes.

Answer 5

Je pense que la comparaison de nvarchars est plus coûteuse que varchars. Elle est donc parfaitement valide et même préférée dans les endroits où vous n’avez vraiment pas besoin de fonctionnalités Unicode, c’est-à-dire pour certains ID internes.

Et le coût de stockage est toujours important . Si vous avez des milliards de lignes, ces "petites" différences deviennent vite grandes.