[SOLUCIONADO] Manejo de Indices

[bandolera]

Estoy rediseñando una base de datos y tengo algunas dudas:
En mi tabla de trabajadores tengo un cambio que es el documento de identidad que son números.
La pregunta es:
1) Ese campo es mejor manejarlo como varchar o como integer o algún otro tipo de campo para que sea la llave primaria??
2) En internet encontré que recomiendan agregar un campo adicional que sea ID autoincremental. Es mejor que usar la clave con el documento de identidada?
Espero sugerencias y comentarios.

[gnzsoloyo]

La cosa sería:
1) Si el numero del documento puede encontrarse representado en alguna parte con un cero inicial, lo tienes que guardar como VARCHAR, de lo contrario es mejor como INT UNSIGNED (sin signo, porque no existen numeros de documento negativos).
2) Ese es un consejo de programadores. El modelo relacionar define solamente que debe ser una clave única e irrepetible. Pero cuando estudias bases de datos profesionalmente se aclara que lo recomendable es que la clave sea un atributo propio de la entidad representada, y no un ID fabricado, incluso cuando eso implique hacer claves compuestas de más de un campo.
Las razones son varias y la explicación es un poquitín larga, pero en definitiva es recomendable no usar autoincrementales, ya que a futuro te evitará problemas en el caso de migraciones, backups, consolidaciones de bases, integracion de datos de bases distribuidas, almacenes de datos, etc.
Para darte una idea: Los números de códigos de barra son únicos universalmente a nivel planetario. Esto implica que el mismo numero es reconocido en tu país, en Italia o en Burkina Faso... Esa es la meta final de una PK.

[bandolera]

Iniciado por gnzsoloyo

La cosa sería:
1) Si el numero del documento puede encontrarse representado en alguna parte con un cero inicial, lo tienes que guardar como VARCHAR, de lo contrario es mejor como INT UNSIGNED (sin signo, porque no existen numeros de documento negativos).
2) Ese es un consejo de programadores. El modelo relacionar define solamente que debe ser una clave única e irrepetible. Pero cuando estudias bases de datos profesionalmente se aclara que lo recomendable es que la clave sea un atributo propio de la entidad representada, y no un ID fabricado, incluso cuando eso implique hacer claves compuestas de más de un campo.
Las razones son varias y la explicación es un poquitín larga, pero en definitiva es recomendable no usar autoincrementales, ya que a futuro te evitará problemas en el caso de migraciones, backups, consolidaciones de bases, integracion de datos de bases distribuidas, almacenes de datos, etc.
Para darte una idea: Los números de códigos de barra son únicos universalmente a nivel planetario. Esto implica que el mismo numero es reconocido en tu país, en Italia o en Burkina Faso... Esa es la meta final de una PK.

Y para redondear la idea, entre un Varchar y un Integer qué es lo más óptimo en líneas generales para pa PK?

[gnzsoloyo]

Estás perdiendo de vista lo que dije: Depende del dato que se representará.
Si tiene ceros a la izquierda, como por ejemplo los numeros telefónicos, no puedes usar campos numéricos. Sólo VARCHAR.
Desde el punto de vista de la performance absoluta (a nivel de kernel), los números son siempre más eficientes, porque no requieren interpretación. Se evalúan en forma binaria. Ahora bien, eso se nota recién cuando hablamos de millones de registros.
Lo dicho primero no quiere decir que sea necesario o correcto usarlos como PK. Esa elección depende de lo que represente esa tabla.
Es un tema de análisis de sistemas, cuando se definen los requerimientos.
Hacerlo porque "dicen" que es más performante puede llevarte a errores de diseño graves, como por ejemplo creer que en lugar de usar una combinación de fecha y hora como PK es menos eficiente que un número. El error es que en la estructura de almacenamiento de una base de datos, una fecha es un número. ¿Sabías eso? No es un campo VARCHAR, ni existe como "fecha", es un numero.

[bandolera]

Iniciado por gnzsoloyo

Estás perdiendo de vista lo que dije: Depende del dato que se representará.
Si tiene ceros a la izquierda, como por ejemplo los numeros telefónicos, no puedes usar campos numéricos. Sólo VARCHAR.
Desde el punto de vista de la performance absoluta (a nivel de kernel), los números son siempre más eficientes, porque no requieren interpretación. Se evalúan en forma binaria. Ahora bien, eso se nota recién cuando hablamos de millones de registros.
Lo dicho primero no quiere decir que sea necesario o correcto usarlos como PK. Esa elección depende de lo que represente esa tabla.
Es un tema de análisis de sistemas, cuando se definen los requerimientos.
Hacerlo porque "dicen" que es más performante puede llevarte a errores de diseño graves, como por ejemplo creer que en lugar de usar una combinación de fecha y hora como PK es menos eficiente que un número. El error es que en la estructura de almacenamiento de una base de datos, una fecha es un número. ¿Sabías eso? No es un campo VARCHAR, ni existe como "fecha", es un numero.

Mi pregunta anterior era en forma genera, comparando un campo código de productos que tiene números con otro que tiene letras y números. Y entendí tu explicación.
Para el análisis de los datos de la BD se deben utilizar las formas normales. Cierto?