¿Por qué todavía hay un tipo de datos varchar?

Muchas de mis bases de datos tienen campos definidos como varchars. Esto no ha sido un gran problema desde que vivo y trabajo en Estados Unidos (donde el único idioma que existe es "americano". Ejem )

Después de trabajar con bases de datos durante aproximadamente 5 años, descubrí que eventualmente me encuentro con problemas con la naturaleza limitada del campo varchar y tengo que modificar mis campos para almacenar datos como nvarchars. Después de tener que realizar otra actualización en una tabla, convirtiendo un campo varchar en un nvarchar, simplemente pensé: ¿por qué seguimos haciéndolo de esta manera? Hace mucho tiempo que tomé la decisión mental de definir todos mis nuevos campos de texto a nvarchar, en lugar de varchar, que es lo que aprendí de mis libros de texto cuando estaba en la escuela hace 10 años.

Es 2011 y hubo una nueva versión de SQL Server el año pasado. ¿Por qué seguimos admitiendo un tipo de datos varchar cuando podemos / deberíamos usar nvarchar?

Sé que a menudo se argumenta que los nvarchars son "dos veces más grandes" que los varchars, por lo que el uso del espacio de almacenamiento podría ser un argumento para mantener los varcars.

Sin embargo, los usuarios de hoy podrían definir sus nvarchars para almacenar los datos como UTF-8 en lugar del UTF-16 predeterminado si quieren ahorrar espacio de almacenamiento. Esto permitiría la codificación de 8 bits si eso es principalmente deseable, al tiempo que garantiza que el carácter raro de 2-8 bytes que se inserta en su base de datos no rompería nada.

¿Me estoy perdiendo de algo? ¿Hay una buena razón por la cual esto no ha cambiado en los últimos 15-20 años?

1. el trabajo varchar es lo suficientemente bueno para muchos idiomas de Europa occidental (noruego, danés, alemán, francés, holandés, etc.) sujeto a algunos problemas de colación

2. Vea esto en SO varchar vs rendimiento de nvarchar nvarchar tiene serias implicaciones de rendimiento

3. Esto es trivial en comparación con tratar con fechas MDY vs DMY

Además de las respuestas que abordan los estándares y la compatibilidad, también se debe tener en cuenta el rendimiento. Si bien el espacio en disco se acepta fácilmente como barato, los DBA / Desarrolladores a menudo ignoran el hecho de que el rendimiento de la consulta a veces está directamente relacionado con el tamaño de fila / página de una tabla. Usar en NVARCHARlugar de VARCHAR(cuando sea innecesario) efectivamente duplicará el tamaño de la fila para los campos de tu personaje. Si tiene, por ejemplo, 5 o 10 campos de 50 de longitud, está hablando de agregar potencialmente 500 bytes adicionales por fila. Si tiene una tabla amplia, esto podría empujar cada fila en varias páginas y tener un efecto adverso en el rendimiento.

Muchas organizaciones todavía tienen una gran base instalada de aplicaciones, interfaces, plataformas y herramientas que adoptan caracteres de un solo byte. Las bases de datos rara vez viven aisladas: son una parte de un ecosistema de TI. Si tiene miles de componentes y millones de líneas de código que dependen de caracteres de un solo byte, necesitaría una buena razón para invertir el tiempo y el dinero necesarios para cambiar a Unicode. Los cambios en esa escala podrían tardar años en completarse. En algunos lugares, Unicode sigue siendo relativamente nuevo, raro o no totalmente compatible.

VARCHAR y NVARCHAR son parte de ISO Standard SQL. Eliminar o dejar de utilizar el soporte VARCHAR en SQL Server sería un paso atrás en compatibilidad y portabilidad.

Alternativamente, los usuarios de hoy podrían definir sus nvarchars para almacenar los datos como UTF-8 en lugar del UTF-16 predeterminado si quieren ahorrar espacio de almacenamiento.

Esto es exactamente lo que hacen la mayoría de las bases de datos de código abierto VARCHAR.

• MySQL proporciona utf8y ucs2"colaciones".
• SQLite le permite elegir entre UTF-8 (el valor predeterminado) y UTF-16.
• PostgreSQL admite UTF-8 (pero no UTF-16).

No es necesario tener dos tipos de cadena separados.

Microsoft es el extraño con su opinión de que las cadenas de 8 bits son para codificaciones heredadas y Unicode = UTF-16. Lo que probablemente esté relacionado con el tratamiento de la API de Windows chary de wchar_tesa manera.

Debido a que algunos de nosotros construimos aplicaciones más pequeñas y livianas en hardware menos avanzado que no necesitan capacidades Unicode. Tal vez necesitemos cambiarlo más tarde, pero por ahora, simplemente no lo necesitamos. Me gusta que mis cadenas ocupen la mitad del espacio que de lo contrario tendrían que tener en NVARCHAR.