Clave principal SQL: entero vs varchar

Question

El equipo con el que estoy trabajando decidió crear una tabla con una clave primaria varchar. Esta tabla es referenciada por otra tabla en esta clave primaria.

Tengo la costumbre de crear una clave primaria entera, siguiendo lo que aprendí en la universidad. He leído que hay un aumento de rendimiento con la clave primaria entera.

El problema es que no conozco ningún otro motivo para crear una clave primaria entera. ¿Tiene algún consejo?

Answer 1

Se supone que la clave principal representa la identidad de la fila y no debe cambiar con el tiempo.

Supongo que varchar es una especie de clave natural, como el nombre de la entidad, una dirección de correo electrónico o un número de serie. Si utiliza una clave natural, a veces puede suceder que la clave necesite cambiar porque, por ejemplo:

• Los datos se ingresaron incorrectamente y deben corregirse.
• El usuario cambia su nombre o dirección de correo electrónico.
• De repente, la administración decide que todos los números de referencia del cliente deben cambiarse a otro formato por razones que le parecen totalmente ilógicas, pero insisten en realizar el cambio incluso después de explicar los problemas que esto le ocasionará.
• Tal vez incluso un país o estado decida cambiar la ortografía de su nombre, muy poco probable, pero no imposible.

Al usar una clave sustituta, evita los problemas causados ​​por tener que cambiar las teclas principales.

Answer 2

VARCHAR frente a INT no dice mucho. ¿Qué importa es el patrón de acceso?

En términos absolutos, una clave más amplia siempre será peor que una clave estrecha. El tipo no tiene absolutamente ninguna importancia, es el ancho que importa. Sin embargo, cuando se compara con INT, pocos tipos pueden vencer a INT en estrechez, por lo que INT generalmente gana ese argumento solo por el hecho de que tiene solo 4 bytes de ancho.

Pero lo que realmente materias es la elección de clúster clave. A menudo se confunde con la clave principal, los dos representan diferentes nociones y son no necesarios para superponerse. Aquí hay una discusión más detallada Should I design a table with a primary key of varchar or int? La elección de la tecla agrupada es casi la decisión más importante en el diseño de la tabla, y una aplicación mecánica de INT identity(1,1) puede ser el mayor error que se pueda cometer. Aquí es donde entra la cuestión de los patrones de acceso:

• ¿Cuáles son las interrogaciones más frecuentes sobre la mesa?
  • ¿Qué columnas se proyectan?
  • ¿qué predicados se aplican?
  • ¿Qué rangos se buscan?
  • ¿Qué uniones se realizan?
  • ¿Qué agregaciones se producen?
• ¿cómo se insertan los datos en la tabla?
• ¿cómo se actualizan los datos en la tabla?
• ¿cómo se eliminan los datos viejos de la tabla, si es que alguna vez?
• ¿cuántos índices no agrupados existen?
  • ¿con qué frecuencia se actualizan las columnas incluidas en los índices NC (clave o hoja)?

En general, hay muchos patrones de acceso que puede ser arruinado por el uso de una identidad INT clave agrupada. Así que antes de saltar a aplicar una solución de cortador de galletas, tal vez se requiere un poco de análisis ...

Algunas pautas más generales:

• Clustered Index Design Guidelines
• Index Design Basics
• Unique Index Design Guidelines

Ve que no hay directrices de diseño de clave principal, porque la clave primaria no es un problema de diseño de almacenamiento, sino una cuestión de modelado y está completamente controlado por el dominio.

Answer 3

que estaba un poco decepcionado porque he el hábito de crear una clave principal entero (después de lo que dijo algún maestro conmigo en la universidad). He leído mucho de la documentación sobre el rendimiento impulso usando la clave primaria entera.

Hay un término para esto: confirmation bias:

"también llamado sesgo de confirmación o sesgo myside) es una tendencia de las personas a favor de la información que confirma sus preconcepciones o hipótesis, independientemente de si son verdaderas. Esto tiene como resultado que las personas recopilen nuevas pruebas de forma selectiva, interpreten las pruebas de forma sesgada o que retiren información de manera selectiva de la memoria ".

Por supuesto, su primera reacción será decir: "¡Pero eso no es cierto!" Sí, dirías que 'porque estás predispuesto;) [con la lengua firmemente incrustada en la mejilla]

Aquí tienes un ejemplo clásico: dijiste que tu profesor de zoología te había dicho que todos los cisnes son blancos y, por supuesto, todos los cisnes que tú y tus amigos alguna vez han visto son blancos. Ahora digamos más adelante en la vida, un colega expresó la opinión de que quizás exista una criatura como un cisne negro. ¡¿Qué?! Eso no es lo que te enseñaron. Tu mundo está sacudido! Inmediatamente sales y realizas una encuesta de cisnes y cuentas 1,000 cisnes blancos y cero cisnes negros. ¡Prueba! Si hubieras encontrado 10.000 cisnes blancos, la hipótesis "Todos los cisnes son blancos" sería diez veces más cierto, ¿no?

Un enfoque diferente sería olvidarse de los cisnes blancos por el momento y tratar de buscar un cisne negro. Tal vez tomar unas vacaciones junto al mar en el soleado Dawlish?

Realmente no quiero sonar irrespetuoso; Admites que lees mucho sobre lo que te han dicho y que de hecho me gana mi respeto. Así que aquí hay un desafío: trate de encontrar casos en los que no sea necesario agregar una columna entera a una tabla.

Aquí hay algunos consejos y spoilers: tablas a las que no hacen referencia otras tablas; tablas de búsqueda de "todas las claves" de una sola columna; '' Pequeñas mesas que no se consultan mucho :)

Aquí están algunos otros temas relacionados que le gustará a investigar:

¿La palabra 'principal' en 'clave principal' tiene mucho significado o son todas las claves en una mesa dada igual?

¿Cuáles son las cualidades de una "buena" clave? (Por ejemplo, ¿los valores de una clave deben ser inmutables o una estabilidad "buena" suficiente?)

Se agrega una columna entera a la tabla como clave artificial (perhpas porque la clave natural disponible no es lo suficientemente buena) o como una clave sustituta (¿tal vez para aumentar el rendimiento de una clave natural "buena")?

Cuando se agrega una clave sustituta a una tabla por razones de rendimiento, ¿se trata de un efecto real medido o simplemente de un efecto percibido (es decir, una optimización prematura)?

¿Deben aparecer las claves sustitutas en el modelo comercial lógico o solo para la implementación?

¿Es una buena idea hacer siempre algo (por ejemplo, agregar una columna entera a una tabla) sin ocupar el cerebro cada vez? ;)

[Descargo de responsabilidad: soy un defensor clave natural y evito los sustitutos. Para mí son como la desnormalización: solo lo haces cuando tienes que hacerlo, generalmente por un problema de rendimiento (específico y demostrable), donde la falla se encuentra en otro lado (mala versión del producto SQL, falla de diseño lógico que no se puede arreglar en este momento, etc.) Los sustitutos nunca deberían aparecer en el modelo de negocio lógico. A veces necesito un identificador artificial e incluso he expuesto los modelos comerciales lógicos.]