Was ist eine richtige Namenskonvention für MySQL-FKs?

Da sie eindeutig sein müssen, wie soll ich FKs in einer MySQL-Datenbank nennen?

In MySQL müssen Fremdschlüsseleinschränkungen nicht symbolisch benannt werden. Wenn kein Name angegeben wird, erstellt InnoDB automatisch einen eindeutigen Namen.

In jedem Fall ist dies die Konvention, die ich verwende:

fk_[referencing table name]_[referenced table name]_[referencing field name]

Beispiel:

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);

Ich versuche, bei referenzierenden und referenzierten Tabellen dieselben Feldnamen zu verwenden wie in user_id obigen Beispiel. Wenn dies nicht praktikabel ist, hänge ich auch den referenzierten Feldnamen an den Fremdschlüsselnamen an.

Diese Namenskonvention ermöglicht es mir, den symbolischen Namen nur anhand der Tabellendefinitionen zu "erraten", und garantiert außerdem eindeutige Namen.

Meine Wahl ist anders. Meiner Meinung nach sollte eine Tabelle ein idFeld haben, kein user_ideinziges, da die Tabelle nur aufgerufen userwird.

CREATE TABLE users(
   id    int,
   name       varchar(100)
);

CREATE TABLE messages(
   id int,
   user_id    int
);

user_idIn der messagesTabelle befindet sich ein fk-Feld, daher muss klargestellt werden, welche ID ( user_id) ist.

Eine vollständig selbsterklärende Namenskonvention könnte meiner Meinung nach sein:

fk_[referencing table name]_[referencing field name]_[referenced table name]_[referenced field name]

i.e.: `fk_messages_user_id_users_id`

Hinweis:

• In einigen Fällen können Sie das zweite Element weglassen ([Name des Referenzfelds]).

• Diese fk könnte eindeutig sein, denn wenn eine messages_userTabelle existiert, sollte der Name des referenzierenden Feldes user_id(und nicht nur id) und der fk-Name sein:

  fk_messages_user_user_id_users_id

Mit anderen Worten, eine Fremdschlüssel-Namenskonvention stellt sicher, dass Sie eindeutige Namen haben, wenn Sie auch eine Namenskonvention "Referenzieren / referenziertes Feld" verwenden (und Sie können natürlich Ihre eigene auswählen).

Wenn Sie nicht so oft auf fk verweisen, nachdem sie erstellt wurden, besteht eine Möglichkeit darin, sie einfach zu halten und MySQL die Benennung für Sie vornehmen zu lassen (wie Daniel Vassallo am Anfang seiner Antwort erwähnt ).

Während Sie mit dieser Methode die Einschränkungsnamen nicht eindeutig "erraten" können, können Sie den Fremdschlüssel-Einschränkungsnamen leicht finden, indem Sie eine Abfrage ausführen:

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;

Beispielsweise erhalten Sie möglicherweise Folgendes von der Abfrage:

+------------+-------------+-----------------+-----------------------+------------------------+
| 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                     |
+------------+-------------+-----------------+-----------------------+------------------------+

Wenn Ihnen dieser zusätzliche Schritt nicht zu viel ist, sollten Sie in der Lage sein, das gesuchte fk leicht zu finden.

fk-[referencing_table]-[referencing_field]

Der Grund ist die Kombination von referencing_tableund referencing_fieldist in einer Datenbank eindeutig. Auf diese Weise ist der Name des Fremdschlüssels leicht zu lesen, zum Beispiel:

table `user`:
    id
    name
    role

table `article`:
    id
    content
    created_user_id /* --> user.id */
    reviewed_user_id /* --> user.id */

Wir haben also zwei Fremdschlüssel:

fk-article-created_user_id
fk-article-reviewed_user_id

Das Hinzufügen eines userTabellennamens zum Fremdschlüsselnamen ist redundant.