A diferencia de otros RDBMS que permiten elegir una codificación, SQL Server almacena datos Unicode solo en UTF-16 (Little Endian) y datos no Unicode en una codificación de 8 bits (ASCII extendido, DBCS o EBCDIC) para cualquier página de códigos implícita en la intercalación del campo.
Su decisión de elegir UCS-2 tiene bastante sentido dado que UTF-16 se introdujo a mediados de 1996 y se especificó por completo en 2000. Muchos otros sistemas también lo usan (o lo usaron) (consulte:https://en.wikipedia.org/wiki/UTF-16#Uso ). Su decisión de continuar con él podría ser más cuestionable, aunque probablemente se deba a que Windows y .NET son UTF-16. El diseño físico de los bytes es el mismo entre UCS-2 y UTF-16, por lo que actualizar los sistemas de UCS-2 para admitir UTF-16 debería ser puramente funcional sin necesidad de modificar ningún dato existente.
Mmm no. Crear un tipo personalizado definido por el usuario a través de SQLCLR no , de ninguna manera, te va a conseguir un reemplazo de cualquier tipo nativo. Es muy útil para crear algo que maneje datos especializados. Pero las cadenas, incluso con una codificación diferente, están lejos de ser especializadas. Seguir esta ruta para sus datos de cadena destruiría cualquier cantidad de usabilidad de su sistema, sin mencionar el rendimiento, ya que no podría usar ninguna funciones de cadena incorporadas. Si pudiera ahorrar algo en el espacio del disco, esas ganancias se borrarían por lo que perdería en el rendimiento general. El almacenamiento de un UDT se realiza serializándolo en un VARBINARY . Entonces, para hacer cualquier comparación de cadenas O clasificación, fuera de una comparación "binaria" / "ordinal", tendría que convertir todos los demás valores, uno por uno, nuevamente a UTF-8 para luego hacer la comparación de cadenas que puede dar cuenta de las diferencias lingüísticas.
Además, esa "documentación" es realmente solo código de muestra/prueba de concepto. El código fue escrito en 2003 ( http://msftengprodsamples.codeplex.com/SourceControl/latest#Kilimanjaro_Trunk/Programmability/CLR/UTF8String/CS/UTF8String/Utf8String.cs ) para SQL Server 2005. Vi un script para probar la funcionalidad, pero nada relacionado con el rendimiento.
Sí mucho así. De forma predeterminada, el manejo de las funciones integradas es solo para UCS-2. Pero a partir de SQL Server 2012, puede hacer que manejen el juego de caracteres UTF-16 completo (bueno, a partir de la versión 5 o 6 de Unicode, según su sistema operativo y la versión de .NET Framework) mediante una de las intercalaciones que tiene un nombre que termina en _SC (es decir, caracteres complementarios).
Correcto. UTF-16 y UCS-2 usan puntos de código de 2 bytes. Pero UTF-16 usa algunos de ellos en pares (es decir, pares sustitutos) para mapear caracteres adicionales. Los puntos de código usados para estos pares están reservados para este propósito en UCS-2 y, por lo tanto, no se usan para mapear a ningún símbolo utilizable. Es por eso que puede almacenar cualquier carácter Unicode en SQL Server y se almacenará y recuperará correctamente.
Correcto, aunque engañoso. Sí, UTF-8 es de ancho variable, pero UTF-16 también es ligeramente variable, ya que todos los caracteres complementarios se componen de dos puntos de código de doble byte. Por lo tanto, UTF-16 usa 2 o 4 bytes por símbolo, aunque UCS-2 siempre tiene 2 bytes. Pero esa no es la parte engañosa. Lo que es engañoso es la implicación de que cualquier otra codificación Unicode no es capaz de codificar todos los demás puntos de código. Si bien UCS-2 puede contenerlos pero no interpretarlos, tanto UTF-16 como UTF-32 pueden mapear todos los puntos de código Unicode, al igual que UTF-8.
Esto puede ser cierto, pero es completamente irrelevante desde una perspectiva operativa.
De nuevo, cierto, pero completamente irrelevante ya que UTF-16 y UTF-32 también mapean todos los puntos de código Unicode.
Dependiendo de las circunstancias, esto podría muy bien ser cierto, y tiene razón al preocuparse por ese uso derrochador. Sin embargo, como mencioné en la pregunta que condujo a esta ( Compatibilidad con UTF-8, SQL Server 2012 y UTF8String UDT
), tiene algunas opciones para mitigar la cantidad de espacio desperdiciado si la mayoría de las filas caben en VARCHAR sin embargo, algunos deben ser NVARCHAR . La mejor opción es habilitar la COMPRESIÓN DE FILAS o LA COMPRESIÓN DE PÁGINAS (¡solo Enterprise Editon!). A partir de SQL Server 2008 R2, permiten NVARCHAR no MAX campos para utilizar el "Esquema de compresión estándar para Unicode", que es al menos tan bueno como UTF-8 y, en algunos casos, es incluso mejor que UTF-8. NVARCHAR(MAX) los campos no pueden usar esta elegante compresión , pero sus datos IN ROW pueden beneficiarse de la compresión regular de ROW y/o PAGE. Consulte lo siguiente para obtener una descripción de esta compresión y un gráfico que compara los tamaños de datos para:UCS-2/UTF-16 sin procesar, UTF-8 y UCS-2/UTF-16 con compresión de datos habilitada.
SQL Server 2008 R2 - Compresión UCS2 qué es - Impacto en los sistemas SAP
Consulte también la página de MSDN para Compresión de datos para obtener más detalles, ya que existen algunas restricciones (además de estar disponible solo en Enterprise Edition, PERO disponible para todos) ediciones a partir de SQL Server 2016, SP1 !!) y algunas circunstancias en las que la compresión podría empeorar las cosas.
La veracidad de esa afirmación depende de cómo se defina "disco". Si está hablando en términos de piezas de productos básicos que puede comprar en el estante en una tienda para usar en su computadora de escritorio / computadora portátil, entonces seguro. Pero, si habla en términos de almacenamiento de nivel empresarial que se usará para sus sistemas de producción, diviértase explicando a quienquiera que controle el presupuesto que no debe rechazar la SAN de más de un millón de dólares que desea porque es "barata". ";-).
Ninguno que se me ocurra. Bueno, siempre y cuando no siga ningún consejo horrible para hacer algo como implementar ese UDT o convertir todas las cadenas a VARBINARY , o usando NVARCHAR(MAX) para todos los campos de cadena;-). Pero de todas las cosas por las que podría preocuparse, SQL Server que usa UCS-2/UTF-16 no debería ser una de ellas.
Pero, si por alguna razón este problema de la falta de soporte nativo para UTF-8 es muy importante, es posible que deba encontrar otro RDBMS para usar que permita UTF-8.
ACTUALIZACIÓN 2018-10-02
Si bien esta aún no es una opción viable, SQL Server 2019 presenta soporte nativo para UTF-8 en VARCHAR / CHAR tipos de datos. Actualmente hay demasiados errores para usarlo, pero si se solucionan, entonces esta es una opción para algunos. escenarios. Consulte mi publicación, "Compatibilidad nativa con UTF-8 en SQL Server 2019:¿salvador o falso profeta?
", para un análisis detallado de esta nueva función.
