SQL - именование столбцов идентификаторов

Question

Мне всегда было интересно, каковы плюсы и минусы этих стилей имен идентификаторов в SQL:

CREATE TABLE cache (
id INT AUTO_INCREMENT,
PRIMARY KEY(id)
);

CREATE TABLE cache (
cid INT AUTO_INCREMENT,
PRIMARY KEY(id)
);

CREATE TABLE cache (
cache_id INT AUTO_INCREMENT,
PRIMARY KEY(id)
);

Почему некоторые разработчики используют «id» в каждой таблице, а некоторые префиксируют его одной буквой имени таблицы или полным именем таблицы вместе с одним подчеркиванием?

Answer 1

Субъективно, но мне нравится использовать именованные идентификаторы (например, customer_id, item_id и т. Д.)

Я рассуждаю так: если вы называете свои внешние ключи последовательно, это облегчает понимание соединений - это всегда a.customer_id = b.customer_id. В противном случае, со сложными запросами, которые используют много объединений, у вас есть море столбцов «id», и не сразу понятно, что с чем.

ETA:

Кроме того, если вы используете MySQL, вы можете использовать более простой синтаксис соединения, например ::

FROM customers INNER JOIN orders USING customer_id

Answer 2

Это все личные предпочтения. Я лично использую Id просто потому, что считаю каждую таблицу отдельной сущностью ... тогда, когда я ссылаюсь с ключом, она становится CustomerId или OrderId в зависимости от имени таблицы.

Answer 3

Собственный SQL: лучше использовать что-то более конкретное, чем id, чтобы люди, пишущие sql, не всегда имели префикс с псевдонимом таблицы. Устраняя необходимость в псевдонимах, вы можете значительно сократить размер SQL и устранить множество ошибок одновременно.

Префикс, даже с именем таблицы, содержит не более символов, чем более конкретное имя столбца:

customer.id
customer_id

С другой стороны, поскольку столбец внешнего ключа ссылается на таблицу, почему бы просто не использовать имя таблицы в качестве внешнего ключа?

table order (
     id        SERIAL PRIMARY KEY,
     customer  INTEGER NOT NULL REFERENCES (customer)
...

Тогда имеем:

FROM customer INNER JOIN order ON customer.id = order.customer

Answer 4

Преимущества простого использования 'id' в том, что у вас единое поле, и его легко запомнить и напечатать.

Преимущества префикса id в имени таблицы заключаются в том, что с ним часто проще работать при частой работе с несколькими таблицами.

cid кажется худшим из трех вариантов, но ни один из преимуществ двух других не дает.

Answer 5

Первым решением является 'id' или нет, и оно определяется инструментом, который обрабатывает SQL:

• ORM: некоторые предпочитают 'id'
• Собственный SQL: лучше использовать что-то более конкретное, чем id, чтобы люди, пишущие sql, не всегда имели префикс с псевдонимом таблицы. Устраняя необходимость в псевдонимах, вы можете значительно уменьшить размер SQL и устранить множество ошибок одновременно.

Второе решение, если вы используете ORM, который требует 'id', это:

• Вы можете просто использовать ограничения ORM для всех имен столбцов
• Или вы можете назвать столбцы для людей и создать отдельное представление, которое переименовывает столбцы в соответствии с требованиями ORM. Это небольшая работа, но если у вас есть больше, чем просто ORM, смотрящий на таблицы (инструменты отчетности, другие ORM и т. Д.), Это может быть полезным.

Или второе решение, если вы не используете 'id', это - как строить имена в реляционных базах данных:

• Как правило, у вас нет кейса для использования - поэтому верблюд и т. Д. Не работают
• Вы хотите избежать именования коллизий
• Вы хотите, чтобы имена были немного интуитивными, не зная имя таблицы
• Вы хотите, чтобы имена были последовательно отформатированы
• Итак, Сид не очень хорош. cache_id является предпочтительным.

Answer 6

Некоторые ORM работают «лучше», когда вы называете первичный ключ каждой таблицы «id».

Answer 7

Как уже отмечали некоторые другие: это действительно личное предпочтение.

Я более или менее придерживаюсь третьего подхода (таблица foo получит столбец id "foo_id"), но не могу точно сказать, почему; -)

Преимущество первого подхода заключается в том, что вы можете переименовывать свою таблицу без необходимости переименовывать столбец id, чтобы отразить изменение. Но вряд ли это повод сделать из этого доктрину.