| Respuesta: Utilizar INT o VARCHAR en claves
En realidad, si bien usar PK numéricas tiene algunas ventajas, el principio sobre el que se basa la elección de una PK no es ese.
El tema se explica muy claramente cuando se estudia Análisis de Sistemas, o bien los Fundamentos de Bases de Datos, y tiene que ver con el modelo Entidad-Relación.
Una de las principales reglas del modelo especifica que toda entidad (representación de una clase en el sistema) debe tener una clave primaria que sea capaz de identificar unívocamente una instancia de esa entidad en todo el universo de instancias que la entidad puede tener.
Pero esa identidad debe surgir de la Entidad misma, es decir, debe ser algún atributo (dato) o conjunto de atributos que no se repita jamás en otra instancia de la misma entidad, y que pueda servir para identificar esa única instancia.
¿Se entiende el concepto?
Cuando, luego, se pasa a el modelo físico (tablas), en principio sigue siendo eficiente: Usar una clave que sea atributo de la entidad que la tabla representa, siempre es la mejor opción. El qué tipo de dato es, es conceptualmente irrelevante. Lo importante es que sea:
- Unico.
- No nulo.
Sobre la base de esa idea, usar un numero de documento, folio de partida de nacimiento, combinacion empresa+sucursal+numero def actura, hora de ocurrencia+identificador de otro objeto, etc., son todas formas posibles de implementar una PK. Y todas ellas pueden ser muy funcionales.
¿Por qué se usan entonces las claves numéricas autoincrementales?
Según vemos los que nos dedicamos a la arquitectura de datos, la respuesta es simple: Porque la mayoría de los programadores no entiende de bases de datos, porque les resultan fáciles al asociarlas a objetos de programación (arrays, diccionarios), y por simple vagancia (sin ofender).
Lo cierto es que razonar como DBA y razonar como programador son dos modos completamente distintos, y eso hace que algunas cosas del diseño de las bases de datos sean poco comprensibles para los programadores. Por eso prefieren meter con forceps una PK numérica, antes que ponerse a mirar el modelo de datos desde esa óptica, simplemente lo entienden mejor.
Hay unas pocas ventajas en usar una clave primaria numérica:
1) Son más rápidas en las búsquedas, porque su matching es binario, lo que aprovecha directamente los recursos del hardware (UAL).
2) Ocupan menos espacio (máximo 8 bytes o 64 bits).
3) Son fáciles de recordar para el usuario, en el caso del ingreso y validación de datos.
4) Son sencillos de poner en las sentencias, ya que no requieren conversiones ni charsets.
Tienen algunas desventajas en el uso:
1) Generan problemas para integración de datos, ya que diferentes instancias de una misma clase pueden estar usando el mismo ID numérico si están en bases de datos separadas.
2) Generan serios problemas ante truncados accidentales o intencionales, ya que el reinicio de los números produce serios problemas de consistencia histórica.
3) No permiten una fusión de datos sin necesidad de largas tareas de migración que compense los diferentes IDs. Y como ese ID muy probablemente sea FK en otras tablas, la cadena de dependencias debe ser tomada en cuenta en esa migración, haciendo la tarea más compleja.
4) El borrado de datos genera discontinuidades que los usuarios no comprenden y resulta difícil explicar por qué no se deben "llenar".
5) Otros... muchos otros (puse sólo algunos).
Por su lado, una PK basada en atributos propios tiene muchas ventajas:
1) No causa problemas de consolidación ni integración (cada ID es único en todo sentido).
2) El borrado o truncado accidental no produce conflictos con los backups.
3) Si las PK son numéricas (aunque no AI) o de fecha y hora, conserva todas las ventajas de una AI, sin ninguna de las desventajas.
4) Como son atributos propios, las búsquedas son más rápidas ya que los datos importantes se recuperan al mismo tiempo (mejora el uso de índices).
5) Consume menos tiempo de red, al no tener que traer datos no relevantes (los AI).
6) Otros...
Como desventajas, este otro tipo de claves pueden tener:
1) Suelen ser más largas, y eventualmente si se usan VARCHAR volverse un poco lentas en ciertos casos.
2) Los índices pueden ser más grandes.
3) Al programador puede darle más trabajo depurar las consultas por errores de programación no muy visibles.
4) Los usuarios no comprenden bien la lógica de usar tipos de claves no numéricas, por lo que esto debe ser completamente transparente para ellos.
Resumiendo: Si lo analizamos como sistema, es mejor usar claves que sean atributos propios, y no crearlas artificialmente sólo porque sea cómodo. A la larga produce más beneficios.
Por otro lado, se suele sugerir usar claves numéricas en las tablas (para simplificar el proceso) si, y sólo si llegados a la normalización y estando en la 3FN (ver Formas Normales en Wikipedia) aún no se ha determinado una clave candidata, o no una eficiente.
__________________
¿A quién le enseñan sus aciertos?, si yo aprendo de mis errores constantemente...
"El problema es la interfase silla-teclado." (Gillermo Luque)
| 
