Відповіді:
У MySQL немає необхідності надавати символічну назву обмеженням зовнішнього ключа. Якщо ім'я не вказано, InnoDB автоматично створює унікальне ім'я.
У будь-якому випадку, я використовую цю конвенцію:
fk_[referencing table name]_[referenced table name]_[referencing field name]
Приклад:
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);
Я намагаюся дотримуватися тих самих імен полів у таблицях посилань та посилань, як у user_id
наведеному вище прикладі. Коли це непрактично, я також додаю назву поля, на яку посилається, до назви зовнішнього ключа.
Ця угода про іменування дозволяє мені "вгадувати" символічну назву, просто переглядаючи визначення таблиць, а крім того, вона також гарантує унікальні імена.
member_id
~> посилання на елемент таблиці, edited_id
~> зовнішній ключ для відредагованого користувача, також посилання на член таблиці. Як я повинен назвати їх?
мій вибір інший. на мій погляд, таблиця повинна мати id
поле, а не user_id
одне, оскільки таблиця просто викликається user
, отже:
CREATE TABLE users(
id int,
name varchar(100)
);
CREATE TABLE messages(
id int,
user_id int
);
user_id
в messages
таблиці - поле fk, тому воно повинно чітко пояснити, який ідентифікатор ( user_id
).
на мій погляд, цілком зрозумілою конвенцією іменування може бути:
fk_[referencing table name]_[referencing field name]_[referenced table name]_[referenced field name]
i.e.: `fk_messages_user_id_users_id`
Примітка:
цей fk could є унікальним, оскільки, якщо messages_user
існує таблиця, ім'я поля посилання має бути user_id
(і не просто id
), а ім'я fk має бути:
fk_messages_user_user_id_users_id
іншими словами, конвенція про іменування зовнішнього ключа гарантує вам впевненість в унікальних іменах, якщо ви також використовуєте конвенцію про іменування "поле посилання / посилання" (і, звичайно, ви можете вибрати власну).
$id
змінну десь, не маючи уявлення, до якої таблиці вона належить. Чим старша ваша кодова база і чим більше людей над нею працювало, тим більшою ймовірністю це стає.
Якщо ви не знайдете посилання на fk, які часто після їх створення, один із варіантів - зробити це простим і дозволити MySQL зробити іменування за вас (як згадує Даніель Вассалло на початку своєї відповіді ).
Хоча ви не зможете однозначно "вгадати" імена обмежень за допомогою цього методу - ви можете легко знайти ім'я обмеження зовнішнього ключа, запустивши запит:
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;
Наприклад, із запиту ви можете отримати таке:
+------------+-------------+-----------------+-----------------------+------------------------+
| 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 |
+------------+-------------+-----------------+-----------------------+------------------------+
Якщо цей додатковий крок для вас не надто великий, тоді ви зможете легко знайти шуканий вами fk.
fk-[referencing_table]-[referencing_field]
Причиною є поєднання referencing_table
та referencing_field
унікальна база даних. Таким чином, ім’я зовнішнього ключа легко читається, наприклад:
table `user`:
id
name
role
table `article`:
id
content
created_user_id /* --> user.id */
reviewed_user_id /* --> user.id */
Отже, у нас є два зовнішні ключі:
fk-article-created_user_id
fk-article-reviewed_user_id
Додавання user
назви таблиці до імені іноземного ключа є зайвим.
user_role
? user
і role
мають багато томових відносин і user_role
є таблицею, яка містить весь зовнішній ключ. Це повинно бути fk_user_role_role
?