obtener - Táctica de normalización de SQL Server: varchar vs int Identity
script to create identity column in sql server (7)
¿Puedes usar nombres como claves principales? ¿No hay un alto riesgo de que varias personas tengan el mismo nombre?
Si realmente tienes tanta suerte de que tu atributo de nombre se pueda usar como clave principal, entonces - por supuesto - úsalo. A menudo, sin embargo, tendrá que inventar algo, como un customer_id, etc.
Y finalmente: "NAME" es una palabra reservada en al menos un DBMS, así que considere usar algo más, por ejemplo, fullname.
Me pregunto cuál es la solución óptima aquí.
Digamos que tengo una base de datos normalizada. La clave principal de todo el sistema es varchar. Lo que me pregunto es si debo relacionar este varchar con un int para la normalización o dejarlo? Es más simple dejarlo como varchar, pero podría ser más óptimo
Por ejemplo, puedo tener
People
======================
name varchar(10)
DoB DateTime
Height int
Phone_Number
======================
name varchar(10)
number varchar(15)
O podría tener
People
======================
id int Identity
name varchar(10)
DoB DateTime
Height int
Phone_Number
======================
id int
number varchar(15)
Agregue varias otras relaciones de uno a muchos, por supuesto.
¿Qué piensan todos ustedes? ¿Cuál es mejor y por qué?
Creo que la mayoría de las personas que han desarrollado aplicaciones de bases de datos del mundo real de tamaño significativo le dirá que las claves sustitutas son la única solución realista.
Sé que la comunidad académica no estará de acuerdo, pero esa es la diferencia entre la pureza teórica y la practicidad.
Cualquier consulta de tamaño razonable que tenga que hacer combinaciones entre las tablas que usan claves no sustitutas, donde algunas tablas tienen claves primarias compuestas, se vuelve rápidamente inmanejable.
Creo que si tu VARCHAR fuera más grande notarías que estás duplicando bastante información en toda la base de datos. Mientras que si fue con una columna de ID numérico, no está duplicando casi la misma cantidad de datos al agregar columnas de clave externa a otras tablas.
Además, los datos textuales son un dolor real en términos de comparaciones, tu vida es mucho más fácil cuando estás haciendo WHERE id = user_id versus WHERE name LIKE inputname (o algo similar).
La pregunta original no es de normalización. Si tienes una base de datos normalizada, como dijiste, entonces no necesitas cambiarla por razones de normalización.
En realidad, hay dos cuestiones en su pregunta. La primera es si ints o varchars son preferibles para usar como claves primarias y claves externas. El segundo es si puede usar las claves naturales dadas en la definición del problema, o si debe generar una clave sintética (clave sustituta) para tomar el lugar de la clave natural.
Los resultados son un poco más concisos que varchar, y un poco más eficientes para el procesamiento de índices. Pero la diferencia no es abrumadora. Probablemente no deba tomar su decisión solo sobre esta base.
La cuestión de si la clave natural provista realmente funciona como clave natural o no es mucho más significativa. El problema de los duplicados en una columna de "nombre" no es el único problema. También está el problema de lo que sucede cuando una persona cambia su nombre. Es probable que este problema no surja en el ejemplo que ha proporcionado, pero aparece en muchas otras aplicaciones de bases de datos. Un ejemplo sería la transcripción durante cuatro años de todos los cursos tomados por un estudiante. Una mujer puede casarse y cambiar su nombre en el transcurso de cuatro años, y ahora estás atrapado.
Debe dejar el nombre sin cambiar, en cuyo caso ya no concuerda con el mundo real, o actualizarlo retroactivamente en todos los cursos que tomó la persona, lo que hace que la base de datos no esté de acuerdo con las listas impresas que se hicieron en ese momento.
Si decide una clave sintética, ahora debe decidir si la aplicación revelará o no el valor de la clave sintética a la comunidad de usuarios. Esa es otra lata de gusanos, y más allá del alcance de esta discusión.
Si el campo "nombre" es realmente apropiado como clave principal, hágalo. La base de datos no se normalizará más al crear una clave sustituta en ese caso. Obtendrá algunas cadenas duplicadas para las claves externas, pero eso no es un problema de normalización, ya que la restricción FK garantiza la integridad en cadenas de la misma forma que lo haría con las claves sustitutas.
Sin embargo, no estás explicando qué es el "nombre". En la práctica, es muy raro que una cadena sea apropiada como clave principal. Si es el nombre de una persona, no funcionará como PK, ya que más de una persona puede tener el mismo nombre, las personas pueden cambiar los nombres, etc.
Una cosa que otros no parecen haber mencionado es que las uniones en campos int tienden a funcionar mejor que las uniones en campos varchar.
Y definitivamente siempre usaría una clave sustituta sobre el uso de nombres (de personas o empresas) porque nunca son únicos a lo largo del tiempo. En nuestra base de datos, por ejemplo, tenemos 164 nombres con más de 100 instancias del mismo nombre. Esto muestra claramente los peligros de considerar usar el nombre como campo clave.
Usar cualquier clase de datos no sintéticos (es decir, cualquier cosa del usuario, en oposición a la generada por la aplicación) como PK es problemático; tiene que preocuparse por las diferencias de cultura / localización, la distinción entre mayúsculas y minúsculas (y otros problemas que dependen de la intercalación de DB), puede ocasionar problemas de datos si / cuando los datos ingresados por el usuario cambian alguna vez, etc.
El uso de datos no generados por el usuario (GUID secuenciales (o no secuenciales si su base de datos no los admite o no le importan las divisiones de página) o las identidades (si no necesita GUID) es mucho más fácil y mucho más seguro.
En cuanto a los datos duplicados: no veo cómo el uso de claves no sintéticas te protege de eso. Todavía tiene problemas donde el usuario ingresa "Bob Smith" en lugar de "Bob K. Smith" o "Smith, Bob" o "bob smith", etc. La administración de duplicación es necesaria (y prácticamente idéntica) independientemente de si su clave es sintética. o claves no sintéticas y no sintéticas tienen una serie de otros problemas potenciales que las claves sintéticas evitan prolijamente.
Muchos proyectos no necesitan preocuparse por eso (las opciones de intercalación estrictamente restringidas evitan muchos de ellos, por ejemplo), pero en general prefiero las claves sintéticas. Esto no quiere decir que no se puede tener éxito con las claves orgánicas, claramente se puede, pero para muchos proyectos no son la mejor opción.