Respostas:
No MySQL, não há necessidade de dar um nome simbólico às restrições de chave estrangeira. Se um nome não for fornecido, o InnoDB cria um nome exclusivo automaticamente.
Em qualquer caso, esta é a convenção que utilizo:
fk_[referencing table name]_[referenced table name]_[referencing field name]
Exemplo:
CREATE TABLE users(
user_id int,
name varchar(100)
);
CREATE TABLE messages(
message_id int,
user_id int
);
ALTER TABLE messages ADD CONSTRAINT fk_messages_users_user_id
FOREIGN KEY (user_id) REFERENCES users(user_id);
Tento manter os mesmos nomes de campo nas tabelas de referência e referenciadas, como no user_id
exemplo acima. Quando isso não for prático, também acrescento o nome do campo referenciado ao nome da chave estrangeira.
Essa convenção de nomenclatura me permite "adivinhar" o nome simbólico apenas olhando as definições da tabela e, além disso, também garante nomes exclusivos.
member_id
~> link para o membro da tabela, edited_id
~> chave estrangeira para o usuário editado, também link para o membro da tabela. Como devo nomeá-los?
minha escolha é diferente. na minha opinião, uma tabela deve ter um id
campo, não user_id
um, porque a tabela é apenas chamada user
, então:
CREATE TABLE users(
id int,
name varchar(100)
);
CREATE TABLE messages(
id int,
user_id int
);
user_id
na messages
tabela é um campo fk, então ele deve deixar claro qual id é ( user_id
).
uma convenção de nomenclatura totalmente autoexplicativa, na minha opinião, poderia ser:
fk_[referencing table name]_[referencing field name]_[referenced table name]_[referenced field name]
i.e.: `fk_messages_user_id_users_id`
Nota:
este fk poderia ser único, porque se messages_user
existir uma tabela, o nome do campo de referência deve ser user_id
(e não apenas id
) e o nome fk deve ser:
fk_messages_user_user_id_users_id
em outras palavras, uma convenção de nomenclatura de chave estrangeira garante que você tenha certeza sobre nomes exclusivos se você também usar uma convenção de nomenclatura "campo de referência / referenciado" (e você pode escolher a sua própria, é claro).
$id
variável em algum lugar sem nenhuma ideia a qual tabela ela pertence. Quanto mais antiga for a sua base de código e quanto mais pessoas trabalharem nela, mais provável será.
Se você não se pega referenciando fk's tão frequentemente depois que eles são criados, uma opção é mantê-lo simples e deixar o MySQL dar a nomenclatura para você (como Daniel Vassallo menciona no início de sua resposta ).
Embora você não possa "adivinhar" exclusivamente os nomes das restrições com este método - você pode encontrar facilmente o nome da restrição da chave estrangeira executando uma consulta:
use information_schema;
select TABLE_NAME,COLUMN_NAME,CONSTRAINT_NAME, REFERENCED_TABLE_NAME,REFERENCED_COLUMN_NAME from KEY_COLUMN_USAGE where REFERENCED_TABLE_SCHEMA = 'your_db_schema_name' ORDER BY TABLE_NAME;
Por exemplo, você pode receber o seguinte da consulta:
+------------+-------------+-----------------+-----------------------+------------------------+
| TABLE_NAME | COLUMN_NAME | CONSTRAINT_NAME | REFERENCED_TABLE_NAME | REFERENCED_COLUMN_NAME |
+------------+-------------+-----------------+-----------------------+------------------------+
| note | taskid | note_ibfk_2 | task | id |
| note | userid | note_ibfk_1 | user | id |
| task | userid | task_ibfk_1 | user | id |
+------------+-------------+-----------------+-----------------------+------------------------+
Se esta etapa extra não for demais para você, você poderá encontrar facilmente o fk que está procurando.
fk-[referencing_table]-[referencing_field]
O motivo é a combinação de referencing_table
e referencing_field
é único em um banco de dados. Desta forma, torna o nome da chave estrangeira fácil de ler, por exemplo:
table `user`:
id
name
role
table `article`:
id
content
created_user_id /* --> user.id */
reviewed_user_id /* --> user.id */
Portanto, temos duas chaves estrangeiras:
fk-article-created_user_id
fk-article-reviewed_user_id
Adicionar o user
nome da tabela ao nome da chave estrangeira é redundante.
user_role
? user
e role
tem relacionamento muitos com muitos e user_role
é a tabela que contém todas as chaves estrangeiras. Deveria ser fk_user_role_role
?