varchar o nvarchar

Estoy almacenando nombre y apellido con hasta 30 caracteres cada uno. Cuál es mejor varchar o nvarchar .

He leído que nvarchar ocupa el doble de espacio en comparación con varchar y que el nvarchar se utiliza para la internationalization.

Entonces, ¿qué sugieres que use: nvarchar o varchar ?

También hágamelo saber sobre el performance de ambos. El performance de ambos es el mismo o difieren en el performance. Porque el espacio no es un gran problema. El problema es el performance.

Básicamente, nvarchar significa que puedes manejar muchos alfabetos, no solo inglés regular. Técnicamente, significa soporte unicode, no solo ANSI. Esto significa caracteres de doble ancho o aproximadamente el doble del espacio. En estos días, el espacio en el disco es tan económico que podría usar nvarchar desde el principio en lugar de pasar por el dolor de tener que cambiar durante la vida de un producto.

Si estás seguro de que solo necesitarás admitir un idioma, puedes seguir con varchar, de lo contrario, me iría con nvarchar.

Esto ha sido discutido en SO antes de aquí .

EDITADO: cambió ascii a ANSI como se indica en el comentario.

En primer lugar, para aclarar, nvarchar almacena datos unicode mientras que varchar almacena datos ANSI (8 bits). Funcionan de manera idéntica, pero el nvarchar ocupa el doble de espacio.

En general, prefiero almacenar nombres de usuario utilizando varchar datatypes a less que esos nombres tengan caracteres que caigan fuera del límite de los caracteres que varchar puede almacenar.

También depende de la intercalación de la database también. Por ejemplo, no podrá almacenar caracteres rusos en un campo varchar , si la intercalación de la database es LATIN_CS_AS . Pero, si está trabajando en una aplicación local, que se usará solo en Rusia, establecería la intercalación de la database en ruso. Lo que hará es que le permitirá ingresar caracteres rusos en un campo varchar , ahorrando espacio.

Pero, actualmente, la mayoría de las aplicaciones que se están desarrollando son internacionales, por lo que tendrá que decidir qué usuarios se registrarán y, en function de eso, decidir el tipo de datos.

Tengo rojo que nvarchar toma dos veces como varchar.

Sí.

nvarchar se usa para la internationalization.

Sí.

¿Qué sugieres si utilizo nvarchar o varchar?

Depende de la aplicación.

Por defecto, vaya con nvarchar. Hay muy pocas razones para ir con varchar estos días, y todas las razones para ir con nvarchar (permite caracteres internacionales, como se discutió).

varchar es 1 byte por carácter, nvarchar tiene 2 bytes por caracter.

Utilizará más espacio con nvarchar, pero hay muchos más caracteres permitidos. El espacio extra es insignificante, pero es posible que te pierdas esos personajes adicionales en el futuro. Incluso si no espera requerir la internationalization, las personas a menudo tendrán caracteres no ingleses (por ejemplo, é, ñ o ö) en sus nombres.

Sugeriría que uses nvarchar.

Tengo rojo que nvarchar toma el doble que varchar

Sí. Según Microsoft: "El tamaño de almacenamiento, en bytes, es dos veces el número de caracteres ingresados ​​+ 2 bytes" ( http://msdn.microsoft.com/en-us/library/ms186939(SQL.90).aspx ).

Pero el almacenamiento es barato; Nunca me preocupo por unos pocos bytes adicionales.

Además, evite problemas en el futuro y establezca los anchos máximos en algo más generoso, como 100 caracteres. No hay absolutamente ningún gasto de almacenamiento cuando se usa varchar o nvarchar (en lugar de char / nchar). Nunca se sabe cuándo se encontrará con un apellido de triple cañón o un nombre extranjero largo que exceda los 30 caracteres.

nvarchar se usa para la internationalization.

nvarchar puede almacenar cualquier carácter Unicode, como caracteres de scripts no latinos (árabe, chino, etc.). No estoy seguro de cómo su aplicación tomará los datos (a través de la web, a través de un kit de herramientas GUI, etc.), pero es probable que la tecnología que esté utilizando sea compatible con el Unicode desde el primer momento. Eso significa que para cualquier información ingresada por el usuario (como el nombre) siempre existe la posibilidad de recibir caracteres no latinos, si no ahora en el futuro.

Si estuviera construyendo una nueva aplicación, usaría nvarchar. Llámalo "a testing de futuro" si quieres.

El tipo nvarchar es Unicode, por lo que puede manejar cualquier personaje que exista en todos los idiomas del planeta. Los caracteres se almacenan como UTF-16 o UCS-2 (no estoy seguro de cuál, y las diferencias son sutiles), por lo que cada personaje usa dos bytes.

El tipo varchar usa un set de caracteres de 8 bits, por lo que está limitado a los 255 caracteres del juego de caracteres que elija para el campo. Hay diferentes juegos de caracteres que manejan diferentes grupos de caracteres, por lo que suele ser suficiente para el text local de un país o región.

Si varchar funciona para lo que quieres hacer, deberías usar eso. Es un poco less de datos, por lo que es en general un poco más rápido. Si necesita manejar una amplia variedad de caracteres, use nvarchar.

en el performance:
¡una razón para usar varchar sobre nvarchar es que puede tener el doble de caracteres en sus índices! las keys de índice están limitadas a 900 bytes
en usabilidad:
si la aplicación solo está destinada a un público inglés y contiene nombres en inglés, utilice varchar

Datos para almacenar: "Sunil"

varchar (5) toma 7B nvarchar (5) toma 12B