Estoy trabajando en un par de enlaces a tablas y me puse a pensar (peligro Robinson, Peligro) ¿cuáles son las posibles estructuras de una tabla de enlaces y cuáles son sus pro y contras.

Me encontré con un par de posibles estenosis de la tabla de enlaces:

Tradicional de la columna 3 modelo

  • id – numeración automática de PRIMARIA
  • table1fk – foreign key
  • table2fk – foreign key

Es un clásico, en la mayoría de los libros, ‘nuff dijo.

Indexado 3 modelo de columna

  • id – numeración automática de PRIMARIA
  • table1fk – foreign key INDEX ('table1fk')
  • table2fk – foreign key INDEX ('table2fk')

En mi propia experiencia, los campos que están en contra de la consulta no son indexados en el modelo tradicional. He encontrado que la indexación de los campos de clave externa que hace mejorar el rendimiento como sería de esperar. No es un cambio importante, pero una buena optimización de tweak.

Clave compuesta de 2 columnas ADD PRIMARY KEY ('table1fk' , 'table2fk')

  • table1fk – foreign key
  • table2fk – foreign key

Con esto yo uso una clave compuesta de modo que un registro de la tabla1 sólo puede estar vinculado a un registro en la tabla2 una vez. Porque la clave está compuesto me puede agregar registros (1,1), (1,2), (2,2) sin duplicación de errores.

Cualquier problema potencial con la clave compuesta de 2 columnas opción? Hay un problema de indexación que esto podría causar? Un impacto en el rendimiento? Nada de lo que descalificaría a esta como una opción posible?

