Соглашения об именах баз данных, таблиц и столбцов? [закрыто]


791

Всякий раз, когда я проектирую базу данных, я всегда задаюсь вопросом, есть ли лучший способ присвоения имени элементу в моей базе данных. Довольно часто я задаю себе следующие вопросы:

  1. Должны ли имена таблиц быть множественными?
  2. Должны ли имена столбцов быть единичными?
  3. Должен ли я добавить префикс таблиц или столбцов?
  4. Должен ли я использовать какой-либо случай в наименовании предметов?

Существуют ли рекомендуемые рекомендации для именования элементов в базе данных?


7
Я думаю, что мы должны назвать множественное число для таблиц и единственное число для столбцов.
AZ_

7
Я вижу таблицу как «хранилище» с несколькими элементами, а не как одну «сущность», поэтому я называю ее множественным числом. Когда я отображал таблицы в объекты, я бы назвал объекты в единственном числе. Это всего лишь мое личное мнение.
дпл

2
@Tryinko Использование ID повсеместно - ЖИВОЙ АД для тех, кто делает соединения из нескольких таблиц. Нет никакого возможного способа, которым небольшое преимущество знания этого PK перевешивает невероятную досаду повторного наложения псевдонима dang ID в каждом кровавом запросе снова и снова. Если вам нужен способ обозначить PK в таблице, сделайте его первым столбцом. Кроме того, обозначение ФК в названиях столбцов, на мой взгляд, является еще одним совершенно злым антишаблоном.
ErikE

2
Посмотрите на этот ответ .
PerformanceDBA

Ответы:


315

Я рекомендую проверить примеры баз данных Microsoft SQL Server: https://github.com/Microsoft/sql-server-samples/releases/tag/adventureworks

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

  1. Особые имена для таблиц
  2. Особые имена для столбцов
  3. Имя схемы для префикса таблиц (например, SchemeName.TableName)
  4. Оболочка Паскаля (он же верхняя часть верблюда)

14
wilsonmar.com/sql_adventureworks.htm - это отличный анализ схемы AdventureWorks.
Даниэль Треббиен

209
Я бы не стал полагаться на Microsoft в отношении какого-либо стандарта - если вы посмотрите на их базу данных северного ветра, то увидите, что они используют множественные таблицы, имена столбцов в единственном числе, префиксы схем для таблиц, префиксы таблиц для столбцов первичных ключей, префиксы ограничений венгерского типа и худшие всех пространств "" для имен таблиц из нескольких слов. Кроме того, системные таблицы для SQLServer используют множественное число, поэтому кажется, что AdventureWorks был паршивой овцой в этой группе.
Маркус Папа

63
Я думаю, что главная проблема здесь в том, что толпа имен таблиц в единственном числе, кажется, рассматривает таблицу как сущность, а не строку в таблице, которую делает толпа множественного числа. Вы должны спросить себя, что это такое. Если таблица является просто контейнером строк, не логичнее ли использовать множественное именование? Вы никогда не назвали бы коллекцию в единственном числе кода, тогда почему бы вы назвали таблицу единственной? Почему несоответствие? Я слышу все аргументы о том, как они сортируются и используются в соединениях, но все они кажутся очень надуманными. Если все сводится к предпочтениям, я пойду с последовательностью и плюрализмом.
Джейсон

4
Также подумайте, в каком направлении идет прилив. Похоже, что он идет в направлении имен множественных таблиц, тем более что все системные таблицы в SQL Server являются множественными, а по умолчанию для Entity Framework используется множественное число из коробки. Если это позиция Microsoft, я хочу пойти в том направлении, в котором мы будем через 20 лет. Даже соглашения с базами данных Oracle говорят имена таблиц во множественном числе. Подумайте, сколько разработчиков на c # ненавидело ключевое слово «var», когда оно было введено, теперь это широко распространенный способ определения переменных.
Джейсон

7
@Jasmine - я вижу твою точку зрения, хотя я думаю, что ты случайно назвал свою таблицу примеров в обратном направлении. «TableOfInvoices» следует сократить до «Invoices», что я и предпочитаю. Вы, вероятно, вместо этого имели в виду «InvoiceTable», что имеет смысл сократить «Invoice».
Дерек

281

Поздний ответ здесь, но вкратце:

  1. Я предпочитаю множественное число
  2. да
  3. Таблицы : * Обычно * без префиксов лучше. Колонны : №
  4. Обе таблицы и столбцы: PascalCase.

Разработка:

(1) Что вы должны сделать. Есть очень мало вещей, которые вы должны делать определенным образом, каждый раз, но есть несколько.

  • Назовите ваши первичные ключи, используя формат «[singularOfTableName] ID». То есть, независимо от того, является ли ваша таблица именем Клиента или Клиентов , первичным ключом должен быть CustomerID .
  • Кроме того, внешние ключи должны называться последовательно в разных таблицах. Должно быть законно избивать кого-то, кто этого не делает. Я бы сказал, что хотя определенные ограничения внешнего ключа часто важны, согласованное именование внешнего ключа всегда важно
  • Ваша база данных должна иметь внутренние соглашения . Несмотря на то, что в последующих разделах вы увидите, что я очень гибок, в базе данных наименование должно быть очень последовательным. Называется ли ваша таблица для клиентов « Клиенты» или « Клиент» менее важно, чем то, как вы делаете это одинаково для всей базы данных. И вы можете перевернуть монету, чтобы определить, как использовать подчеркивание, но тогда вы должны продолжать использовать их так же . Если вы этого не сделаете, вы плохой человек, у которого должна быть низкая самооценка.

