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

Мне было интересно мнение людей об именах столбцов идентификаторов в таблицах базы данных.

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

Где я сейчас работаю, они вызвали все столбцы идентификатора идентификаторами.

Итак, они сделали бы следующее:

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

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

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

ID - это антипаттерн SQL. См. Http://www.amazon.com/s/ref=nb_sb_ss_i_1_5?url=search-alias%3Dstripbooks&field-keywords=sql+antipatterns&sprefix=sql+a.

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

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

Если вы хотите использовать синтаксис USING, разрешенный некоторыми базами данных, вы не можете использовать ID.

Если вы используете ID, вы можете легко получить ошибочное соединение, если вам случится копировать синтаксис соединения (не говорите мне, что никто никогда этого не делает!) И забудьте изменить псевдоним в условии соединения.

Итак, теперь у вас есть

select t1.field1, t2.field2, t3.field3
from table1 t1 
join table2 t2 on t1.id = t2.table1id
join table3 t3 on t1.id = t3.table2id

когда ты имел в виду

select t1.field1, t2.field2, t3.field3 
from table1 t1 
join table2 t2 on t1.id = t2.table1id
join table3 t3 on t2.id = t3.table2id

Если вы используете tablenameID в качестве поля идентификатора, вероятность возникновения такой случайной ошибки гораздо меньше, и ее гораздо легче найти.

Я всегда предпочитал ID вместо TableName + ID для столбца id, а затем TableName + ID для внешнего ключа. Таким образом, все таблицы будут иметь одно и то же имя для поля id и не будет повторяющегося описания. Мне это кажется проще, потому что все таблицы имеют одно и то же имя поля первичного ключа.

Что касается объединения таблиц и незнания, какое поле Id принадлежит какой таблице, на мой взгляд, запрос должен быть написан для обработки этой ситуации. Там, где я работаю, мы всегда предпочитаем поля, которые мы используем в операторе, с псевдонимом таблицы / таблицы.

В последнее время в моей компании велась борьба ботаников из-за этого. Появление LINQ сделало повторяющийся шаблон имя таблицы + идентификатор еще более глупым в моих глазах. Я думаю, что большинство разумных людей скажут, что если вы вручную пишете свой SQL таким образом, что вам нужно указывать имена таблиц для различения FK, тогда это не только экономит на вводе, но и добавляет ясности в ваш SQL, чтобы использовать только ID, в котором вы можете четко видеть, что является PK, а которое FK .

Например

ОТ сотрудников e ЛЕВАЯ ПРИСОЕДИНЯЙТЕСЬ к клиентам c НА e.ID = c.EmployeeID

говорит мне не только о том, что они связаны, но и о том, что является ПК, а что - ФК . Тогда как в старом стиле приходится либо смотреть, либо надеяться, что их правильно назвали.

Мы используем InvoiceID, а не ID. Это делает запросы более удобочитаемыми - когда вы видите IDодно, это может означать что угодно, особенно когда вы присваиваете таблице псевдоним i.

Я согласен с Кевеном и несколькими другими людьми здесь, что PK для таблицы должен быть просто Id, а внешние ключи перечисляют OtherTable + Id.

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

В моем текущем положении мы используем структуру сущностей с использованием генерации POCO. Используя стандартное соглашение об именах Id, PK позволяет наследовать базовый класс poco с проверкой и тому подобное для таблиц, которые используют набор общих имен столбцов. Использование Tablename + Id в качестве PK для каждой из этих таблиц лишает возможности использовать для них базовый класс.

Просто пища для размышлений.

Я предпочитаю также ID для первичного ключа и TableNameID для внешнего ключа. Мне также нравится иметь столбец «имя» в большинстве таблиц, где я храню читаемый пользователем идентификатор (например, имя :-)) записи. Эта структура обеспечивает большую гибкость в самом приложении, таким же образом я могу обрабатывать массу таблиц. Это очень мощная штука. Обычно объектно-ориентированное программное обеспечение создается поверх базы данных, но набор инструментов объектно-ориентированного программирования не может быть применен, потому что сама база данных не позволяет этого. Иметь идентификатор и имя столбца - это еще не очень хорошо, но это шаг.

