Наименование столбцов идентификаторов в таблицах базы данных

Question

Мне было интересно узнать мнение людей о присвоении имен столбцам ID в таблицах базы данных.

Если бы у меня была таблица с именем «Счета-фактуры» с первичным ключом столбца идентификаторов, я бы назвал этот столбец «InvoiceID», чтобы не конфликтовать с другими таблицами, и очевидно, что это.

Там, где я работаю, они называют все идентификаторы столбцов ID.

Таким образом, они будут делать следующее:

Select  
    i.ID 
,   il.ID 
From
    Invoices i
    Left Join InvoiceLines il
        on i.ID = il.InvoiceID

Теперь я вижу здесь несколько проблем:
1. Вам нужно будет создать псевдоним столбцов на
. 2. ID = InvoiceID не вписывается в мой мозг
3. Если вы не указали псевдоним таблиц и сослались на InvoiceID, очевидно ли, в какой таблице он находится?

Что думают другие люди на эту тему?

Answer 1

Исходя из этого с точки зрения формального словаря данных, я бы назвал элемент данных invoice_ID. Как правило, имя элемента данных будет уникальным в словаре данных и в идеале должно иметь одно и то же имя, хотя иногда могут потребоваться дополнительные уточняющие термины на основе контекста, например элемент данных с именем employee_ID может использоваться дважды в оргструктуре и поэтому квалифицируется как supervisor_employee_ID и subordinate_employee_ID соответственно.

Очевидно, что соглашения о присвоении имен носят субъективный характер и зависят от стиля. Я считаю, что руководящие указания ISO / IEC 11179 являются полезной отправной точкой.

Для СУБД я рассматриваю таблицы как наборы объектов (кроме тех, которые когда-либо содержат только одну строку, например, таблицу cofig, таблицу констант и т. Д.), Например. таблица, где мой employee_ID является ключом, будет называться Personnel. Так что сразу соглашение TableNameID не работает для меня.

Я видел стиль TableName.ID=PK TableNameID=FK, используемый в больших моделях данных, и должен сказать, что он немного сбивает с толку: я предпочитаю, чтобы имя идентификатора было одинаковым во всем, то есть не меняло имя в зависимости от того, в какой таблице оно появляется в. Следует отметить, что вышеупомянутый стиль, кажется, используется в магазинах, которые добавляют столбец IDENTITY (автоинкремент) к каждой таблице , в то же время избегая использования натуральных и составных ключей во внешних ключах. Эти магазины, как правило, не имеют формальных словарей данных и не строят из моделей данных. Опять же, это просто вопрос стиля, на который я лично не согласен. Так что, в конечном счете, это не для меня.

После всего этого я вижу случай, когда иногда удаляют классификатор из имени столбца, когда имя таблицы предоставляет контекст для этого, например. элемент с именем employee_last_name может стать просто last_name в таблице Personnel. Обоснование здесь заключается в том, что доменом являются «фамилии людей», и он, скорее всего, будет UNION редактироваться с last_name столбцами из других таблиц, а не использоваться в качестве внешнего ключа в другой стол, но опять же ... Я мог бы просто передумать, иногда ты никогда не сможешь сказать. Вот в чем дело: моделирование данных - это отчасти искусство, отчасти наука.

Answer 2

Мой голос за InvoiceID для идентификатора таблицы. Я также использую то же соглашение об именах, когда он используется в качестве внешнего ключа, и использую интеллектуальные псевдонимы в запросах.

 Select Invoice.InvoiceID, Lines.InvoiceLine, Customer.OrgName
 From Invoices Invoice
 Join InvoiceLines Lines on Lines.InvoiceID = Invoice.InvoiceID
 Join Customers Customer on Customer.CustomerID = Invoice.CustomerID

Конечно, это длиннее, чем некоторые другие примеры. Но улыбнись. Это для потомков, и когда-нибудь бедному младшему программисту придется изменить свой шедевр. В этом примере нет никакой двусмысленности, и когда к запросу добавляются дополнительные таблицы, вы будете благодарны за многословие.