(2) Что вы, вероятно, должны делать.

  • Поля, представляющие данные одного типа в разных таблицах, должны называться одинаково. Не используйте Zip на одном столе и ZipCode на другом.
  • Чтобы разделить слова в именах таблиц или столбцов, используйте PascalCasing. Использование camelCasing само по себе не будет проблематичным, но это не соглашение, и это будет выглядеть забавно. Я обращусь к подчеркиваниям через минуту. (Вы не можете использовать ALLCAPS, как в прежние времена. OBNOXIOUSTABLE.ANNOYING_COLUMN в DB2 было хорошо 20 лет назад, но не сейчас.)
  • Не сокращайте искусственно и не сокращайте слова. Лучше, чтобы имя было длинным и ясным, чем коротким и запутанным. Сверхкороткие имена - пережиток более мрачных и диких времен. Cus_AddRef. Что это такое? Ссылка на адрес получателя? Клиент Дополнительный возврат? Пользовательский адрес реферала?

(3) Что вы должны рассмотреть.

  • Я действительно думаю, что вы должны иметь множественные имена для таблиц; некоторые думают единственное число. Прочитайте аргументы в другом месте. Однако имена столбцов должны быть единственными. Даже если вы используете множественные имена таблиц, таблицы, представляющие комбинации других таблиц, могут быть в единственном числе. Например, если у вас есть Акции и предметы таблица « , то таблица, представляющая элемент, являющийся частью рекламной акции, может быть Promotions_Items, но я думаю, что она также вполне может быть Promotion_Items (отражая отношение «один ко многим»).
  • Используйте подчеркивание последовательно и для определенной цели. Просто общие имена таблиц должны быть достаточно понятны с помощью PascalCasing; вам не нужно подчеркивание, чтобы отделить слова. Сохраните подчеркивания либо (a), чтобы указать ассоциативную таблицу, либо (b) для префикса, о котором я расскажу в следующем пункте.
  • Префикс ни хорошо, ни плохо. Это обычно не лучше. В вашей первой БД или двух я бы не советовал использовать префиксы для общей тематической группировки таблиц. Таблицы в конечном итоге не соответствуют вашим категориям, и на самом деле это может затруднить поиск таблиц. Имея опыт, вы можете планировать и применять схему префиксов, которая приносит больше пользы, чем вреда. Однажды я работал в БД, где таблицы данных начинались с tbl , таблицы конфигурации с ctbl , представления с vew , sp процедуры proc и udf's fnи несколько других; это было тщательно, последовательно применено, таким образом, это работало хорошо. Единственный раз, когда вам НУЖНЫ префиксы, это когда у вас действительно отдельные решения, которые по какой-то причине находятся в одном и том же БД; их префикс может быть очень полезен при группировке таблиц. Префикс также подходит для особых ситуаций, например для временных таблиц, которые вы хотите выделять.
  • Очень редко (если вообще когда-либо) вы захотите добавить префиксы к столбцам.

11
«Поля, представляющие данные одного и того же типа в разных таблицах, должны иметь одинаковые имена. Не используйте Zip для одной таблицы и ZipCode для другой». Да да миллион раз да Можете ли вы сказать, что наша база данных не была разработана таким образом? К персону можно обращаться любым из дюжины различных способов, очень раздражающих в поддержании. Я всегда придерживался этого правила в любой базе данных, которую контролировал при проектировании, и это значительно упрощает жизнь.
HLGEM

87
Я думаю, что первичный ключ должен быть просто «ID». Такое простое соглашение делает первичный ключ предсказуемым и быстро идентифицируемым. Однако я бы добавил имя таблицы («PersonID»), когда она используется в качестве внешнего ключа в других таблицах. Это соглашение может помочь различить первичный ключ и внешний ключ в одной таблице.
Triynko

55
@Tryinko Использование ID повсеместно - ЖИВОЙ АД для тех, кто делает соединения из нескольких таблиц. Нет никакого возможного способа, которым небольшое преимущество знания этого PK перевешивает невероятную досаду повторного наложения псевдонима dang ID в каждом кровавом запросе снова и снова. Если вам нужен способ обозначить PK в таблице, сделайте его первым столбцом. Кроме того, обозначение ФК в названиях столбцов, на мой взгляд, является еще одним совершенно злым антишаблоном.
ErikE

18
@Triynko, если вы используете только «ID», также невозможно определить, к какой таблице он принадлежит. С префиксом имени таблицы вы можете просто отрезать последние две цифры первичного ключа и узнать имя таблицы, к которой он принадлежит, с помощью кода. Часто ИТ-специалисты и администраторы баз данных не осознают, что для программистов есть определенные преимущества в разработке баз данных определенными способами.
Даллин

16
@ErikE Я имею в виду, что вы не знаете, CustomerIDявляется ли первичный ключ из Customerтаблицы или внешний ключ в какой-либо другой таблице. Это небольшая проблема. Почему вы хотите использовать плохие имена, как c? CustomerID = Customer.IDочень ясно, что вы видите, что вы соединяете внешний ключ с первичным ключом; это не избыточно, так как две стороны - это две разные вещи. Одноименное именование - плохая практика IMO.
Дейв Кузино

