SQL - именование ID столбцов

Question

Я всегда задавался вопросом, каковы плюсы и минусы этих ID именования стилей в 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) 
); 

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

Answer 1

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

Answer 2

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

Answer 3

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

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

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

Answer 4

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

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

ETA:

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

FROM customers INNER JOIN orders USING customer_id 

Answer 5

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

• ОРМ: некоторые предпочитают «ID»
• Native SQL: его лучше использовать что-то более конкретное, чем идентификатор, так что люди писать SQL д всегда нужно префикс с псевдонимом таблицы. Исключая необходимость в псевдонимах, вы можете значительно уменьшить размер SQL и одновременно устранить множество ошибок.

Второе решение, если вы используете ORM, который требует «идентификатор», является:

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

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

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

Answer 6

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

я более или менее придерживаться третьего подхода (таблица Foo получит столбец ID «foo_id»), но не могу сказать вам, почему ;-)

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

Answer 7

Native SQL: его лучше использовать что-то более конкретное, чем идентификатор, так что люди, пишущие 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