Esquema de nombres de claves foráneas

Question

Estoy empezando a trabajar con claves foráneas por primera vez y me pregunto si existe un esquema de nomenclatura estándar para ellas.

Dadas estas tablas:

task (id, userid, title) 
note (id, taskid, userid, note); 
user (id, name) 

donde las tareas se han notas, tareas son propiedad de los usuarios, y los usuarios autor señala.

¿Cómo se nombrarían las tres claves externas en esta situación? O, como alternativa, ¿importa incluso?

Actualización: ¡Esta pregunta se trata de nombres de claves foráneas, no de nombres de campos!

Answer 1

La convención estándar en SQL Server es:

FK_ForeignKeyTable_PrimaryKeyTable 

Así, por ejemplo, la clave entre las notas y tareas sería:

FK_note_task 

Y la clave entre las tareas y los usuarios serían:

FK_task_user 

Esto le brinda una vista "de un vistazo" de qué tablas están involucradas en la clave, por lo que Es fácil ver en qué tablas depende una en particular (la primera llamada) (la segunda se llama). En este escenario, el conjunto completo de teclas sería:

FK_task_user 
FK_note_task 
FK_note_user 

Así se puede ver que las tareas dependen de los usuarios, y las notas dependerá de ambas tareas y usuarios.

Answer 2

¿Qué tal FK_TABLENAME_COLUMNNAME?

K EEP I t S impleS tupid siempre que sea posible.

Answer 3

Por lo general, solo dejo mi ID con nombre PK, y luego concateno mi nombre de tabla y nombre de columna clave al nombrar FK en otras tablas. Nunca me molesto con camel-casing, porque algunas bases de datos descartan la distinción entre mayúsculas y minúsculas y simplemente devuelven todos los nombres de mayúsculas y minúsculas. En cualquier caso, esto es lo que mi versión de las tablas se vería así:

task (id, userid, title); 
note (id, taskid, userid, note); 
user (id, name); 

Tenga en cuenta que también el nombre de mi tablas en el singular, debido a que una fila representa uno de los objetos que estoy persistentes. Muchas de estas convenciones son preferencias personales. Sugeriría que es más importante elegir una convención y usarla siempre, que adoptar la convención de otra persona.

Answer 4

uso dos caracteres de subrayado como delimitador es decir

fk__ForeignKeyTable__PrimaryKeyTable 

Esto se debe a los nombres de tabla de vez en cuando contener caracteres de subrayado sí mismos. Esto sigue la convención de nomenclatura para restricciones en general porque los nombres de los elementos de datos con frecuencia contienen caracteres de subrayado, p. Ej.

CREATE TABLE NaturalPersons (
    ... 
    person_death_date DATETIME, 
    person_death_reason VARCHAR(30) 
     CONSTRAINT person_death_reason__not_zero_length 
     CHECK (DATALENGTH(person_death_reason) > 0), 
    CONSTRAINT person_death_date__person_death_reason__interaction 
     CHECK ((person_death_date IS NULL AND person_death_reason IS NULL) 
       OR (person_death_date IS NOT NULL AND person_death_reason IS NOT NULL)) 
     ... 

Answer 5

Sobre la base de las respuestas y comentarios aquí, una convención de nombres que incluye la tabla FK, FK campo, y la tabla de PK (FK_FKTbl_FKCol_PKTbl) deben evitar colisiones FK nombre de restricción.

lo tanto, para las tablas dadas aquí:

fk_task_userid_user 
fk_note_userid_user 

Por lo tanto, si se agrega una columna a un seguimiento de quién modificada por última vez una tarea o una nota ...

fk_task_modifiedby_user 
fk_note_modifiedby_user 

Answer 6

Una nota de Microsoft en relación con SQL Server:

una restricción FOREIGN KEY no tiene por qué estar vinculado únicamente a una PRIMARIA KEY en anot su mesa; también se puede definir para hacer referencia a las columnas de una restricción ÚNICA en otra tabla.

Por lo tanto, utilizaré términos que describan la dependencia en lugar de los términos convencionales de relación primaria/extranjera.

Al hacer referencia a la clave primaria de la independiente (padre) mesa junto a la columna (s) de nombre similar en el dependiente (niños) mesa, omito el nombre (s) columna:

FK_ChildTable_ParentTable 

al hacer referencia a otras columnas, o los nombres de las columnas varían entre las dos tablas, o simplemente ser explícitos:

FK_ChildTable_childColumn_ParentTable_parentColumn 

Answer 7

Si no se hace referencia a su FK de que con frecuencia y usar MySQL (e InnoDB) entonces puedes dejar que MySQL nombre el FK por ti.

En un momento posterior puede find the FK name you need by running a query.

Answer 8

Mi enfoque habitual es

FK_ColumnNameOfForeignKey_TableNameOfReference_ColumnNameOfReference 

O en otros términos

FK_ChildColumnName_ParentTableName_ParentColumnName 

De esta manera puedo nombrar dos claves externas que hacen referencia a la misma mesa como un history_info table con column actionBy and actionTo de users_info mesa

Será como

FK_actionBy_usersInfo_name - For actionBy 
FK_actionTo_usersInfo_name - For actionTo 

Tenga en cuenta que:

no he incluido el nombre de tabla secundaria, ya que parece de sentido común para mí, yo estoy en la tabla del niño para que pueda asumir fácilmente nombre de la tabla del niño.El carácter total de la misma es de 26 y se adapta bien al límite de 30 caracteres de Oracle que fue declarado por Charles Burns en un comentario here

Nota para los lectores: Muchas de las mejores prácticas que figuran a continuación no funcionan en Oracle debido a su límite de 30 caracteres de nombre. El nombre de una tabla o el nombre de la columna ya pueden tener cerca de 30 caracteres, por lo que una convención combinando los dos en un solo nombre requiere un truncamiento estándar o otros trucos. - Charles Burns

Answer 9

Esto es probablemente demasiado matar, pero funciona para mí. Me ayuda mucho cuando trato con VLDB especialmente. Puedo usar el siguiente:

CONSTRAINT [FK_ChildTableName_ChildColName_ParentTableName_PrimaryKeyColName] 

Por supuesto, si por alguna razón usted no está haciendo referencia a una clave principal debe estar haciendo referencia a una columna contenida en una restricción única, en este caso:

CONSTRAINT [FK_ChildTableName_ChildColumnName_ParentTableName_ColumnInUniqueConstaintName] 

¿Puede ser largo, sí. ¿Ha ayudado a mantener la información clara para los informes, o me ha dado un salto rápido para que el problema potencial sea durante una alerta prod-alert? Al 100% le encantaría conocer los pensamientos de la gente sobre esta convención de nombres.