100

Хорошо, так как мы взвешиваем мнение:

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

Для тех, кому нравится видеть в запросах единичные «имена сущностей», я бы использовал псевдонимы таблиц для:

SELECT person.Name
FROM People person

Немного похоже на LINQ "от человека в человеке выберите person.Name".

Что касается 2, 3 и 4, я согласен с @Lars.


17
@Emtucifor: На английском мы не говорим: «Посмотрите на всех людей в этой толпе!» Следует ожидать наличия концептуальной проблемы с множественными вещами, на которые ссылается единственное слово. Это не нормально и не правильно. «Данные» являются исключительными и часто используются для обозначения части объема вещества, очень похожего на «пирог». "Хочешь (кусок) торта?" Называть таблицу «Люди», потому что она содержит информацию о нескольких лицах, имеет гораздо больший смысл, чем называть ее «Персона». Класс данных с именем "Person" для ROW имеет смысл, как и имена столбцов в единственном числе.
Triynko

6
@Emtucifor: В конечном итоге весь язык является произвольным и условным. Я просто утверждал, что условно мы называем коллекцию предметов множественным числом по типу предмета в нем. Таким образом, коллекция строк, в которой каждая строка содержит информацию об одном человеке, будет представлена ​​как группа людей. Но если вы хотите сослаться на это как на личность, идите вперед.
Трийнко

3
@Emtucifor: Да, лол. Присвоение имени таблице «PersonCollection» будет эквивалентно присвоению ей имени «Люди». Противопоставьте, что с именованием такой коллекции просто «Персона», что не имеет смысла :)
Triynko

4
@Emtucifor: Тогда давайте подумаем об этом с другой стороны, чтобы поместить соглашение об именах в контекст. Предположим, у вас есть классы объектов для представления как строки, так и таблицы. «Человек», очевидно, имеет смысл для класса, представляющего ряд данных. Если ваша таблица также называется «Персона», то у вас может возникнуть конфликт имен или некоторая путаница. Я просто думаю, что более разумно называть объекты точным множеством. Строка с данными о человеке должна называться Person, а таблица с информацией о людях или нескольких лицах называется People, PersonCollection, Persons и т. Д.
Triynko,

5
@ Джош М. Ну, ни в коем случае. Если вы пойдете по моему пути, вы можете создать псевдоним таблицы People как «персона» и выбрать SELECT person.Name. Задача решена. ;-)
Мэтт Гамильтон

73

Я работаю в группе поддержки баз данных с тремя администраторами баз данных, и мы рассматриваем следующие варианты:

  1. Любой стандарт именования лучше, чем не стандарт.
  2. Не существует «одного истинного» стандарта, у всех нас есть свои предпочтения
  3. Если стандарт уже есть, используйте его. Не создавайте другой стандарт и не запутывайте существующие стандарты.

Мы используем единственные имена для таблиц. Таблицы обычно имеют префикс с названием системы (или ее аббревиатурой). Это полезно, если система сложна, так как вы можете изменить префикс для логической группировки таблиц (т.е. reg_customer, reg_booking и regadmin_limits).

