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


99

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

Если у меня есть таблица с именем 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, очевидно, какая таблица это находится на?

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


1
Ага, нас окружают люди с дурным вкусом! ;-)
Винко Врсалович


2
Как насчет выбора второго ответа в качестве « ответа »?
displayname

Ответы:


25

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


8
@ spencer7593, если вам нравится ID, это не значит, что это не антипаттерн. Когда у вас есть идентификатор tablename, труднее делать ошибки в соединениях, потому что вы сразу получите синтаксическую ошибку.
HLGEM

7
+1 Столбцы, которые являются синонимами, должны иметь одно и то же имя - с помощью префикса имени таблицы вы можете иметь столбец первичного ключа с именем table1ID и столбец внешнего ключа в другой таблице с именем table1ID - и вы ЗНАЕТЕ, что это одно и то же. Меня этому учили 20 лет назад, и эта практика не подведет.
amelvin

9
НЕТ! Это соглашение об именах смурфов!
Росс

19
Мне не нравится это соглашение, потому что оно просто означает, что вы практически вынуждены использовать псевдонимы для всех своих таблиц, чтобы не было избыточного именования таблицы, повторного именования таблицы, а затем добавления идентификатора. join table2 on table1.table1id = table2.table1id. Ваше рассуждение в порядке, за исключением того, что если вы используете идентификатор, имя таблицы в любом случае будет перед идентификатором. join table2 on table1.id = table2.table1id... который столь же подробен и не избыточен, ни заставляет неясные псевдонимы предотвращать только что упомянутую избыточность ... что, на мой взгляд, является проклятием разработки sql.
Anther

13
Затем, если у вас есть Nameполе в таблице, следует ли вам изменить его на, Table1Nameчтобы избежать тех же проблем с этим полем? Следует ли по той же причине ставить перед всеми столбцами префикс имени таблицы? Это звучит неправильно.
Joanvo

152

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

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


2
Я понимаю старую ветку, но согласен. Также упрощает сопоставление на уровне доступа к данным: если все «объекты» имеют поле Id, которое должно быть уникальным, то при создании методов на уровне доступа к данным для выполнения таких действий, как удаление элементов, вы можете сделать их универсальными, поскольку вы можете получить список Идентификаторы для чего угодно и знайте, что вам просто нужно удалить where Id = blah из этой конкретной таблицы, а не сохранять сопоставление того, что является уникальным для каждой таблицы, а также сопоставление имени таблицы / логического имени программы.
Майк

1
Кевин, такой же, как ты. например: user_id, role_id для PKey и role_user_id для FKey. Это хорошо для масштабного проекта. Потому что, если все поля ID имеют имя «id», это слишком запутанно. Но я думаю, что это личное предпочтение, кто-то думает, что использовать только «id» понятно.
Cheung

2
Это мое предпочтение. Тот факт, что запросы между таблицами труднее читать, не означает, что столбец Id должен быть изменен, чтобы упростить его. Просто сделайте свои псевдонимы более информативными.
tmutton 09

1
Я подозреваю, что соглашение об использовании префикса ID с именем объекта исходит от людей, использующих "select * from" по тем или иным причинам. В среде, допускающей «выбор *», реальность обычно искажается в сторону поддержки массового отбора всего отовсюду. В этом нет особого смысла, если не выбирать все вслепую. Также есть ссылки на ИСПОЛЬЗОВАНИЕ и естественные объединения, которые довольно опасны и также не выглядят для меня аргументом, потому что они эффективно мешают вам использовать соглашение об именах внешних ключей на основе ролей.
Роман Полунин

53

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

Например

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

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


2
За исключением того, что я никогда в жизни не встречал ни одного разработчика, который написал бы ваш пример. Вместо этого они пишут: LEFT JOIN Customers как c ON e.ID = c.EmployeeID Для меня это яснее: LEFT JOIN Customers как c ON e.EmployeeID = c.EmployeeID И какой элемент является внешним ключом, очевидно по имени таблицы . очевидно, что customer.employeeId - это внешний ключ, а employee.employeeId - нет.
dallin 06

8
Множеству людей (например, составителей отчетов, которые пишут очень сложные sql) и специалистов по бизнес-аналитике, выполняющих импорт и экспорт, по-прежнему необходимо писать SQl от руки. Дизайн базы данных должен учитывать и их, а не только разработчиков приложений.
HLGEM 07

30

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