12 Comentarios

  1. 12

    Por cierto vincular tablas, por lo general, no existe como objeto de entidades en mis modelos de objetos. Así, el sustituto de la clave es que no las he usado nunca. El extraíbles de un elemento de una colección de resultados en la eliminación de un elemento de un vínculo de relación en la que ambas claves foráneas son conocidos (Person.Siblings.Remove(Sibling) o Person.RemoveSibling(Sibling) que está debidamente traducido en la capa de acceso a datos como usp_Person_RemoveSibling(PersonID, SiblingID)).

    Como Mike se mencionó, si se le hace una entidad real en su modelo de objetos, entonces es posible que el mérito de un ID. Sin embargo, incluso con adición de factores temporales como eficaz fechas de inicio y fin de la relación, y cosas como esa, no siempre está claro. Por ejemplo, la colección puede tener una fecha de vigencia asociados a nivel agregado, por lo que la relación en sí todavía no puede convertirse en una entidad con cualquiera de propiedades expuestas.

    Me gustaría añadir que usted podría necesitar muy bien la tabla indizada en ambos sentidos en las dos columnas de clave externa.

  2. 18

    Me haría uso de la clave compuesta, y sin sentido de la clave.

    No me gustaría usar un ORM sistema que exige el cumplimiento de estas reglas en mi db estructura.

    • además, trato de evitar IDENTIDAD/AUTO_INCREMENT campos, como tienden a hacer el trabajo con tablas más difícil, y le da menos control. Pero es irrelevante en este caso, y que tienen su propósito..
    • Yo woudln no elige utilizar un ORM que la impone, cualquiera, pero en algunos trabajos (como el mío) que no llega a elegir a veces. Yo trabajo en cerca de 40 proyectos de un año, y no todos de ellos a comenzar desde cero, sino que son mejoras de los existentes en los sitios del cliente, donde un ORM ya está en su lugar.
    • +1 Buena cabezas arriba en el ORM. Va a mirar hacia fuera para eso.
    • en caso de que el índice sea único?
    • Depende de su caso de uso.
  3. 6

    Si esta es una verdadera muchos-a-muchos de unirse a la mesa, y luego volcar innecesaria columna de id (a menos que su ORM requiere uno. en ese caso, usted tiene que decidir si su intelecto se va para el triunfo de su sentido práctico).

    Pero me parece que la verdadera unión de tablas son bastante raros. Normalmente no pasa mucho tiempo antes de que empiece a querer poner algunos otros datos de esa tabla. Debido a que casi siempre el modelo de estas unirse a las mesas como entidades desde el principio y palo de una id de allí.

  4. 6

    Tener una sola columna pk puede ayudar mucho en la situación de recuperación de desastres. Así, aunque mientras correcta en la teoría de que sólo se necesitan las 2 claves foráneas. En la práctica, cuando la mierda golpea el ventilador puede que desee que el único columna clave. Nunca he estado en una situación en la que yo estaba jodido porque tenía un único identificador de columna, pero he estado en la que yo estaba jodido porque yo no.

    • +1 para señalar esto, sé que debería tener una clave principal para permitir la recuperación de desastres, pero no sé cómo lo que realmente ayuda. ¿Puede por favor explicar como tener un clave primaria de la ayuda y/o punto de que algunos materiales?
  5. 3

    Compuesto PK y desactivar la agrupación.

    • podría elaborar en la agrupación? por qué desactivarlo?
    • Al crear una clave principal por defecto se crea un índice agrupado. Esto está bien si las claves principales serán principalmente insertado o buscado en orden. Pero para una tabla de enlaces como esto de las relaciones más probable es que no será en ningún orden significativo por lo tanto se convierte en más trabajo para SQL para mantener la tabla.
  6. 1

    He utilizado compuesto clave para prevenir la duplicación de la entrada y dejar la base de datos de manejar la excepción. Con una sola tecla, se basan en la aplicación de front-end para comprobar la base de datos duplicados antes de agregar un nuevo registro.

  7. 0

    Si usted necesita para recorrer la tabla de combinación «en ambas direcciones’, que está empezando con un table1fk o un table2fk clave, usted puede considerar la adición de un segundo revés, índice compuesto.

    ADD KEY ('table2fk', 'table1fk')
  8. 0

    La respuesta correcta es:

    • Clave principal es ('table1fk' , 'table2fk')
    • Otro índice de la ('table2fk' , 'table1fk')

    Porque:

    • Usted no necesita un índice en table1fk o table2fk solos: el optimizador de conversiones se utilice el PK
    • Lo más probable es que el uso de la tabla de «ambos» formas
    • La adición de una clave suplente sólo es necesario porque de braindead Orm
    • De verdad? Puedo entender el primer punto, pero estoy sorprendido de que unirse a la tabla1->link->tabla2 llevará a cabo de manera diferente que la tabla2->link->table1
    • Se da el optimizador de más opciones y no te olvides de: tendrás una DONDE o EXISTE o no puede tocar la tabla 2 en caso de hacer «DONDE vínculo.table2fk = @table2keyvalue»
  9. 0

    Hay algo que se llama identificación y la no identificación de la relación. Con la identificación de las relaciones de la FK es una parte de la PK en el de muchos-a-muchos de la tabla. Por ejemplo, supongamos que tenemos las tablas Person, Company y muchos-a-muchos la tabla Employment. En una relación de identificación, tanto fk PersonID y CompanyID son parte de la pk, así que no se puede repetir PersonID, CompanyID combinación.

    TABLE Employment(PersonID int (PK,FK), CompanyID int (PK,FK))

    Ahora, supongamos que queremos capturar la historia de empleo, de modo que una persona puede salir de una empresa, trabajar en otro lugar y volver a la misma compañía más tarde. La relación es la no identificación de aquí, la combinación de PersonID, CompanyID ahora pueden repetir, por lo que la tabla sería algo como:

    TABLE Employment(EmploymentID int (PK), PersonID int (FK), CompanyID int (FK), 
                         FromDate datetime, ToDate datetime)
  10. 0

    Si usted está usando un ORM para obtener/modificar los datos, algunos de ellos requieren de una sola columna de clave principal (Gracias Tom H para señalar esto) con el fin de funcionar correctamente (creo Subsónico 2.x fue de esta manera, no estoy seguro acerca de 3.x).

    En mi mente, tener la clave principal no afecta al rendimiento mensurable de grado, así que normalmente uso.

    • Por la «clave principal» supongo que quieres decir, «de una sola columna de clave principal». Esa es una muy importante distinción. Una clave principal compuesta también es una clave principal.
    • Doh! Eso es exactamente a lo que me refería. Gracias por la aclaración. Voy a editar la respuesta a mostrar que, demasiado.
  11. -1

    yo he usado tanto, la única ventaja de usar el primer modelo (con uid) es que puede transportar el identificador de alrededor como un número, mientras que en algunos casos, usted tendría que hacer algo de concatenación de cadenas con la clave compuesta para el transporte de alrededor.

    estoy de acuerdo en que no indexación de las claves foráneas es una mala idea, sea cual sea la manera de ir.

    • El transporte? ¿Cómo es eso? Estoy asumiendo movimiento de db a db o db de texto. No estoy familiarizado con el término.
    • Yo creo que él significa pasar de la entidad en su código, o en una cadena de consulta, etc. Siempre se puede tener 2 parámetros en cualquiera que sea el método/función a la que llama, pero a veces es más fácil tener 1 que representa el registro como oposición a ambos.
    • sí, me refiero a lo que matt dice.
  12. -1

    Yo (casi) siempre uso adicional de una sola columna de clave principal. Esto generalmente hace que sea más fácil para construir interfaces de usuario, ya que cuando un usuario selecciona una particular vinculación de la entidad que se puede identificar con un único valor entero en lugar de tener que crear y, a continuación, analizar compuesto identificadores.

Dejar respuesta

Please enter your comment!
Please enter your name here