Answer 3

Я думаю, что вы можете использовать что угодно для «идентификатора», если вы последовательны. Включение имени таблицы важно для. Я бы предложил использовать инструмент моделирования, такой как Erwin, для обеспечения соблюдения соглашений и стандартов именования, чтобы при написании запросов было легко понять отношения, которые могут существовать между таблицами.

Что я имею в виду под первым утверждением, вместо ID вы можете использовать что-то еще, например, «recno». Итак, эта таблица будет иметь PK invoice_recno и т. Д.

Ура, Бен

Answer 4

Для имени столбца в базе данных я бы использовал "InvoiceID".

Если я скопирую поля в безымянную структуру через LINQ, я могу назвать его «ID», если это единственный идентификатор в структуре.

Если столбец НЕ будет использоваться во внешнем ключе, так что он используется только для уникальной идентификации строки для редактирования или удаления, я назову ее «PK».

Answer 5

Если вы даете каждому ключу уникальное имя, например, «invoices.invoice_id» вместо «invoices.id», тогда вы можете без проблем использовать операторы «естественное соединение» и «использование». Э.Г.

SELECT * FROM invoices NATURAL JOIN invoice_lines
SELECT * FROM invoices JOIN invoice_lines USING (invoice_id)

вместо

SELECT * from invoices JOIN invoice_lines
    ON invoices.id = invoice_lines.invoice_id

SQL достаточно многословен, не делая его более многословным.

Answer 6

FWIW, наш новый стандарт (который меняется, я имею в виду «развивается», с каждым новым проектом):

• Имена полей базы данных в нижнем регистре
• Прописные имена таблиц
• Используйте подчеркивания для разделения слов в имени поля - преобразуйте их в регистр Pascal в коде.
• pk_ префикс означает первичный ключ
• _id суффикс означает целое число, идентификатор автоинкремента
• fk_ префикс означает внешний ключ (без суффикса)
• _VW суффикс для видов
• is_ префикс для логических значений

Таким образом, таблица с именем NAMES может иметь поля pk_name_id, first_name, last_name, is_alive, и fk_company и представление с именем LIVING_CUSTOMERS_VW, определенное как:

SELECT first_name, last_name
FROM CONTACT.NAMES
WHERE (is_alive = 'True')

Однако, как уже говорили другие, любая схема будет работать, если она последовательна и не излишне запутывает ваши значения.

Answer 7

То, что я делаю, чтобы все было согласованно для себя (где таблица имеет первичный ключ из одного столбца, используемый в качестве идентификатора), - это присвоение имени первичному ключу таблицы Table_pk. Везде, где у меня есть внешний ключ, указывающий на первичный ключ этой таблицы, я называю столбец PrimaryKeyTable_fk. Таким образом, я знаю, что если у меня есть Customer_pk в моей таблице клиентов и Customer_fk в моей таблице заказов, я знаю, что таблица заказов ссылается на запись в таблице клиентов.

Для меня это имеет смысл, особенно для соединений, где, я думаю, это читается легче.

SELECT * 
FROM Customer AS c
    INNER JOIN Order AS c ON c.Customer_pk = o.Customer_fk

Answer 8

Я определенно согласен с включением имени таблицы в имя поля идентификатора, именно по указанным вами причинам. Как правило, это единственное поле, в которое я бы включил имя таблицы.

Answer 9

Вы можете использовать следующее соглашение об именах. У него есть свои недостатки, но он решает ваши конкретные проблемы.

1. Используйте короткие (3-4 символа) псевдонимы для имен таблиц, т.е. Счет - inv, Линии счетов - invl
2. Назовите столбцы в таблице, используя эти псевдонимы, т.е. inv_id, invl_id
3. Для справочных столбцов используйте invl_inv_id для имен.

так вы могли бы сказать

SELECT * FROM Invoice LEFT JOIN InvoiceLines ON inv_id = invl_inv_id

Answer 10

также см. Соглашение об именовании первичного ключа / внешнего ключа