Согласитесь, и вы укажете основную причину, по которой не следует использовать «id», потому что у нас всегда есть псевдоним таблицы, такой как «i» для inoice, p для «product» в SQL или LINQ и т. Д.
Cheung

3
Использование Id более уместно. В таблице есть столбец «счета-фактуры», так что этого должно хватить. Если вы пишете кросс-табличные запросы, вам следует использовать более описательные псевдонимы. «i» недостаточно. Назовите это «счетами».
tmutton 09

1
Неясно, что само по себе «ID» означает «Счета-фактуры». Предположим, у вас также есть внешние ключи для учетных записей и людей. Теперь какой из них "ID?" Разве в соединении не проще, скажем, прочитать a.InvoiceID = b.InvoiceID вместо a.ID = b.InvoiceID и не иметь возможности легко отладить его.
Джейсон Коэн

@JasonCohen Это просто означает, что псевдоним таблицы является мусором, а не имя столбца.
Джошуа Шлихтинг,

22

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

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

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

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


8
+1 для реального примера того, как универсальное именование улучшает повторное использование кода в конкретном случае (об этом позаботятся многие разработчики, поскольку существует миллионы разработчиков .NET, и многие будут использовать EF).
codingoutloud

В моей работе не только EF и тому подобное, у нас есть много общих методов. Таким образом, веб-сервис будет иметь что-то вроде List <Result> Save <T> (List <int> Ids); Поскольку мы знаем, что каждая таблица имеет столбец Id, который является первичным ключом, мы можем делать такие вещи, просто отображая объекты C # в их таблицы (что-то вроде <Customer, "Customers">, <BillingCode, "BillingCodes"> ( или, еще лучше, сохраненные имена процессов), генерируйте sql на лету на основе переданного объекта и вуаля никаких повторных методов сохранения / удаления / редактирования для каждого типа объекта.
Майк,

11

Я предпочитаю также 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 в целом - плохой выбор.


10

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

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


8

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

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


3
+1 для реального примера более конкретного имени, улучшающего ремонтопригодность.
codingoutloud

6

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


6

Я лично предпочитаю (как было сказано выше) 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


Я думаю, что ваша точка зрения хороша для красоты базы данных и дидактических целей, но для функциональности я думаю, что это проблема. Множественное число имен таблиц способствует несогласованности между таблицами, а PK Id <-> FK IdTable создает различия в именах одного и того же объекта. В то же время что-то вроде как- User.UserIdто странно набирать в программировании.
Machado

4

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


2

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

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

Привет, Бен


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

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


1

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

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

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


1

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


Вы знаете, поддерживает ли SQL Server естественное соединение?
Арри,

Я не думаю, что это так. Согласно connect.microsoft.com/SQLServer/feedback/… похоже, что этот синтаксис планируется добавить в какую-то версию после SQL Server 2005. Я знаю, что он работает в PostgreSQL и в Oracle.
Стивен Хьювиг,

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

1
хех, это похоже на звук из реальной жизни :)
dland

Я бы использовал естественное соединение только для специальных запросов.
Стивен Хьювиг,

1

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

1

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 = 'Истина')

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


0

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


0

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


1
Я слишком много раз читал слово «счет-фактура» в этом посте. Теперь это выглядит забавно
Кевин

2
Тьфу, неявное присоединение! Я хочу вырвать глаза, глядя на это.
HLGEM

0

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

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

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

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

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

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


0

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

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

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

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


0

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

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

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



-2

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

  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

5
ick! Я бы проголосовал против использования коротких псевдонимов для таблиц (или любого другого объекта). С псевдонимами вы никогда не узнаете точно, что такое короткое имя. Помните, есть много способов написать это неправильно; есть только один способ написать это правильно.
Джеймс Карран,

1
Джеймс, я не согласен. Если у вас короткое имя, которое не является описательным, и вы не можете вспомнить, что это, значит, вы выбрали неправильное имя или не понимаете соглашение об именах, которое выбрал кто-то другой.
kemiller2002,

2
Используйте псевдонимы для достижения того же эффекта. выберите * из Invoice inv left присоединиться к InvoiceLines invl на inv.ID = invl.InvoiceID
yfeldblum

2
Нет нет Нет Нет. псевдоним таблицы с аббревиатурой в запросе. Но имя таблицы должно быть полным.
Mesh

2
Почему так много программистов ленивы и кажется, что ответ на все - набирать как можно меньше просто потому, что слишком сложно набрать немного больше.
М.П.
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.