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

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

Я ненавижу простое имя 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, за исключением одного из наиболее часто используемых идентификаторов. Это был настоящий ад.

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

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

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

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

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

SELECT * FROM Invoice LEFT JOIN InvoiceLines ON inv_id = invl_inv_id

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

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

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

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

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

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

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

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

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

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

Ваше здоровье, Бен

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

Например.

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

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

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

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

Исходя из этого с точки зрения формального словаря данных, я бы назвал элемент данных 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. Обоснованием здесь является то, что домен - это `` фамилии людей '' и, скорее всего, будет UNIONed с last_name столбцами из других таблиц, а не будет использоваться в качестве внешнего ключа в другой таблицы, но опять же ... Я могу просто передумать , иногда никогда не скажешь. В том-то и дело: моделирование данных - это отчасти искусство, отчасти наука.

Я предпочитаю DomainName || 'Я БЫ'. (например, DomainName + ID)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 в качестве поля идентификатора, вероятность возникновения такой случайной ошибки гораздо меньше, и ее гораздо легче найти.

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

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

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

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

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

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

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

ТАК Как бы мое внутреннее ОКР это не ненавидело, я придерживаюсь соглашения TableID. Давайте вспомним, что он называется Data ОСНОВАНИЕ, так как он будет базой для многих будущих приложений. И все технологии должны иметь хорошо нормализованную с четким описанием схему.

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

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

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

  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 я бы упростил его как: ВЫБЕРИТЕ EmployeeID_Manager как ManagerID из магазина