Выберите
i.ID, il.ID из счетов-фактур. Я оставил строки для присоединения к счету il на i.ID = il.InvoiceID.

Почему я не могу этого сделать?

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

На мой взгляд, это очень удобно и просто. Называть переменные как i и il в целом - плохой выбор.

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

Но важно быть последовательным, чтобы не смотреть на определения таблиц каждый раз, когда вы пишете запрос.

Я только начал работать в месте, которое использует только «ID» (в основных таблицах, на которые ссылается TableNameID во внешних ключах), и уже обнаружил ДВЕ производственные проблемы, непосредственно вызванные этим.

В одном случае запрос использовал «... где ID в (SELECT ID FROM OtherTable ...») вместо «... where ID in (SELECT TransID FROM OtherTable ...».

Может ли кто-нибудь честно сказать, что это было бы гораздо легче обнаружить, если бы использовались полные, согласованные имена там, где неправильный оператор читал бы "... где TransID in (SELECT OtherTableID from OtherTable ..."? Я не думаю так.

Другая проблема возникает при рефакторинге кода. Если вы используете временную таблицу, тогда как ранее запрос выполнялся из базовой таблицы, тогда старый код читается как «... dbo.MyFunction (t.ID) ...», и если это не изменилось, то «t» теперь относится к временную таблицу вместо основной, вы даже не получите ошибку - только ошибочные результаты.

Если целью является создание ненужных ошибок (может быть, у некоторых людей недостаточно работы?), Тогда такое соглашение об именах отлично подходит. В остальном последовательное именование - это лучший способ.

Для простоты большинство людей называют столбец в таблице идентификатором. Если у него есть ссылка на внешний ключ в другой таблице, тогда они явно называют это InvoiceID (для использования вашего примера) в случае объединений, вы все равно используете псевдоним таблицы, поэтому явный inv.ID по-прежнему проще, чем inv.InvoiceID

Я лично предпочитаю (как было сказано выше) Table.ID для PK и TableID для FK . Даже (пожалуйста, не стреляйте в меня) Microsoft Access рекомендует это.

ОДНАКО, я ТАКЖЕ знаю, что некоторые инструменты генерации предпочитают TableID для PK, потому что они имеют тенденцию связывать все имена столбцов, которые содержат «ID» в слове, ВКЛЮЧАЯ ID !!!

Даже конструктор запросов делает это на Microsoft SQL Server (и для каждого создаваемого вами запроса вы в конечном итоге отбрасываете все ненужные вновь созданные отношения во всех таблицах по идентификатору столбца)

ПОЭТОМУ, как бы сильно мое внутреннее ОКР его не ненавидело, я придерживаюсь соглашения TableID . Давайте вспомним, что это называется БАЗА ДАННЫХ , так как она, мы надеемся, станет основой для многих многих приложений в будущем. И все технологии должны иметь хорошо нормализованную с четким описанием схему.

Само собой разумеется, что я ДЕЙСТВУЮ черту, когда люди начинают использовать TableName, TableDescription и т. Д. На мой взгляд, конвенции должны делать следующее:

• Название таблицы: во множественном числе. Ex. Сотрудников

• Псевдоним таблицы: полное имя таблицы в единственном числе. Ex.

  SELECT Employee.*, eMail.Address
  FROM Employees AS Employee LEFT JOIN eMails as eMail on Employee.eMailID = eMail.eMailID -- I would sure like it to just have the eMail.ID here.... but oh well

[Обновить]

Кроме того, в этой ветке есть несколько валидных сообщений о дублированных столбцах из-за «родства» или роли. Например, если у магазина есть EmployeeID , это говорит мне о приседании. Поэтому я иногда делаю что-то вроде Store.EmployeeID_Manager . Конечно, он немного больше, но, по крайней мере, люди не сойдут с ума, пытаясь найти таблицу ManagerID или то, что EmployeeID там делает. При запросе WHERE я бы упростил его как: SELECT EmployeeID_Manager as ManagerID FROM Store

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

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

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

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

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

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

Под первым утверждением я подразумеваю, что вместо идентификатора вы можете использовать что-то другое, например recno. Таким образом, в этой таблице будет PK invoice_recno и так далее.

Привет, Бен

Я голосую за 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

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

В качестве имени столбца в базе данных я бы использовал «InvoiceID».

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

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

Если вы дадите каждому ключу уникальное имя, например «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 достаточно подробен, но не делает его более многословным.

Что я делаю, чтобы поддерживать единообразие для себя (когда таблица имеет один первичный ключ столбца, используемый в качестве идентификатора), так это называть первичный ключ таблицы 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

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

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

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

ВЫБЕРИТЕ first_name, last_name
ОТ CONTACT.NAMES
ГДЕ (is_alive = 'Истина')

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

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

Я ненавижу простое имя id. Я настоятельно предпочитаю всегда использовать invoice_id или его вариант. Я всегда знаю, какая таблица является авторитетной таблицей для идентификатора, когда мне нужно, но это меня смущает

SELECT * from Invoice inv, InvoiceLine inv_l where 
inv_l.InvoiceID = inv.ID 
SELECT * from Invoice inv, InvoiceLine inv_l where 
inv_l.ID = inv.InvoiceLineID 
SELECT * from Invoice inv, InvoiceLine inv_l where 
inv_l.ID = inv.InvoiceID 
SELECT * from Invoice inv, InvoiceLine inv_l where 
inv_l.InvoiceLineID = inv.ID 

Хуже всего то, что вы упомянули совершенно запутанную смесь. Мне приходилось работать с базой данных, где почти всегда это был foo_id, за исключением одного из наиболее часто используемых идентификаторов. Это был настоящий ад.

Я предпочитаю DomainName || 'МНЕ БЫ'. (т.е. DomainName + ID)

Имя домена часто, но не всегда, совпадает с именем таблицы.

Проблема с ID сама по себе в том, что он не масштабируется вверх. Когда у вас есть около 200 таблиц, каждая из которых имеет первый столбец с именем ID, данные начинают выглядеть одинаково. Если вы всегда уточняете идентификатор с именем таблицы, это немного помогает, но не сильно.

DomainName и ID могут использоваться для именования внешних ключей, а также первичных ключей. Когда внешние ключи названы в честь столбца, на который они ссылаются, это может иметь мнемоническую помощь. Формально связывать имя внешнего ключа с ключом, на который он ссылается, необязательно, так как ограничение ссылочной целостности устанавливает ссылку. Но это ужасно удобно, когда дело доходит до чтения запросов и обновлений.

Иногда DomainName || «ID» использовать нельзя, потому что в одной таблице будет два столбца с одинаковым именем. Пример: Employees.EmployeeID и Employees.SupervisorID. В этих случаях я использую RoleName || «ID», как в примере.

И последнее, но не менее важное: по возможности я использую естественные ключи, а не синтетические. Бывают ситуации, когда естественные ключи недоступны или ненадежны, но есть множество ситуаций, когда естественный ключ является правильным выбором. В таких случаях я позволяю естественному ключу взять то имя, которое у него естественно было бы. В этом имени часто даже нет букв «ID». Пример: OrderNo, где No - сокращение от «Number».

Для каждой таблицы я выбираю сокращение букв в виде дерева (например, Сотрудники => Emp)

Таким образом, числовой первичный ключ автонумерации становится nkEmp .

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

Я использую те же имена в SQL и на всех языках, которые я использую (в основном C #, Javascript, VB6).

См. Соглашения об именах на сайте Interakt для получения хорошо продуманной системы именования таблиц и столбцов. Этот метод использует суффикс для каждой таблицы ( _prdдля таблицы продуктов или _ctgдля таблицы категорий) и добавляет его к каждому столбцу данной таблицы. Таким образом, столбец идентификаторов для таблицы продуктов будет id_prdуникальным в базе данных.

Они делают еще один шаг, чтобы помочь понять внешние ключи: внешний ключ в таблице продуктов, который ссылается на таблицу категорий, будет idctg_prdтаким, чтобы было очевидно, к какой таблице он принадлежит ( _prdсуффикс) и к какой таблице он относится (категория) .

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

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

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

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

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

SELECT * FROM Invoice LEFT JOIN InvoiceLines ON inv_id = invl_inv_id