none
Dudas sobre identificador para una tabla RRS feed

  • Pregunta

  • Buenas tardes, 

    tenía un par de dudas para elegir la PK para una tabla.

    La primera es que por ejemplo si tengo una entidad Persona que posee un DNI y, por lo tanto, podría usar ese DNI como PK podría usar este campo como PK o sería una mejor práctica crear un campo idPersona de tipo int para identificar unas personas de otras. 

    La segunda pregunta sería si es mejor usar un tipo int como PK o es igualmente eficiente usar varchar.

    Muchas gracias y un saludo

    martes, 2 de agosto de 2016 18:00

Respuestas

  • No estoy seguro si sea lo correcto almacenar un código de manera incompleta (no me refiero a un número, el DNI no lo es), para luego agregar ceros a la izquierda, ¿por qué? ¿para sustentar tener un campo identificador numérico?, pienso que el fin no debe de justificar los medios. Por cierto, en Perú la consulta de DNI requiere ingresar 8 dígitos y creo es de esperar, ya que una regla de validación no puede asumir que el primer dígito es cero cuando el usuario sólo haya ingresado 7 dígitos, el usuario pudo haber olvidado digitar un número y no por eso se debe "agregar ligeramente" un cero a la izquierda.


    jueves, 4 de agosto de 2016 3:16

Todas las respuestas

  • Josean_85,

    Una clave subrogada (sin significado para el negocio) es buena candidata porque podrías indicar que el valor se auto-genere (propiedad IDENTITY) y porque al ser un tipo numérico la resolución de las expresiones de combinación (ON) o de filtro (WHERE) es mucho más rápido que un tipo cadena.


    Espero que la información proporcionada te haya sido de utilidad, quedo atento a tus comentarios.
    martes, 2 de agosto de 2016 18:06
  • Te recomiendo siempre usar claves artificiales, y simpre claves del tipo enteros, ya que luegos la vas utilizar en filtros y join, los cuales en indices se comportan mejor que los otro tipos de datos, tambien las claves artificiales te ayudan a la hora de ofucar datos, ya que por ejemplo si queres ofucara el dni y lo tenes como PK, vas a tener que retocar todas las tablas que se relacionan con el DNI, si tu clave es artificial vas a poder ofucar el DNI(columna no clave) si necesidad de recrear relaciones entres las tablas.

    Carlos Ignacio Aguero. DBA SQL Server. Toda mi respeto al pueblo Peruano por la ayuda prestada en la guerra de Malvinas.

    martes, 2 de agosto de 2016 18:26
  • El dni es numerico asi que en vez de varchar lo creas int o numeric(8,0) y ya esta.

    Aparte si vas  a buscar personas por dni un indice tenes que tener ya sea el PK u otro no Clustered porque por el identity no vas a poder buscar.


    • Editado LUIS TARZIA martes, 2 de agosto de 2016 23:10
    martes, 2 de agosto de 2016 23:09
  • Estimado LUIS TARZIA,

    Un número de DNI no puede ser de tipo numérico porque hay números de DNI que inician con 0, ¿cómo representar un cero a la izquierda en un tipo numérico?, no es posible, lo correcto es que la columna sea de un tipo que soporte caracteres alfanuméricos (llámese varchar(n) o similares).

    miércoles, 3 de agosto de 2016 0:38
  • Sinceramente el tema da para mucho, pero me gustaria aclarar un par de puntos, el primero es que al declarar una columna como Primary Key NO obliga a que el Clustered Index de la tabla sea dicha columna, esta es una conducta por default PERO no nosotros podemos perfectamente definirlo en la forma que deseamos, el segundo punto a tomar en cuenta es que por definición dentro de una tabla que al final representan entidades siempre es idoneo el establecimiento de PK NATURALES por aspectos propios del modelado de Base de Datos.

    Mi consejo es:

     1. Crea tus PK tomando atributos o columnas que representen de forma NATURAL (y no artificial) la unicidad de cada fila contenida en la tabla, siempre que sea posible.

    2. En caso de ser columnas cuyo tipo y longitud conoces con precisión y nunca cambiaran te sugiero usar CHAR(N) en lugar de VARCHAR(N) por temas de un mejor rendimiento.

    Hay un texto que explica en detalle estos aspectos y se llama Data & Databases de Joe Celkos, tambien este articulo que explica un poco del tema de PK:

    http://blog.sqlauthority.com/2013/02/10/sql-server-primary-key-and-nonclustered-index-in-simple-words/

    Saludos.


    "Oh, the wind, the wind is blowing,through the graves the wind is blowing,Freedom soon will come; then well come from the shadows".The Partisan(Leonard Cohen) Email: me[at]geohernandez.net Blog:www.geohernandez.net

    miércoles, 3 de agosto de 2016 6:54
  • Por lo menos en Argentina cuando alguien consulta por dni dice 8240350 no 08240350,aparte el tema seria para mostrarlo si quieren ponerle el cero adelante pero un cero a la izquierda no tiene valor.

    miércoles, 3 de agosto de 2016 23:43
  • Igual en el caso de dni si el maximo puede ser 8 (99999999) tenerlo char(8) desperdicia el espacio de los que son menos de 10 millones.
    miércoles, 3 de agosto de 2016 23:46
  • No estoy seguro si sea lo correcto almacenar un código de manera incompleta (no me refiero a un número, el DNI no lo es), para luego agregar ceros a la izquierda, ¿por qué? ¿para sustentar tener un campo identificador numérico?, pienso que el fin no debe de justificar los medios. Por cierto, en Perú la consulta de DNI requiere ingresar 8 dígitos y creo es de esperar, ya que una regla de validación no puede asumir que el primer dígito es cero cuando el usuario sólo haya ingresado 7 dígitos, el usuario pudo haber olvidado digitar un número y no por eso se debe "agregar ligeramente" un cero a la izquierda.


    jueves, 4 de agosto de 2016 3:16
  • Una cosa es la entrada de datos en la web que obliguen a poner 8 digitos para estar seguro que no se olvidan ninguno,otra es que la pagina envie al sql la consulta en forma numerica para hacer uso del indice,

    Si no tiene un indice por dni como lo busca con un identity ??

    Se supone que la validacion y regla de negocio esta del lado del front end (puede poner los 8 digitos y equivocarse tambien) y al sql le tiene que llegar la consulta limpita.

    jueves, 4 de agosto de 2016 4:29