Для полей мы ожидаем, что имена полей будут включать префикс / acryonm таблицы (то есть cust_address1), и мы также предпочитаем использовать стандартный набор суффиксов (_id для PK, _cd для «code», _nm для «name» ", _nb для" числа ", _dt для" даты ").

Имя поля ключа Foriegn должно совпадать с полем первичного ключа.

т.е.

SELECT cust_nm, cust_add1, booking_dt
FROM reg_customer
INNER JOIN reg_booking
ON reg_customer.cust_id = reg_booking.cust_id

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


9
Специально для номера 3 у нас была группа людей, которых всех наняли из одной компании, и они пытались навязать свой старый стандарт именования (которым никто из нас не пользовался) во всем, что они делали. Очень назойливый.
HLGEM

40
Конечно, делает SQL нечитаемым; но я думаю, что могу перевести. cust_nm должен быть CustomerName , booking_dt должен быть BookingDate . reg_customer, ну я понятия не имею, что это такое.
Ян Бойд

3
@Ian. Намерение состоит в том, чтобы вы придерживались соглашения об именах, к которому вы привыкли, и придерживались его. Я ВСЕГДА знаю, что любое поле даты - _dt, любое поле имени - _nm. 'reg' - это пример системы "регистрации" (бронирования, клиенты и т. д.), и все связанные таблицы будут иметь одинаковый префикс. Но каждый по-своему ...
Парень

7
Я согласен, что определенный стандарт не так важен, как наличие последовательного стандарта. Но некоторые стандарты неверны. DB2 и имена столбцов, такие как CSPTCN, CSPTLN, CSPTMN, CSDLN. Люди должны понять, что были изобретены длинные имена - мы можем позволить себе читать вещи.
Ян Бойд

17
На протяжении многих лет я добавлял новые столбцы в конце своих таблиц в приложении, которое разработал и продал. Иногда я использую английские имена в своих столбцах, иногда я использую испанский, а иногда я использую столбцы для чего-то другого, вместо того, чтобы удалить их и добавить новый столбец с подходящим описательным именем для того, что оно используется. Я специально сделал это, чтобы ОБОСНОВАТЬ мой исходный код на случай, если кто-то еще попытается взломать или перепроектировать мой код. Только я могу понять это, кто-то еще расстроится! .. Таким образом, они всегда должны полагаться на меня во всем!
Франк Р.

47
  1. Нет. Таблица должна быть названа в честь сущности, которую она представляет. Личность, а не личность - это то, как вы относитесь к тому, кого представляет одна из записей.
  2. Опять то же самое. Столбец FirstName действительно не должен называться FirstNames. Все зависит от того, что вы хотите представить в колонке.
  3. NO.
  4. Да. Случай для ясности. Если вам нужно иметь столбцы типа «FirstName», регистр облегчит чтение.

Хорошо. Это мой $ 0,02


5
Добавление ясности к номеру 3 - префиксы - это способ встраивания метаданных в имя столбца. Не должно быть необходимости делать это в любой современной БД по тем же причинам, что и (чрезмерное использование) венгерской нотации.
Марк Макдональд

21
`выбрать топ 15 из заказа 'или" выбрать топ 15 из заказа "? Последнее мое (человеческое) предпочтение.
Ян Бойд

8
@Ian Boyd: Да: ВЫБЕРИТЕ ТОП-100 * ИЗ ОТЧЕТА R ВНУТРЕННЕЕ РЕШЕНИЕ VisitReport VR ON R.ReportID = VR.ReportID. Все зависит от того, как вы об этом думаете. Если вы поместите изображение лимона на канистру, вы будете знать, что внутри были лимоны, без необходимости использовать два лимона снаружи, чтобы указать, что это может быть множественное число. Конечно, вы можете пометить его с письменным словом «лимоны». Но это может быть и «лимон». Чтобы приобрести ресурс под названием «лимон», перейдите сюда.
ErikE

6
добавьте $ 0,01 для использования UpperCase в именах столбцов и добавьте еще $ 0,01 для использования подчеркивания в именах столбцов, чтобы было легче различать имена столбцов на виду. Итого = мои $ 0,02 пожертвования для вас!
Франк Р.

6
«Таблица должна быть названа в честь сущности, которую она представляет» Таблица - это совокупность сущностей. Хотя таблица также является сущностью, она является сущностью типа «Таблица», которую бессмысленно добавлять к ее имени.
Trisped

34

Я также поддерживаю соглашение об именовании в стиле ISO / IEC 11179, отмечая, что они являются скорее рекомендациями, чем предписаниями.

Смотрите имя элемента данных в Википедии :

«Таблицы являются коллекциями сущностей и следуют рекомендациям по присвоению имен коллекциям. В идеале используется коллективное имя: например,« Персонал ». Множество также правильно: сотрудники. Неправильные имена включают: Employee, tblEmployee и EmployeeTable».

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


-1: ссылочный текст не имеет ничего общего с ИСО / МЭК 11179. Ссылочной странице википедии нельзя доверять; Вместо этого прочитайте действующий стандарт ( metadata-standards.org/11179/#A5 )
mkadunc

@onedaywhen: я не знаю достаточно о предмете, чтобы исправить страницу википедии; Кроме того, страница википедии не столько ошибочна, сколько вводит в заблуждение - она ​​прямо не говорит о том, что ИСО / МЭК 11179 включает в себя соглашения об именах баз данных, она просто говорит, что «ИСО / МЭК 11179 применима, когда называются таблицы и столбцы внутри реляционная база данных ". Затем он приводит пример соглашений об именах, которые могут использоваться для реляционной базы данных. Это позволяет вам думать, что пример взят из стандарта, тогда как на самом деле он составлен автором статьи в Википедии.
mkadunc

27

Я все время слышу аргумент о том, является ли таблица множественной или нет, все зависит от личного вкуса, и наилучшей практики не существует. Я не верю, что это правда, особенно как программист, а не администратор баз данных. Насколько мне известно, нет никаких законных причин для множественного числа имен таблиц, кроме «Это просто имеет смысл для меня, потому что это набор объектов», в то время как в коде есть законные выгоды от наличия имен таблиц в единственном числе. Например:

  1. Это позволяет избежать ошибок и ошибок, вызванных множественной неопределенностью. Программисты не совсем известны своим опытом в написании, и некоторые слова вводят в заблуждение. Например, множественное число заканчивается на «эс» или просто «с»? Это люди или люди? Когда вы работаете над проектом с большими командами, это может стать проблемой. Например, экземпляр, в котором член команды использует неправильный метод для создания таблицы, которую он создает. К тому времени, когда я взаимодействую с этой таблицей, она используется повсюду в коде, к которому у меня нет доступа, или исправление займет слишком много времени. В результате я должен помнить, что каждый раз, когда я его использую, пишется неправильно. Что-то очень похожее на это случилось со мной. Чем проще вы сможете сделать для каждого члена команды последовательное и простое использование точного, исправляйте имена таблиц без ошибок или необходимости постоянно искать имена таблиц, тем лучше. Единственная версия намного проще в командной среде.

  2. Если вы используете единственную версию имени таблицы И добавляете префикс первичного ключа к имени таблицы, у вас теперь есть преимущество в простом определении имени таблицы из первичного ключа или наоборот только с помощью кода. Вам может быть задана переменная с именем таблицы, конкатенировать «Id» до конца, и теперь у вас есть первичный ключ таблицы через код, без необходимости делать дополнительный запрос. Или вы можете обрезать «Id» в конце первичного ключа, чтобы определить имя таблицы с помощью кода. Если вы используете «id» без имени таблицы для первичного ключа, то вы не сможете с помощью кода определить имя таблицы из первичного ключа. Кроме того, большинство людей, которые множат имена таблиц и префикс столбцов PK с именем таблицы, используют единственную версию имени таблицы в PK (например, statuses и status_id),

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

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

Подводя итог, можно сказать, что при множественном использовании имен таблиц вы теряете всевозможные преимущества, которые делают ваш код более умным и простым в обращении. Могут даже быть случаи, когда вам нужны таблицы / массивы для преобразования имен таблиц в объектные или локальные кодовые имена, которых вы могли бы избежать. Имена таблиц в единственном числе, хотя поначалу, возможно, и кажутся немного странными, предлагают значительные преимущества по сравнению с множественными именами, и я считаю, что это лучшая практика.


26

наше предпочтение:

  1. Должны ли имена таблиц быть множественными?
    Никогда. Аргументы в пользу того, что это коллекция, имеют смысл, но вы никогда не знаете, что будет содержать таблица (0,1 или много элементов). Множественные правила делают излишне сложным именование. 1 дом, 2 дома, мышь против мышей, человек против людей, и мы даже не смотрели на другие языки.

    Update person set property = 'value'действует на каждого человека в таблице.
    Select * from person where person.name = 'Greg'возвращает коллекцию / набор строк строк

  2. Должны ли имена столбцов быть единичными?
    Обычно да, кроме случаев, когда вы нарушаете правила нормализации.

  3. Должен ли я добавить префикс таблиц или столбцов?
    Главным образом предпочтение платформы. Мы предпочитаем префикс столбцов с именем таблицы. Мы не префикс таблиц, но мы делаем префиксы представлений (v_) и сохраненных_процедур (sp_ или f_ (функция)). Это помогает людям, которые хотят попробовать обновить v_person.age, который на самом деле является вычисляемым полем в представлении (которое все равно не может быть ОБНОВЛЕНО).

    Это также отличный способ избежать столкновения ключевых слов (delivery.from прерывается, но delivery_from - нет).

    Это делает код более многословным, но часто способствует удобочитаемости.

    bob = new person()
    bob.person_name = 'Bob'
    bob.person_dob = '1958-12-21'
    ... очень читабельно и явно. Это может выйти из-под контроля, хотя:

    customer.customer_customer_type_id

    указывает на связь между customer и таблицей customer_type, указывает первичный ключ в таблице customer_type (customer_type_id), и, если вы когда-либо увидите «customer_customer_type_id» во время отладки запроса, вы сразу узнаете, откуда он (таблица customer).

    или если у вас есть отношение MM между customer_type и customer_category (для определенных категорий доступны только определенные типы)

    customer_category_customer_type_id

    ... немного (!) на длинной стороне.

  4. Должен ли я использовать какой-либо случай в наименовании предметов? Да - нижний регистр :), с подчеркиванием. Они очень читабельны и кроссплатформенны. Вместе с 3 выше это также имеет смысл.

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


1
SELECT * FROM people AS person WHERE person.name = 'Greg'звучит наиболее естественно для меня.
Кенмор

1
@Zuko В основном, соглашение об именах для первичного ключа таблицы <table name><id>, например, PersonIDи Person_IDт. Д. Поэтому имеет больше смысла, чтобы вы НЕ называли свои таблицы множественным числом, поскольку каждая запись - это отдельный человек, а не люди.
Мистер Блонд,

20

Взгляните на ISO 11179-5: принципы именования и идентификации. Вы можете получить его здесь: http://metadata-standards.org/11179/#11179-5

Я уже писал об этом здесь: ISO-11179 Условные обозначения


19
Ваш ответ был бы более доступным (= лучше), если бы вы дали резюме здесь. Отличный указатель!
Ола Элдой

15

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

Все столбцы должны иметь имена с префиксом, уникальным для таблицы, в которой они определены.

Например, учитывая таблицы "customer" и "address", давайте перейдем с префиксами "cust" и "addr" соответственно. «customer» будет содержать «cust_id», «cust_name» и т. д. «address» будет содержать «addr_id», «addr_cust_id» (FK назад to customer), «addr_street» и т. д.

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

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

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

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

Другое, относительно незначительное преимущество, это то, что вам нужно использовать псевдонимы таблиц только при самостоятельном объединении:

SELECT cust_id, cust_name, addr_street, addr_city, addr_state
    FROM customer
        INNER JOIN address ON addr_cust_id = cust_id
    WHERE cust_name LIKE 'J%';

1
Тогда ты больше не можешь reliably find every line of code that touches a particular column... Разве не в этом смысл?
raveren

6
@Raveren - Ты все еще можешь. Если все, что вы делаете, это «SELECT *», то запрос для этой цели не имеет значения. Когда / если позже вы используете результаты этого запроса, вы должны использовать имя столбца, чтобы что-то делать с его данными, так что это место, о котором вам нужно беспокоиться в вашем коде, а не оператор SQL.
Грейнджер

Мне будет любопытно, в каких ситуациях требуется SELECT *? Я, конечно, не хотел бы, чтобы кто-нибудь использовал это в рабочем коде. Да, это полезно для специальных запросов и для выяснения того, какая часть данных делает ваши результаты запроса на множественное объединение странными, но я не могу представить себе места в рабочем коде, где это требуется.
HLGEM

2
Если вы не программируете все свое приложение на языке, отличном от OO, то наличие достойного слоя ORM делает этот аргумент избыточным.
Адам

6
Поэтому из-за этого ответа я решил попробовать использовать префиксы таблиц в большом проекте и решил отчитаться. Это действительно сделало рефакторинг таблиц чрезвычайно простым, что было здорово! Тем не менее, это была большая боль, чем я ожидал. В нашей базе данных было много сложных именованных таблиц. Легко запомнить, что Cust является префиксом для Customer, но не так легко запомнить префикс для HazardVerificationMethod. Каждый раз, когда я писал таблицу или поле, мне приходилось делать паузу, чтобы подумать о префиксе. В конце концов я решил, что скорость и удобство важнее поиска, но я чувствовал, что это ценный опыт.
Даллин

15

Мои мнения по этим вопросам:

1) Нет, имена таблиц должны быть в единственном числе.

Хотя кажется, что это имеет смысл для простого selection ( select * from Orders), он имеет меньше смысла для OO-эквивалента ( Orders x = new Orders).

Таблица в БД на самом деле является набором этой сущности, это имеет смысл, когда вы используете set-logic:

select Orders.*
from Orders inner join Products
    on Orders.Key = Products.Key

Эта последняя строка, фактическая логика объединения, выглядит запутанной с именами таблиц во множественном числе.

Я не уверен в том, что всегда использовать псевдоним (как предлагает Мэтт) проясняет ситуацию.

2) Они должны быть единственными, поскольку они имеют только 1 свойство

3) Никогда, если имя столбца является неоднозначным (как указано выше, где у них обоих есть столбец с именем [Key]), то имя таблицы (или ее псевдоним) может различить их достаточно хорошо. Вы хотите, чтобы запросы были быстрыми и простыми - префиксы добавляли ненужную сложность.

4) Все, что вы хотите, я бы предложил CapitalCase

Я не думаю, что есть один набор абсолютных рекомендаций по любому из них.

Пока все, что вы выбираете, является единым для всего приложения или БД, я не думаю, что это действительно имеет значение.


3
Что за хрень CapitalCase?
ВИРУСТРИНИКА

@ViRuSTriNiTy он, вероятно, имел в видуpascal case
marctrem

Кит, под номером 3 я делаю и то и другое, и я непоследователен (но я отвлекся), но я не понимаю, почему плохо иметь имя описательного столбца, если оно не за бортом, то же самое с таблицей, переменная и т. д.
Джонни

@ Джонни, это не плохо, просто так не нужно. Зачем печатать вещи, которые вам не нужны? Кроме того, большинство intellisense в основном использует начало имени, поэтому, если у вас есть Product.ProductName, Product.ProductIDи Product.ProductPriceт.д., ввод Product.Pдает вам все поля с префиксом.
Кит

13

По моему мнению:

  1. Имена таблиц должны быть во множественном числе.
  2. Имена столбцов должны быть единственными.
  3. Нет.
  4. Либо CamelCase (мой выбор), либо underscore_separated для имен таблиц и столбцов.

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


1
относительно # 4, PascalCase ... camelCase ... snake_case ...
Эндрю

11

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

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

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

На всякий случай вот мои ответы:

  1. Да. Таблица - это группа записей , учителей или актеров , так что ... во множественном числе.
  2. Да.
  3. Я ими не пользуюсь.
  4. База данных, которую я использую чаще всего - Firebird - хранит все в верхнем регистре, поэтому это не имеет значения. В любом случае, когда я программирую, я пишу имена так, чтобы их было легче читать, например, releaseYear .

11
  1. Определенно держите имена таблиц в единственном числе, человек не люди
    1. Тоже самое
    2. Нет. Я видел несколько ужасных префиксов, дошедших до того, что они утверждают, что имеют дело с таблицей (tbl_) или процедурой пользовательского хранилища (usp_). Затем следует имя базы данных ... Не делайте этого!
    3. Да. Я склонен PascalCase все мои имена таблиц

28
О, МОЙ БОГ. NO. Имена таблиц ОПРЕДЕЛЕННО во множественном числе. Это коллекция. В нем есть несколько вещей. "выбрать * из людей". Вы выбираете не одного человека, а нескольких людей!
Triynko

4
Мне всегда нравилось, как выражение select звучит лучше, если оно множественное. SELECT id,name FROM contacts WHERE email_address LIKE '%gmail%'таблицы множественного числа, столбцы единственного числа. Опять же всегда вопрос личного мнения.
scunliffe

Префикс tbl, qry и т. д. может быть чрезвычайно полезен при обработке метаданных базы данных. Если вы проверяете объект в базе данных, имея быстрое и простое соглашение об именах, это может значительно ускорить понимание
Cruachan

9

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

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

Вот мои ответы:

  1. Да, имена таблиц должны быть множественными, когда они относятся к набору сделок , ценных бумаг или контрагентов .
  2. Да.
  3. Да. Таблицы SQL имеют префикс tb_, представления - префикс vw_, хранимые процедуры - префикс usp_, а триггеры - префикс tg_, за которым следует имя базы данных.
  4. Имя столбца должно быть в нижнем регистре, разделенных подчеркиванием.

Присвоение имен сложно, но в каждой организации есть кто-то, кто может называть вещи, и в каждой команде разработчиков программного обеспечения должен быть кто-то, кто берет на себя ответственность за стандарты именования и гарантирует, что проблемы именования, такие как sec_id , sec_value и security_id, будут решены раньше, чем они попадут в проект. ,

Итак, каковы основные принципы хорошего соглашения об именах и стандартов:

  • Используйте язык вашего клиента и вашего домена решения
  • Быть описательным
  • Быть последовательным
  • Устранение неоднозначности, отражение и рефакторинг
  • Не используйте сокращения, если они не понятны всем
  • Не используйте зарезервированные ключевые слова SQL в качестве имен столбцов

3
таблицы по определению отношения. которые на самом деле единичны. префиксы отстой. Вам когда-нибудь нужно было преобразовать таблицу в представление или наоборот? попробуйте это с префиксами. какая разница, если это представление или таблица?
Уильям Джонс

Префикс может помочь, когда у нас одно и то же имя для двух объектов - функции и хранимой процедуры. Я хотел бы иметь функцию с именем «GetApproverList» и с тем же именем, я хотел бы создать хранимую процедуру, которая будет вызывать эту функцию внутри. Sql не позволит создавать два объекта с одинаковыми именами.
Равиндер Сингх


7
SELECT 
   UserID, FirstName, MiddleInitial, LastName
FROM Users
ORDER BY LastName

2
Обратите внимание на используемые стандарты: таблицы содержат несколько вещей, пользователи имеют одно имя, ключевые слова T-SQL в верхнем регистре, определения таблиц в регистре Pascal.
Ян Бойд

3
опечатка: Lastnameдолжно бытьLastName
аминималанимал

1
Имя таблицы должно быть единичным, то есть: Пользователь вместо Пользователей
AZ_

И обратите внимание, как имена таблиц во множественном числе; поскольку они содержат пользователей , а не пользователей .
Ян Бойд

5

Имена таблиц всегда должны быть единичными, потому что они представляют собой набор объектов. Как вы говорите, стадо, чтобы обозначить группу овец или стадо, определите группу птиц. Нет необходимости во множественном числе. Когда имя таблицы составлено из двух имен, а соглашение об именах - во множественном числе, становится трудно понять, должно ли множественное имя быть первым словом или вторым словом, или и тем, и другим. Это логика - Object.instance, а не objects.instance. Или TableName.column, а не TableNames.column (s). Microsoft SQL не чувствителен к регистру, проще читать имена таблиц, если используются заглавные буквы, для разделения имен таблиц или столбцов, когда они состоят из двух или более имен.


2
Стадо - это группа овец . А Userэто не группа пользователей.
EricRobertBrewer

4

Имя таблицы: оно должно быть единичным, так как это единичная сущность, представляющая объект реального мира, а не объекты, которые являются единичными.

Имя столбца: оно должно быть единственным, только тогда оно сообщает, что будет иметь атомное значение и подтвердит теорию нормализации. Однако, если существует n свойств одного и того же типа, к ним следует добавить суффикс 1, 2, ..., n и т. Д.

Таблицы / столбцы с префиксами: это огромная тема, о которой мы поговорим позже.

Корпус: это должен быть чехол для верблюда

Мой друг Патрик Керхер , прошу вас не писать ничего, что может кого-то оскорбить, как вы написали: «• Кроме того, внешние ключи должны называться последовательно в разных таблицах. Должно быть законно избивать кого-то, кто этого не делает. сделай это.". Я никогда не делал эту ошибку, мой друг Патрик, но я пишу в целом. Что если они вместе планируют побить тебя за это? :)


2
То есть, вы говорите, что таблица - это сущность? Или строка в таблице является сущностью? Для меня таблица - это набор строк, следовательно, набор сущностей, который подразумевает множественное число.
Джейсон

4

Очень поздно на вечеринку, но я все еще хотел добавить свои два цента о префиксах столбцов

Кажется, есть два основных аргумента для использования стандарта именования столбцов table_column (или tableColumn) для столбцов, оба основаны на том факте, что само имя столбца будет уникальным во всей вашей базе данных:

1) Вам не нужно постоянно указывать имена таблиц и / или псевдонимы столбцов в своих запросах

2) Вы можете легко найти весь код для имени столбца

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

Всегда используйте имя таблицы в вашем SQL. Например, всегда используйте table.column вместо column.

Это, очевидно, решает 2), так как теперь вы можете просто искать table.column вместо table_column.

Но я слышу, как ты кричишь, как это решает 1)? Именно о том, чтобы избежать этого. Да, это так, но решение было ужасно ошибочным. Почему? Что ж, префиксное решение сводится к следующему:
чтобы избежать необходимости указывать table.column при неоднозначности, вы называете все свои столбцы table_column!
Но это означает, что отныне вам ВСЕГДА придется писать имя столбца каждый раз, когда вы указываете столбец. Но если вам все равно придется это делать, какая выгода по сравнению с тем, чтобы всегда явно писать table.column? Точно, нет никакой выгоды, это то же самое количество символов для ввода.

изменить: да, я знаю, что присвоение имен столбцам с префиксом обеспечивает правильное использование, тогда как мой подход опирается на программистов


1
Как вы упомянули, вы не можете полагаться на каждый случай, имеющий table.column. Программисты забудут в одном месте, и тогда ваш глобальный поиск и замена просто сломали всю вашу программу. Или вы сделаете это правилом, и кто-то подумает, что он выполняет это правило, используя псевдоним таблицы, что опять-таки помешает глобальному поиску. Кроме того, если вы хотите организовать свой код, имея некоторый класс базы данных (что любой хороший программист сделает), будут случаи, когда вы просто передадите имя столбца в функцию db или просто будете иметь имя только одного столбца в Переменная.
Даллин

2
@janb: я полностью поддерживаю твой ответ. Я также хочу добавить, что использование текстового поиска для поиска зависимостей является варварским способом навигации по коду. Как только люди избавятся от этой практики поиска варваров - они начнут использовать хорошее именование, которое называется table.column. Так что проблема не в стиле именования, проблема в плохих инструментах, созданных для варваров.
alpav

Ваш аргумент неверен. Проблема в том, что он работает в обе стороны и не добавляет никаких преимуществ. Вы говорите, чтобы решить это, просто всегда пишите table.column, так как вы уже пишете table_column. Ну, вы также можете сказать просто написать table_column, потому что вы уже пишете table.column. Другими словами, между вашим ответом нет никакой разницы, кроме того, что он вносит возможные ошибки и не обеспечивает соблюдения соглашений. По этой причине у нас есть «частное» ключевое слово. Мы могли бы доверять программистам, чтобы они всегда правильно использовали переменные класса, но ключевое слово применяет их и исключает возможные ошибки.
Даллин

3

Основные соглашения об именах баз данных (и стиль) (нажмите здесь для более подробного описания)

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


1
хотя то, что Oracle предлагает, это совершенно противоположно ссылке на линке выше. узнайте, что говорит Oracle здесь .. ss64.com/ora/syntax-naming.html
AZ_


Соглашение об именах Oracle было самым смешным из них .. e.g. PATIENTS would have a primary key called pa_patient_id_pk!!
nawfal

2

Названия таблиц в единственном числе. Допустим, вы моделировали отношения между кем-то и его адресом. Например, если вы читаете модель данных, вы бы предпочли, чтобы «каждый человек мог жить по 0,1 или нескольким адресам». или «каждый человек может жить по 0,1 или многим адресам». Я думаю, что это проще для множественного адреса, чем перефразировать людей как личность. Плюс собирательные существительные довольно часто не употребляются в единственном числе.


-4

--Example SQL

CREATE TABLE D001_Students
(
    StudentID INTEGER CONSTRAINT nnD001_STID NOT NULL,
    ChristianName NVARCHAR(255) CONSTRAINT nnD001_CHNA NOT NULL,
    Surname NVARCHAR(255) CONSTRAINT nnD001_SURN NOT NULL,
    CONSTRAINT pkD001 PRIMARY KEY(StudentID)
);

CREATE INDEX idxD001_STID on D001_Students;

CREATE TABLE D002_Classes
(
    ClassID INTEGER CONSTRAINT nnD002_CLID NOT NULL,
    StudentID INTEGER CONSTRAINT nnD002_STID NOT NULL,
    ClassName NVARCHAR(255) CONSTRAINT nnD002_CLNA NOT NULL,
    CONSTRAINT pkD001 PRIMARY KEY(ClassID, StudentID),
    CONSTRAINT fkD001_STID FOREIGN KEY(StudentID) 
        REFERENCES D001_Students(StudentID)
);

CREATE INDEX idxD002_CLID on D002_Classes;

CREATE VIEW V001_StudentClasses
(
    SELECT
        D001.ChristianName,
        D001.Surname,
        D002.ClassName
    FROM
        D001_Students D001
            INNER JOIN
        D002_Classes D002
            ON
        D001.StudentID = D002.StudentID
);

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

  1. Множественное число. Это коллекция сущностей.
  2. Да. Атрибут является представлением единственного свойства сущности.
  3. Да, префикс имени таблицы позволяет легко отслеживать имена всех индексов ограничений и псевдонимов таблиц.
  4. Pascal Case для имен таблиц и столбцов, префикс + ALL caps для индексов и ограничений.

6
ChristianName ... это странное соглашение.
BobbyShaftoe

3
Серийные номера на ваших столах? Кто - нибудь серьезно думает , что это имеет смысл работу для разработчиков?
ErikE

Так как этот пример поднял этот вопрос ... Я лично против прописных сокращений в именах таблиц или столбцов, так как я думаю, что это затрудняет чтение. Поэтому в этом случае я бы сказал, что StudentId предпочтительнее, чем StudentID. Ничего страшного, когда аббревиатура в конце, но я видел бесчисленные примеры в моей работе, где аббревиатуры были в начале или в середине имени, и это усложняло анализ в вашем уме. Пример: StudentABCSSN против StudentAbcSsn.
redOctober13
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.