separar - split sql server

¿Cómo debo almacenar cadenas cortas de texto en una base de datos SQL Server? (8)

varchar (255), varchar (256), nvarchar (255), nvarchar (256), nvarchar (max), etc.?

256 parece un número agradable, redondo, eficiente en el uso del espacio. Pero he visto que 255 usó mucho. ¿Por qué?

¿Cuál es la diferencia entre varchar y nvarchar?

Debido a que hay 8 bits en 1 byte y así en 1 byte puede almacenar hasta 256 valores distintos que es

0 1 2 3 4 5 ... 255

Tenga en cuenta que el primer número es 0, por lo que hay un total de 256 números.

Entonces, si usas nvarchar (255) usará 1 byte para almacenar la longitud de la cadena, pero si lo vuelves a dar 1 y usas nvarchar (256), estás desperdiciando 1 byte adicional solo para ese artículo extra 1 de 255 (ya que necesita 2 bytes para almacenar el número 256 ).

Esa podría no ser la implementación real del servidor SQL, pero creo que ese es el razonamiento típico para limitar las cosas en 255 más de 256 elementos.

y nvarchar es para Unicode, que usa 2+ bytes por carácter y
varchar es para texto ASCII normal que solo usa 1 byte

En MS SQL Server (7.0 y superior), los datos varchar se representan internamente con hasta tres valores:

La cadena real de caracteres, que será de 0 a algo más de 8000 bytes (se basa en el tamaño de página, las otras columnas almacenadas para la fila y algunos otros factores)
Dos bytes utilizados para indicar la longitud de la cadena de datos (que produce un valor de 0 a 8000+)
Si la columna es anulable, un bit en la máscara de bits nula de la fila (para que el estado nulo de hasta ocho columnas con nulos pueda representarse en un byte)

La parte importante es ese indicador de longitud de datos de dos bytes. Si fue un byte, solo puede grabar cadenas de longitud de 0 a 255; con dos bytes, puede grabar cadenas de longitud 0 en algo superior a 64000+ (específicamente, 2 ^ 16 -1). Sin embargo, la longitud de la página del Servidor SQL es 8k, que es de donde proviene ese límite de más de 8000 caracteres. (Hay elementos de desbordamiento de datos en SQL 2005, pero si sus cadenas van a ser tan largas, debería ir con varchar (max)).

Entonces, no importa cuánto tiempo declare que su columna de tipo de datos varchar es (15, 127, 511), lo que en realidad va a almacenar para cada fila es:

2 bytes para indicar cuánto tiempo es la cadena
La cadena real, es decir, el número de caracteres en esa cadena

Lo que me lleva a mi punto: varios sistemas antiguos usaban solo 1 byte para almacenar la longitud de la cadena, y eso te limitaba a una longitud máxima de 255 caracteres, que no es tan larga. Con 2 bytes, no tiene ese límite arbitrario ... por lo que recomiendo elegir un número que tenga sentido para el usuario (supuestamente no orientado técnicamente). , Me gustan 50, 100, 250, 500, incluso 1000. Dado que la base de 8000+ bytes de almacenamiento, 255 o 256 es tan eficiente como 200 o 250, y menos eficiente cuando llega el momento de explicar las cosas a los usuarios finales .

Esto se aplica a datos de un solo byte (es decir, ansii, SQL _ Latin1 * _ * General_CP1, et al.). Si tiene que almacenar datos para múltiples páginas de códigos o idiomas usando diferentes alfabetos, necesitará trabajar con el tipo de datos nvarchar (que creo que funciona igual, dos bytes para el número de caracteres, pero cada carácter real de datos requiere dos bytes de almacenamiento). Si tiene cadenas que probablemente superen los 8000, o más de 4000 en nvarchar, necesitará usar los tipos de datos [n] varchar (max).

Y si quiere saber por qué es tan importante ocupar espacio con bytes adicionales solo para rastrear cuánto tiempo son los datos, visite http://www.joelonsoftware.com/articles/fog0000000319.html

Felipe

Hay otros puntos a considerar al definir char / varchar y las N variaciones.

En primer lugar, existe cierta sobrecarga para almacenar cadenas de longitud variable en la base de datos. Una buena regla general es usar CHAR para cadenas de menos de 10 caracteres de longitud, ya que N / VARCHAR almacena tanto la cadena como la longitud y la diferencia entre almacenar cadenas cortas en N / CHAR vs. N / VARCHAR en 10 no es vale la pena la sobrecarga de la longitud de la cuerda.

En segundo lugar, una tabla en el servidor SQL se almacena en páginas de 8KB, por lo que el tamaño máximo de la fila de datos es de 8060 bytes (los otros 192 se usan para sobrecarga por SQL). Es por eso que SQL permite una columna máxima definida de VARCHAR (8000) y NVARCHAR (4000). Ahora puede usar VARCHAR (MAX) y la versión Unicode. Pero puede haber una sobrecarga adicional asociada con eso.

Si no me equivoco, el servidor SQL intentará almacenar los datos en la misma página que el resto de la fila pero, si intenta poner demasiados datos en una columna VARCHAR (Máx), lo tratará como binario y almacenarlo en otra página.

Otra gran diferencia entre CHAR y VARCHAR tiene que ver con las divisiones de página. Dado que SQL Server almacena datos en páginas de 8KB, puede tener cualquier cantidad de filas de datos almacenados en una página. Si ACTUALIZA una columna VARCHAR con un valor lo suficientemente grande como para que la fila ya no quepa en la página, el servidor dividirá esa página, eliminando algunos registros. Si la base de datos no tiene páginas disponibles y la base de datos está configurada para crecer automáticamente, el servidor hará crecer primero la base de datos para asignarle páginas en blanco, luego asignará páginas en blanco a la tabla y finalmente dividirá la página en dos.

IIRC, 255 es el tamaño máximo de un varchar en MySQL antes de que tuviera que cambiar al tipo de datos de texto, o fue en algún momento (en realidad, creo que es más alto ahora). Así que mantenerlo en 255 podría comprarle algo de compatibilidad allí. Sin embargo, querrá buscar esto antes de actuar sobre él.

varchar vs nvarchar es algo así como ascii vs unicode. varchar está limitado a un byte por carácter, nvarchar puede usar dos. Es por eso que puedes tener un varchar (8000) pero solo un nvarchar (4000)

Si va a admitir idiomas que no sean inglés, querrá usar nvarchar.

HTML debe estar bien siempre que contenga caracteres ASCII estándar. He usado nvarchar principalmente en bases de datos que son compatibles con varios idiomas.

Tanto el varchar como el nvarchar son de tamaño automático para el contenido, pero el número que define al declarar el tipo de columna es un máximo.

Los valores en "nvarchar" ocupan el doble del espacio de disco / memoria como "varchar" porque el unicode es de dos bytes, pero cuando declaras el tipo de columna, declaras el número de caracteres, no los bytes.

Por lo tanto, cuando define un tipo de columna, debe determinar el número máximo de caracteres que la columna necesitará contener y tenerlos como el tamaño varchar (o nvarchar).

Una buena regla es estimar la longitud máxima de aguijón que la columna necesita contener, luego agregue soporte para aproximadamente 10% más de caracteres para evitar problemas con datos inesperadamente largos en el futuro.

VARCHAR (255). No usará los 255 caracteres de almacenamiento, solo el almacenamiento que necesita. Es 255 y no 256 porque entonces tienes espacio para 255 más el terminador nulo (o byte de tamaño).

La "N" es para Unicode. Úselo si espera caracteres que no sean ASCII.

varchar (255) también fue la longitud máxima en SQL Server 7.0 y versiones anteriores.