Pourquoi existe-t-il encore un type de données varchar?

Beaucoup de mes bases de données ont des champs définis comme varchars. Cela n’a pas posé beaucoup de problèmes depuis que je vis et travaille en Amérique (où le seul langage qui existe est "américain". Ahem )

Après avoir travaillé avec des bases de données pendant environ 5 ans, j'ai finalement rencontré des problèmes avec la nature limitée du champ varchar et je devais modifier mes champs pour stocker des données en tant que nvarchars. Après avoir dû effectuer une autre mise à jour dans une table, en convertissant un champ varchar en un nvarchar, je viens juste de penser - pourquoi le faisons-nous toujours de cette manière? J'ai depuis longtemps pris la décision mentale de définir tous mes nouveaux champs de texte dans nvarchar, au lieu de varchar, ce que j'ai appris à faire avec mes manuels lorsque j'étais à l'école il y a 10 ans.

Nous sommes en 2011 et une nouvelle version de SQL Server est disponible l'année dernière. Pourquoi continuons-nous à prendre en charge un type de données varchar alors que nous pouvons / devrions utiliser nvarchar?

Je sais que l'on dit souvent que nvarchars est "deux fois plus grand" que varchars, de sorte que l'utilisation de l'espace de stockage pourrait être un argument pour maintenir des varcars.

Cependant, les utilisateurs d'aujourd'hui pourraient définir leur nvarchars pour stocker les données au format UTF-8 au lieu du format UTF-16 par défaut s'ils souhaitent économiser de l'espace de stockage. Cela permettrait un codage sur 8 bits si cela est principalement souhaitable, tout en garantissant que le caractère rare composé de 2 à 8 octets inséré dans leur base de données ne casse rien.

Est-ce que je manque quelque chose? Y a-t-il une bonne raison pour que cela n'ait pas changé au cours des 15 à 20 dernières années?

1. Le travail varchar est suffisant pour de nombreuses langues d'Europe occidentale (norvégien, danois, allemand, français, néerlandais, etc.), sous réserve de quelques problèmes de classement

2. Voir ceci sur SO varchar vs performance nvarchar nvarchar a de graves conséquences sur les performances

3. Ceci est trivial par rapport au traitement des dates MDY vs DMY

Outre les réponses aux normes et à la compatibilité, il convient de garder à l’esprit les performances. Bien que l’espace disque soit facilement accepté comme peu coûteux, les administrateurs de base de données / développeurs ignorent souvent que les performances des requêtes sont parfois directement liées à la taille des lignes / pages d’un tableau. Utiliser NVARCHARplutôt que VARCHAR(lorsque cela n'est pas nécessaire) doublera effectivement la taille de la ligne pour vos champs de caractères. Si vous avez, par exemple, 5 ou 10 50 champs de longueur, vous parlez d'ajouter éventuellement 500 octets supplémentaires par ligne. Si vous avez une table large, cela pourrait pousser chaque ligne sur plusieurs pages et avoir un effet négatif sur les performances.

De nombreuses organisations disposent toujours d’une base d’applications, d’interfaces, de plates-formes et d’outils reposant sur des caractères codés sur un octet. Les bases de données vivent rarement isolément - elles font partie d'un écosystème informatique. Si vous avez des milliers de composants et des millions de lignes de code dépendant de caractères à un octet, vous avez besoin d'une bonne raison pour investir le temps et l'argent nécessaires pour passer à l'unicode. Des changements de cette ampleur pourraient prendre des années. À certains endroits, Unicode est encore relativement nouveau, rare ou pas complètement pris en charge.

VARCHAR et NVARCHAR font tous deux partie de la norme ISO Standard SQL. La suppression ou la dépréciation de la prise en charge de VARCHAR dans SQL Server constituerait un retour en arrière en termes de compatibilité et de portabilité.

Autrement, les utilisateurs actuels pourraient définir leur nvarchars pour stocker les données au format UTF-8 au lieu du format UTF-16 par défaut s'ils souhaitent économiser de l'espace de stockage.

C'est exactement ce que font la plupart des bases de données open-source VARCHAR.

• MySQL fournit utf8et ucs2« du classement ».
• SQLite vous donne le choix entre UTF-8 (valeur par défaut) et UTF-16.
• PostgreSQL supporte UTF-8 (mais pas UTF-16).

Pas besoin d'avoir deux types de chaîne distincts.

Microsoft est l'intrus avec son point de vue que les chaînes de 8 bits sont pour les encodages hérités et Unicode = UTF-16. Ce qui est probablement lié à l'API Windows lui - même le traitement charet de wchar_tcette façon.

Certains d'entre nous construisant des applications plus petites et plus légères sur un matériel moins sophistiqué qui ne nécessite pas de fonctionnalités Unicode. Peut-être devrons-nous le changer plus tard, mais pour l'instant, nous n'en avons tout simplement pas besoin. J'aime que mes chaînes prennent la moitié de l'espace qu'elles devraient sous NVARCHAR.