A partir de SQL Server 2019 (actualmente en versión beta / "Community Tech Preview"), hay soporte nativo para UTF-8 a través de una nueva serie de colaciones UTF-8. SIN EMBARGO, tener la capacidad de usar UTF-8 no significa que debas hacerlo. Existen inconvenientes definitivos para usar UTF-8, tales como:
- Solo los primeros 128 puntos de código son de 1 byte (es decir, el conjunto ASCII estándar de 7 bits)
- Los siguientes casi 2000 puntos de código son de 2 bytes, por lo tanto, no hay ahorro de espacio con UTF-16
NVARCHAR
- Los restantes 63k puntos de código en el BMP (es decir, el rango U + 0800 - U + FFFF) son todos 3 bytes, por lo tanto, 1 byte más grande que el mismo carácter en UTF-16 /
NVARCHAR
.
- Solo dígalo: los caracteres suplementarios son de 4 bytes en ambas codificaciones, por lo que no hay diferencia de espacio allí
- Si bien es posible que ahorre espacio con UTF-8, existe una gran probabilidad de que tenga un impacto en el rendimiento al hacerlo.
Lo que realmente se reduce a esto es: UTF-8 es un diseño de formato de almacenamiento para permitir que los sistemas de 8 bits (que generalmente se diseñaron alrededor de ASCII y ASCII Extended - Páginas de códigos) utilicen Unicode sin romper nada ni requerir ninguna modificación de los existentes. archivos para mantener las cosas funcionando. UTF-8 es maravilloso para sistemas de archivos y redes, pero los datos almacenados dentro de SQL Server tampoco lo son. El hecho de que los datos que se encuentran mayormente (o completamente) dentro del rango ASCII estándar requiere menos espacio que los mismos datos cuando se almacenan como UTF-16 / NVARCHAR
es un efecto secundario. Claro, es un efecto secundario que puede resultar útil, pero esa decisión debe ser tomada por alguien que entienda tanto los datos como las consecuencias / inconvenientes de esta decisión. Esto esNo es una característica de uso general.
Además, el caso de uso principal para UTF-8 (en SQL Server) es para el código de la aplicación que ya usa UTF-8, posiblemente ya con otro RDBMS que lo admita, y no existe el deseo o la capacidad de actualizar el código de la aplicación / esquema de DB para usar NVARCHAR
tipos de datos (para tablas, variables, parámetros, etc.) o para prefijar literales de cadena con una "N" mayúscula. El objetivo es el mismo que el motivo de la existencia de UTF-8: habilitar el código de la aplicación para usar Unicode sin cambiar la estructura general o hacer que los datos existentes no sean válidos. Si esto describe su situación, use UTF-8, pero tenga en cuenta que todavía hay algunos errores / problemas con él.
Si no tiene una necesidad explícita de que Unicode funcione sin usar NVARCHAR
o literales de cadena con el prefijo "N" en mayúsculas, entonces el único otro escenario donde UTF-8 es un beneficio es si tiene MUCHOS datos ASCII en su mayoría estándar que deben permitir Caracteres Unicode, y está utilizando NVARCHAR(MAX)
(lo que significa que la compresión de datos no funcionará), y la tabla se actualiza con frecuencia (por lo que el Índice de almacén de columnas en clúster probablemente no va a ayudar realmente).
Para más detalles, vea mi publicación:
Soporte nativo de UTF-8 en SQL Server 2019: ¿Salvador o falso profeta?