ruby-on-rails - tipos - que es una clave principal en access

¿Por qué no es bueno tener una clave principal en una tabla de unión?

Question

Estaba viendo un vídeo en la pantalla donde el autor dijo que no es bueno tener una clave principal en una tabla de unión, pero no expliqué por qué.

La tabla de unión en el ejemplo tenía dos columnas definidas en una migración de Rails y el autor agregó un índice a cada una de las columnas, pero no una clave principal.

¿Por qué no es bueno tener una clave principal en este ejemplo?

create_table :categories_posts, :id => false do |t|
t.column :category_id, :integer, :null => false
t.column :post_id, :integer, :null => false
end
add_index :categories_posts, :category_id
add_index :categories_posts, :post_id

EDITAR: Como mencioné a Cletus, puedo entender la utilidad potencial de un campo de número automático como clave principal incluso para una tabla de combinación. Sin embargo, en el ejemplo que mencioné anteriormente, el autor explícitamente evita crear un campo de número automático con la sintaxis ": id => false" en la declaración "crear tabla". Normalmente, Rails agregaría automáticamente un campo de identificación de número automático a una tabla creada en una migración como esta y se convertiría en la clave principal. Pero para esta tabla de unirse, el autor específicamente lo previno. No estaba seguro de por qué decidió seguir este enfoque.

Answer 1

Algunas notas:

1. La combinación de category_id y post_id es única en sí misma, por lo que una columna de ID adicional es redundante y inútil
2. La frase "no es bueno tener una clave principal" es incorrecta en el screencast. Todavía tiene una clave principal: solo está formada por las dos columnas (p. Ej., CREATE TABLE foo (cid, pid, PRIMARY KEY (cid, pid)). Para las personas que están acostumbradas a establecer valores de identificación en todas partes, esto puede parecer. extraño, pero en teoría relacional es bastante correcto y natural; el autor del screencast hubiera dicho que "no es bueno tener un atributo entero implícito llamado ''ID'' como clave principal".
3. Es redundante tener la columna adicional porque de todos modos colocará un índice único en la combinación de category_id y post_id para asegurarse de que no se inserten filas duplicadas
4. Finalmente, aunque la nomenclatura común es llamarlo "clave compuesta", esto también es redundante. El término "clave" en la teoría relacional es en realidad el conjunto de cero o más atributos que identifican de forma única la fila, por lo que está bien decir que la clave principal es category_id, post_id
5. Coloque la columna MÁS SELECTIVA PRIMERO en la declaración de clave primaria. Una discusión sobre la construcción de árboles b (+ / *) está fuera del alcance de esta respuesta (para una discusión de nivel inferior, consulte: http://www.akadia.com/services/ora_index_selectivity.html ) pero en su caso Probablemente lo querrá en post_id, category_id ya que post_id aparecerá con menos frecuencia en la tabla y, por lo tanto, hará que el índice sea más útil. Por supuesto, dado que la tabla es tan pequeña y el índice será, esencialmente, las filas de datos, esto no es muy importante. Sería en casos más amplios donde la tabla es más ancha.

Answer 2

Básicamente porque no hay necesidad de ello. La combinación de los dos campos de clave externa identifica de forma única y exclusiva cualquier fila.

Pero eso simplemente dice por qué no es una buena idea ... pero ¿por qué sería una mala idea?

Considere la posibilidad de agregar una columna de identidad. La tabla ocuparía un 50% más de espacio en disco. Peor es la situación del índice. Con un campo de identidad, debe mantener el recuento de identidades más un segundo índice. Estará triplicando el espacio del disco y triplicando el trabajo que se necesita realizar en cada inserción. Con la única ventaja de ser una cláusula WHERE ligeramente más corta en un comando DELETE.

Por otro lado, si los campos clave compuestos son la tabla completa, entonces el índice puede ser la tabla.

Answer 3

Colocar primero la columna más selectiva solo debe ser relevante en la declaración INDEX. En la declaración de KEY, no debería importar (porque, como se ha señalado correctamente, KEY es un SET, y dentro de un set, el orden no importa: el set {a1, a2} es el mismo set que {a2 , a1}).

Si un producto DBMS es tal que el orden de los atributos dentro de una declaración KEY hace una diferencia, entonces ese producto DBMS es culpable de no distinguir correctamente entre el diseño lógico de una base de datos (la parte donde se hace la declaración KEY) y el diseño físico de La base de datos (la parte donde se hace la declaración INDEX).

Answer 4

Es una mala idea no tener una clave principal en ninguna tabla, punto (si el DBMS es un DBMS relacional, o un DBMS de SQL). Las claves principales son una parte crucial de la integridad de su base de datos.

Supongo que si a usted no le importa que su base de datos sea inexacta y proporcione respuestas incorrectas de vez en cuando, entonces podría prescindir de ... pero la mayoría de la gente quiere respuestas precisas de su DBMS y para esas personas, las claves principales son cruciales.

Answer 5

La combinación de claves externas puede ser una clave principal (denominada clave principal compuesta). Personalmente prefiero usar una clave principal técnica en lugar de eso (campo de número automático, secuencia, etc.). ¿Por qué? Bueno, hace que sea mucho más fácil identificar el registro, lo que es posible que deba hacer si lo va a eliminar.

Piénselo: si va a presentar una página web con todos los enlaces, tener una clave principal para identificar el registro lo hace mucho más fácil.

Answer 6

Quería comentar sobre el siguiente comentario: "No es correcto decir cero o más".

Quería señalar que el texto al que se agregó este comentario simplemente no contenía el texto "cero o más", por lo que el autor del comentario que quería comentar criticaba a otra persona por algo que no se había dicho.

También quería comentar que no es correcto decir que no es correcto decir "cero o más". La teoría relacional, tal como se la conoce hoy en día entre las pocas personas que todavía se molestan en estudiar los detalles de esa teoría, en realidad REQUIERE la posibilidad de una clave sin atributos.

Pero cuando presioné el botón "comentar", el sistema me respondió que comentar requiere un puntaje de reputación de 50 (o algo así).

Una triste ilustración de cómo el mundo parece haber olvidado que la ciencia no es la democracia, y que en la ciencia, la verdad no está determinada por quien sea la mayoría, ni por quien tenga la "reputación suficiente".

Answer 7

Un DBA le diría que la clave principal en este caso es en realidad la combinación de las dos columnas FK. Ya que Rails / ActiveRecord no funciona bien con PKs compuestas (al menos por defecto), esa puede ser la razón.

Answer 8

Ventajas de tener un solo PK

• Identifica de forma única una fila con un solo valor
• Facilita la referencia de la relación desde otro lugar si es necesario
• Algunas herramientas quieren que tengas un solo valor entero pk

Contras de tener un solo PK

• Utiliza más espacio en disco
• Necesita 3 índices en lugar de 1
• Sin una restricción única, podría terminar con varias filas para la misma relación

Notas

• Necesitas definir una restricción única si quieres evitar duplicados
• En mi opinión, no uses el único pk si tu mesa va a ser enorme, de lo contrario intercambia un poco de espacio en el disco por conveniencia. Sí, es un desperdicio, pero a quién le importan unos pocos MB en disco en aplicaciones del mundo real.