none
varchar vs Nvarchar RRS feed

  • Pregunta

  • Hola, buenos días, tengo una inquietud

    entiendo perfectamente los tipos de dato varchar y nvachar

    Ahora bien, en las bases de datos de Microsoft, vienen ejemplos como el siguiente

    un campo llamado Gender el cual tiene una longitud de 1 caracter y una restricción = 'M' OR 'F'

    solamente

    ahora, la pregunta es, porque utiliza un tipo de dato NVARCHAR(1)?

    que no es más óptimo un VARCHAR(1)

    cuál sería su razón? alguno tiene idea?  muchas gracias


    saludos

    miércoles, 22 de mayo de 2013 15:14

Respuestas

  • El motivo para ese caso quiza habria que preguntarselo al que creo el ejemplo. Pero nosotros podemos especular.

    Si bien es cierto lo que mencionas NVARCHAR utiliza mas espacio existen otros factores que pudieron ser determinantes al elegirlos.

    1. UNICODE tiene mayor soporte de caracteres, aunque para un campo que almacenaria M y F probablemente no fue determinante.
    2. Pudo haber sido solo una preferencia sin importancia del creador.
    3. Pudo haber sido generado con alguna herramienta que asi lo determino, como lo hacen las herramientas CASE.
    4. Un factor que pudo ser mas determinante es que la mayoria de los programadores que utilizan .NET al enviar parametros a la BD lo hacen con "Parameter.AddWithValue()" que recibe un objeto de tipo object y este al detectar un valor string a nivel de aplicacion envía un parametro NVARCHAR, a no ser que se utilice Parameter.Add() con la especificacion del tipo de datos, considerando esto, si SQL Server recibiera un VARCHAR y la aplicacion por defecto envía NVARCHAR, SQL SERVER tiene que realizar la conversion implicita, y cuando se tiene muchos datos ésta es lenta y genera un cuello de botella muy dificil de detectar, no se si el creador pensó en esto al hacer un ejemplo, pero pudo ser parte de su costumbre como desarrollador experimentado.
    5. Si vas al caso del almacenamiento, lo mas optimo para este caso especifico no ni siquiera el VARCHAR y ni siquiera el CHAR(1), sería el bit que sería mas liviano y más rápido en un índice.
    • Marcado como respuesta kakaroto2012 miércoles, 22 de mayo de 2013 23:54
    miércoles, 22 de mayo de 2013 20:00

Todas las respuestas

  • Hola este enlace te puede servir:

    Diferencia entre Varchar y NVarchar


    Si se solucionó tu consulta no olvides marcar la respuesta. Saludos

    miércoles, 22 de mayo de 2013 15:30
  • conozco el tipo de dato y sus diferencias

    lo que no entiendo, es por qué Microsoft decide colocar NVARCHAR(1) doble espacio de almacenamiento

    a un caracter que puede almacenarse en 1 byte mientras que con unicode lo hace al doble

    posteriormente tendría que utilizar compresión para menos lecturas a la unidad.

    no me cuadra....


    saludos

    miércoles, 22 de mayo de 2013 15:47
  • En este caso no hay razón alguna, solo ocupa el doble y listo, también podría implementarse como un bit que si hay más de un campo comparten ese espacio. El único motivo si es que existe alguno es curarse en salud, desconozco si en chino el Ascii de la F da lugar a una florecita, poniendolo como unicode, desde luego ese problerma no existe. 

    Comparte lo que sepas, aprende lo que no sepas (FGG)
    portalSQL
    El rincón del DBA

    miércoles, 22 de mayo de 2013 19:51
    Moderador
  • El motivo para ese caso quiza habria que preguntarselo al que creo el ejemplo. Pero nosotros podemos especular.

    Si bien es cierto lo que mencionas NVARCHAR utiliza mas espacio existen otros factores que pudieron ser determinantes al elegirlos.

    1. UNICODE tiene mayor soporte de caracteres, aunque para un campo que almacenaria M y F probablemente no fue determinante.
    2. Pudo haber sido solo una preferencia sin importancia del creador.
    3. Pudo haber sido generado con alguna herramienta que asi lo determino, como lo hacen las herramientas CASE.
    4. Un factor que pudo ser mas determinante es que la mayoria de los programadores que utilizan .NET al enviar parametros a la BD lo hacen con "Parameter.AddWithValue()" que recibe un objeto de tipo object y este al detectar un valor string a nivel de aplicacion envía un parametro NVARCHAR, a no ser que se utilice Parameter.Add() con la especificacion del tipo de datos, considerando esto, si SQL Server recibiera un VARCHAR y la aplicacion por defecto envía NVARCHAR, SQL SERVER tiene que realizar la conversion implicita, y cuando se tiene muchos datos ésta es lenta y genera un cuello de botella muy dificil de detectar, no se si el creador pensó en esto al hacer un ejemplo, pero pudo ser parte de su costumbre como desarrollador experimentado.
    5. Si vas al caso del almacenamiento, lo mas optimo para este caso especifico no ni siquiera el VARCHAR y ni siquiera el CHAR(1), sería el bit que sería mas liviano y más rápido en un índice.
    • Marcado como respuesta kakaroto2012 miércoles, 22 de mayo de 2013 23:54
    miércoles, 22 de mayo de 2013 20:00
  • Que buena respuesta !
    miércoles, 22 de julio de 2015 16:15