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

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

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

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

Я думаю, что мы должны назвать множественное число для таблиц и единственное число для столбцов.
AZ_ 5.05.2011 06:04:29
Я вижу таблицу как «хранилище» с несколькими элементами, а не как одну «сущность», поэтому я называю ее множественным числом. Когда я отображал таблицы в объекты, я бы назвал объекты в единственном числе. Это всего лишь мое личное мнение.
dpp 19.07.2013 02:40:30
@Tryinko Использование ID повсеместно - ЖИЗНЕННЫЙ АД для тех, кто делает соединения из нескольких таблиц. Нет никакого возможного способа, которым небольшое преимущество знания этого PK перевешивает невероятную досаду повторного наложения псевдонима dang ID в каждом кровавом запросе снова и снова. Если вам нужен способ обозначить PK в таблице, сделайте его первым столбцом. Кроме того, обозначение ФК в названиях столбцов, на мой взгляд, является еще одним совершенно злым антишаблоном.
ErikE 2.02.2016 23:05:30
Посмотрите на этот ответ .
PerformanceDBA 6.02.2019 09:16:16
23 ОТВЕТА
РЕШЕНИЕ

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

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

  1. Особые имена для таблиц
  2. Особые имена для столбцов
  3. Имя схемы для префикса таблиц (например, SchemeName.TableName)
  4. Оболочка Паскаля (он же верхняя часть верблюда)
311
2.04.2018 20:05:38
wilsonmar.com/sql_adventureworks.htm - превосходный анализ схемы AdventureWorks.
Daniel Trebbien 11.01.2011 00:40:00
Я бы не стал полагаться на Microsoft в отношении какого-либо стандарта - если вы посмотрите на их базу данных северного ветра, то увидите, что они используют множественные таблицы, имена столбцов в единственном числе, префиксы схем для таблиц, префиксы таблиц для столбцов первичных ключей, префиксы ограничений венгерского типа и худшие всех пространств "" для имен таблиц из нескольких слов. Кроме того, системные таблицы для SQLServer используют множественное число, так что, похоже, AdventureWorks был паршивой овцой в этой группе.
Marcus Pope 20.03.2012 20:09:07
Я думаю, что главная проблема здесь в том, что толпа имен таблиц в единственном числе, кажется, рассматривает таблицу как сущность, а не строку в таблице, которую делает толпа множественного числа. Вы должны спросить себя, что это такое. Если таблица является просто контейнером строк, не более ли логично использовать множественное именование? Вы никогда не назвали бы коллекцию в единственном числе кода, тогда почему бы вы назвали таблицу единственной? Почему несоответствие? Я слышу все аргументы о том, как они сортируются и используются в соединениях, но эти аргументы кажутся очень надуманными. Если все сводится к предпочтениям, я пойду с последовательностью и плюрализмом.
Jason 10.04.2012 16:34:56
Также подумайте, в каком направлении идет прилив. Кажется, что он идет в направлении имен множественных таблиц, тем более что все системные таблицы в SQL Server являются множественными, а по умолчанию для Entity Framework используется множественное число из коробки. Если это позиция Microsoft, я хочу пойти в том направлении, в котором мы будем через 20 лет. Даже соглашения с базами данных Oracle говорят имена таблиц во множественном числе. Подумайте, сколько разработчиков на c # ненавидело ключевое слово «var», когда оно было введено, теперь это широко распространенный способ определения переменных.
Jason 10.04.2012 16:39:13
@Jasmine - я вижу вашу точку зрения, хотя думаю, что вы случайно назвали свою таблицу примеров в обратном направлении. «TableOfInvoices» следует сократить до «Invoices», что я и предпочитаю. Вы, вероятно, вместо этого имели в виду «InvoiceTable», что имеет смысл сократить «Invoice».
Derek 5.03.2013 14:53:18
  1. Нет. Таблица должна быть названа в честь сущности, которую она представляет. Личность, а не личность - это то, как вы относитесь к тому, кого представляет одна из записей.
  2. Опять то же самое. Столбец FirstName действительно не должен называться FirstNames. Все зависит от того, что вы хотите представить в колонке.
  3. NO.
  4. Да. Случай для ясности. Если вам нужно иметь столбцы типа «FirstName», регистр облегчит чтение.

ОК. Это мой $ 0,02

46
20.01.2017 22:10:16
Добавление ясности к номеру 3 - префиксы - это способ встраивания метаданных в имя столбца. Не должно быть необходимости делать это в любой современной БД по тем же причинам, что и (чрезмерное использование) венгерской нотации.
Mark McDonald 4.01.2010 14:13:15
`выбрать топ 15 из заказа 'или" выбрать топ 15 из заказа "? Последнее мое (человеческое) предпочтение.
Ian Boyd 22.01.2010 23:15:21
@Ian Boyd: Да: ВЫБЕРИТЕ ТОП-100 * ИЗ ОТЧЕТА R ВНУТРЕННЕЕ РЕШЕНИЕ VisitReport VR ON R.ReportID = VR.ReportID. Все зависит от того, как вы об этом думаете. Если вы поставите изображение лимона на канистру, вы узнаете, что внутри были лимоны, без необходимости использовать два лимона снаружи, чтобы указать, что это может быть множественное число. Конечно, вы могли бы обозначить его письменным словом «лимоны». Но это также может быть "лимон". Чтобы приобрести ресурс под названием «лимон», перейдите сюда.
ErikE 29.01.2010 00:35:27
добавьте $ 0,01 для использования UpperCase в именах столбцов и добавьте еще $ 0,01 для использования подчеркивания в именах столбцов, чтобы было легче различать имена столбцов на виду. Итого = мои $ 0,02 пожертвования для вас!
Frank R. 11.11.2010 06:04:50
«Таблица должна быть названа в честь сущности, которую она представляет» Таблица - это совокупность сущностей. Хотя таблица также является сущностью, она является сущностью типа «Таблица», которую бессмысленно добавлять к ее имени.
Trisped 9.04.2012 19:01:36

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

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

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

SELECT person.Name
FROM People person

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

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

99
22.01.2010 16:14:04
@Emtucifor: На английском мы не говорим: «Посмотрите на всех людей в этой толпе!» Ожидается наличие концептуальной проблемы с множественными вещами, на которые ссылается единственное слово. Это не обычное и не правильное. «Данные» являются исключительными и часто используются для обозначения части объема вещества, очень похожего на «пирог». "Хочешь (кусок) торта?" Называть таблицу «Люди», потому что она содержит информацию о нескольких лицах, имеет гораздо больший смысл, чем называть ее «Персона». Класс данных с именем "Person" для ROW имеет смысл, как и имена столбцов в единственном числе.
Triynko 1.04.2010 19:37:10
@Emtucifor: В конечном итоге весь язык является произвольным и условным. Я просто утверждал, что условно мы называем коллекцию предметов множественным числом типа предмета в нем. Таким образом, коллекция строк, в которой каждая строка содержит информацию об одном человеке, будет представлена ​​как группа людей. Но если вы хотите сослаться на это как на личность, идите вперед.
Triynko 21.04.2010 17:02:46
@Emtucifor: Да, лол. Присвоение имени таблице «PersonCollection» будет эквивалентно присвоению ей имени «Люди». Противопоставьте, что с именованием такой коллекции просто «Персона», что не имеет смысла :)
Triynko 22.04.2010 15:04:04
@Emtucifor: Тогда давайте подумаем об этом с другой стороны, чтобы поместить соглашение об именах в контекст. Предположим, у вас есть классы объектов для представления как строки, так и таблицы. «Человек», очевидно, имеет смысл для класса, представляющего ряд данных. Если ваша таблица также называется «Персона», то у вас может возникнуть конфликт имен или некоторая путаница. Я просто думаю, что более разумно называть объекты точным множеством. Строка с данными о человеке должна называться Person, а таблица с информацией о людях или нескольких лицах называется People, PersonCollection, Persons и т. Д.
Triynko 23.04.2010 16:15:16
@ Джош М. Ну, ни в коем случае. Если вы пойдете по моему пути, вы можете создать псевдоним таблицы People как «персона» и выбрать SELECT person.Name. Задача решена. ;-)
Matt Hamilton 12.11.2010 04:48:25

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

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

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

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

  1. Да. Таблица - это группа записей , учителей или актеров , так что ... во множественном числе.
  2. Да.
  3. Я ими не пользуюсь.
  4. База данных, которую я использую чаще всего - Firebird - хранит все в верхнем регистре, поэтому это не имеет значения. В любом случае, когда я программирую, я пишу имена так, чтобы их было легче читать, например, releaseYear .
11
11.08.2008 11:14:11
  1. Определенно держите имена таблиц в единственном числе, человек не люди
    1. Тоже самое
    2. Нет. Я видел несколько ужасных префиксов, дошедших до того, что они утверждают, что имеют дело с таблицей (tbl_) или процедурой хранения пользователя (usp_). Затем следует имя базы данных ... Не делайте этого!
    3. Да. Я склонен PascalCase все мои имена таблиц
11
20.06.2011 20:04:25
О, МОЙ БОГ. NO. Имена таблиц ОПРЕДЕЛЕННО во множественном числе. Это коллекция. В нем есть несколько вещей. "выбрать * из людей". Вы выбираете не одного человека, а нескольких людей!
Triynko 1.04.2010 19:43:34
Мне всегда нравилось, как выражение select звучит лучше, если оно множественное. SELECT id,name FROM contacts WHERE email_address LIKE '%gmail%'таблицы множественного числа, столбцы единственного числа. Опять же всегда вопрос личного мнения.
scunliffe 1.07.2012 01:46:49

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

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

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

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

15
12.04.2012 10:30:28
Что за хрень CapitalCase?
ViRuSTriNiTy 23.06.2016 09:30:00
@ViRuSTriNiTy он, вероятно, имел в видуpascal case
marctrem 28.02.2017 18:18:46
Кит, под номером 3 я делаю и то и другое, и я непоследователен (но я отвлекся), но я не понимаю, почему плохо иметь описательное имя столбца, если оно не за бортом, то же самое с таблицей, переменная и т. д.
johnny 15.01.2018 17:45:28
@ Джонни, это не плохо, просто так не нужно. Зачем печатать вещи, которые вам не нужны? Кроме того, большинство intellisense в основном использует начало имени, поэтому, если у вас есть Product.ProductName, Product.ProductIDи Product.ProductPriceт.д., ввод Product.Pдает вам все поля с префиксом.
Keith 15.01.2018 22:25:05

--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 для индексов и ограничений.
-4
11.08.2008 11:46:05
ChristianName ... это странное соглашение.
BobbyShaftoe 25.02.2009 00:31:04
Серийные номера на ваших столах? Кто - нибудь серьезно думает , что это имеет смысл работу для разработчиков?
ErikE 20.06.2011 20:05:34
Так как этот пример поднял этот вопрос ... Я лично против прописных сокращений в именах таблиц или столбцов, так как я думаю, что это затрудняет чтение. Так что в этом случае я бы сказал, что StudentId предпочтительнее, чем StudentID. Ничего страшного, когда аббревиатура в конце, но я видел бесчисленные примеры в моей работе, где аббревиатуры были в начале или в середине имени, и это усложняло анализ в вашем уме. Пример: StudentABCSSN против StudentAbcSsn.
redOctober13 5.01.2019 14:01:55

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

  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

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

72
22.01.2010 22:54:45
Специально для номера 3 у нас была группа людей, которых всех наняли из одной компании, и они пытались навязать свой старый стандарт именования (которым никто из нас не пользовался) во всем, что они делали. Очень надоедливый.
HLGEM 22.01.2010 16:11:55
Конечно, делает SQL нечитаемым; но я думаю, что могу перевести. cust_nm должен быть CustomerName , booking_dt должен быть BookingDate . reg_customer, ну я понятия не имею, что это такое.
Ian Boyd 22.01.2010 23:17:50
@Ian. Намерение состоит в том, чтобы вы придерживались соглашения об именах, к которому вы привыкли, и придерживались его. Я ВСЕГДА знаю, что любое поле даты - _dt, любое поле имени - _nm. 'reg' - это пример системы "регистрации" (бронирования, клиенты и т. д.), и все связанные таблицы будут иметь одинаковый префикс. Но каждый по-своему ...
Guy 25.01.2010 19:30:36
Я согласен, что определенный стандарт не так важен, как наличие последовательного стандарта. Но некоторые стандарты неверны. DB2 и имена столбцов, такие как CSPTCN, CSPTLN, CSPTMN, CSDLN. Люди должны узнать, что длинные имена были изобретены - мы можем позволить себе делать вещи более читабельными.
Ian Boyd 26.01.2010 00:13:02
На протяжении многих лет я добавлял новые столбцы в конце своих таблиц в приложении, которое разработал и продал. Иногда я использую английские имена в своих столбцах, иногда я использую испанский, а иногда я использую столбцы для чего-то другого, вместо того, чтобы удалить их и добавить новый столбец с подходящим описательным именем для того, что оно используется. Я специально сделал это, чтобы ОБОСНОВАТЬ мой исходный код на случай, если кто-то еще попытается взломать или перепроектировать мой код. Только я могу понять это, кто-то еще расстроится! .. Таким образом, они всегда должны полагаться на меня во всем!
Frank R. 11.11.2010 06:15:17

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

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

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

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

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

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

  • Используйте язык вашего клиента и вашего домена решения
  • Быть описательным
  • Быть последовательным
  • Устранение неоднозначности, отражение и рефакторинг
  • Не используйте сокращения, если они не понятны всем
  • Не используйте зарезервированные ключевые слова SQL в качестве имен столбцов
9
11.08.2008 12:38:12
таблицы по определению отношения. которые на самом деле единичны. префиксы отстой. Вам когда-нибудь нужно было преобразовать таблицу в представление или наоборот? попробуйте это с префиксами. какая разница, если это представление или таблица?
William Jones 7.04.2017 15:57:20
Префикс может помочь, когда у нас одинаковое имя для двух объектов - например, функции и хранимой процедуры. Я хотел бы иметь функцию с именем «GetApproverList» и с тем же именем, я хотел бы создать хранимую процедуру, которая будет вызывать эту функцию внутри. Sql не позволит создавать два объекта с одинаковыми именами.
Ravinder Singh 6.07.2019 19:29:25

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

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

20
11.08.2008 13:13:58
Ваш ответ был бы более доступным (= лучше), если бы вы дали резюме здесь. Отличный указатель!
Ola Eldøy 27.04.2009 09:50:16

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

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

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

13
11.08.2008 15:23:32
относительно # 4, PascalCase ... camelCase ... snake_case ...
Andrew 17.12.2019 13:36:31

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

http://justinsomnia.org/writings/naming_conventions.html

9
22.10.2008 17:05:31

Я также поддерживаю соглашение об именовании в стиле ИСО / МЭК 11179, отмечая, что они являются скорее рекомендациями, чем предписаниями.

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

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

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

34
23.10.2008 10:45:02
-1: ссылочный текст не имеет ничего общего с ИСО / МЭК 11179. Ссылочной странице википедии нельзя доверять; Вместо этого прочтите действительный стандарт ( metadata-standards.org/11179/#A5 )
mkadunc 29.06.2012 11:24:53
@onedaywhen: я не знаю достаточно о предмете, чтобы исправить страницу википедии; Кроме того, страница википедии не столько ошибочна, сколько вводит в заблуждение - она ​​прямо не говорит о том, что ИСО / МЭК 11179 включает в себя соглашения о присвоении имен базам данных, она просто говорит, что «ИСО / МЭК 11179 применима при именовании таблиц и столбцов внутри реляционная база данных ". Затем он приводит пример соглашений об именах, которые могут использоваться для реляционной базы данных. Это позволяет вам думать, что пример взят из стандарта, тогда как на самом деле он составлен автором статьи в Википедии.
mkadunc 3.07.2012 15:21:30

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

  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 и fn udfи несколько других; это было тщательно, последовательно применено, таким образом, это работало хорошо. Единственный раз, когда вам НУЖНЫ префиксы, это когда у вас есть действительно отдельные решения, которые по какой-то причине находятся в одном БД; их префикс может быть очень полезен при группировке таблиц. Префикс также подходит для особых ситуаций, например для временных таблиц, которые вы хотите выделять.
  • Очень редко (если вообще когда-либо) вы захотите добавить префиксы к столбцам.
274
20.04.2018 19:55:07
«Поля, представляющие данные одного и того же типа в разных таблицах, должны иметь одинаковые имена. Не используйте Zip для одной таблицы и ZipCode для другой». Да да миллион раз да Можете ли вы сказать, что наша база данных не была разработана таким образом? К персону можно обращаться любым из дюжины различных способов, очень раздражающих в поддержании. Я всегда придерживался этого правила в любой базе данных, которую контролировал при проектировании, и это значительно упрощает жизнь.
HLGEM 26.03.2010 14:09:00
Я думаю, что первичный ключ должен быть просто «ID». Такое простое соглашение делает первичный ключ предсказуемым и быстро идентифицируемым. Однако я бы добавил имя таблицы («PersonID»), когда она используется в качестве внешнего ключа в других таблицах. Это соглашение может помочь различить первичный ключ и внешний ключ в одной таблице.
Triynko 1.04.2010 21:00:18
@Tryinko Использование ID повсеместно - ЖИЗНЕННЫЙ АД для тех, кто делает соединения из нескольких таблиц. Нет никакого возможного способа, которым небольшое преимущество знания этого PK перевешивает невероятную досаду повторного наложения псевдонима dang ID в каждом кровавом запросе снова и снова. Если вам нужен способ обозначить PK в таблице, сделайте его первым столбцом. Кроме того, обозначение ФК в названиях столбцов, на мой взгляд, является еще одним совершенно злым антишаблоном.
ErikE 20.06.2011 20:03:30
@Triynko, если вы используете просто «ID», также невозможно определить, к какой таблице он принадлежит. С префиксом имени таблицы вы можете просто отрезать последние две цифры первичного ключа и узнать имя таблицы, к которой оно принадлежит, с помощью кода. Часто ИТ-специалисты и администраторы баз данных не осознают, что для программистов есть определенные преимущества в разработке баз данных определенными способами.
dallin 29.04.2013 21:19:16
@ErikE Я имею в виду, вы не знаете, CustomerIDявляется ли первичный ключ из Customerтаблицы или внешний ключ в какой-то другой таблице. Это небольшая проблема. Почему вы хотите использовать плохие имена, как c? CustomerID = Customer.IDочень ясно, что вы видите, что вы соединяете внешний ключ с первичным ключом; это не избыточно, так как две стороны - это две разные вещи. Одноименное именование - плохая практика IMO.
Dave Cousineau 2.02.2016 22:21:51
SELECT 
   UserID, FirstName, MiddleInitial, LastName
FROM Users
ORDER BY LastName
7
27.04.2018 05:31:52
Обратите внимание на используемые стандарты: таблицы содержат несколько вещей, пользователи имеют одно имя, ключевые слова T-SQL в верхнем регистре, определения таблиц в регистре Pascal.
Ian Boyd 26.01.2010 00:14:39
опечатка: Lastnameдолжно бытьLastName
aminimalanimal 2.06.2017 21:42:16
Имя таблицы должно быть в единственном числе, то есть: пользователь вместо пользователей
AZ_ 22.01.2020 08:44:51
И обратите внимание, как имена таблиц во множественном числе; поскольку они содержат пользователей , а не пользователей .
Ian Boyd 23.01.2020 00:16:38

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

  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_type, указывает первичный ключ в таблице customer_type (customer_type_id), и если вы когда-либо увидите «customer_customer_type_id» во время отладки запроса, вы сразу узнаете, откуда он (таблица customer).

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

    customer_category_customer_type_id

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

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

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

25
7.01.2014 16:12:48
SELECT * FROM people AS person WHERE person.name = 'Greg'звучит наиболее естественно для меня.
Kenmore 28.12.2016 00:25:20
@Zuko В основном, соглашение об именах для первичного ключа таблицы <table name><id>, например, PersonIDи Person_IDт. Д. Поэтому имеет больше смысла, чтобы вы НЕ называли свои таблицы множественным числом, поскольку каждая запись - это отдельный человек, а не люди.
Mr. Blond 2.04.2018 23:19:55

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

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

3
5.05.2011 06:08:50
хотя то, что Oracle предлагает, это совершенно противоположно ссылке на линке выше. узнайте, что говорит Oracle здесь .. ss64.com/ora/syntax-naming.html
AZ_ 5.05.2011 06:10:08
Соглашение об именах Oracle было самым смешным из них .. e.g. PATIENTS would have a primary key called pa_patient_id_pk!!
nawfal 26.01.2013 13:40:04

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

2
26.06.2011 19:18:57

Я знаю, что это слишком поздно для игры, и на вопрос уже получен очень хороший ответ, но я хочу высказать свое мнение о # 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%';
15
2.09.2011 22:19:26
Тогда ты больше не можешь reliably find every line of code that touches a particular column... Разве не в этом смысл?
raveren 4.03.2013 07:52:59
@Raveren - Ты все еще можешь. Если все, что вы делаете, это «SELECT *», то запрос для этой цели не имеет значения. Когда / если позже вы используете результаты этого запроса, вы должны использовать имя столбца, чтобы что-то делать с его данными, так что это место, о котором вам нужно беспокоиться в вашем коде, а не оператор SQL.
Granger 26.04.2013 13:04:26
Мне будет любопытно, какие ситуации требуют SELECT *? Я, конечно, не хотел бы, чтобы кто-нибудь использовал это в рабочем коде. Да, это полезно для специальных запросов и для выяснения того, какая часть данных делает ваши результаты запроса на множественное объединение странными, но я не могу представить себе места в рабочем коде, где это требуется.
HLGEM 29.04.2013 20:30:01
Если вы не программируете все свое приложение на языке, отличном от OO, то наличие достойного слоя ORM делает этот аргумент избыточным.
Adam 15.04.2015 15:15:19
Поэтому из-за этого ответа я решил попробовать использовать префиксы таблиц в большом проекте и решил отчитаться. Это действительно сделало рефакторинг таблиц чрезвычайно простым, что было здорово! Тем не менее, это была большая боль, чем я ожидал. В нашей базе данных было много сложных именованных таблиц. Легко запомнить, что Cust является префиксом для Customer, но не так легко запомнить префикс для HazardVerificationMethod. Каждый раз, когда я писал таблицу или поле, мне приходилось делать паузу, чтобы подумать о префиксе. В конце концов я решил, что скорость и удобство важнее поиска, но я чувствовал, что это ценный опыт.
dallin 12.03.2018 22:05:06

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

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

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

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

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

4
24.09.2011 13:08:53
То есть, вы говорите, что таблица - это сущность? Или строка в таблице является сущностью? Для меня таблица - это набор строк, следовательно, набор сущностей, который подразумевает множественное число.
Jason 10.04.2012 16:29:29

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

5
25.06.2012 10:18:06
Стадо - это группа овец . UserЭто не группа пользователей.
EricRobertBrewer 14.07.2017 17:04:33

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

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

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

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

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

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

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

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

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

4
3.12.2012 09:26:39
Как вы упомянули, вы не можете полагаться на каждый случай, имеющий table.column. Программисты забудут в одном месте, и тогда ваш глобальный поиск и замена просто сломали всю вашу программу. Или вы сделаете это правилом, и кто-то подумает, что он выполняет это правило, используя псевдоним таблицы, что опять-таки помешает глобальному поиску. Кроме того, если вы хотите организовать свой код, имея некоторый класс базы данных (что будет делать любой хороший программист), будут времена, когда вы просто передадите имя столбца в функцию db или просто будете иметь только имя столбца в Переменная.
dallin 29.04.2013 19:33:32
@janb: я полностью поддерживаю твой ответ. Я также хочу добавить, что использование текстового поиска для поиска зависимостей является варварским способом навигации по коду. Как только люди избавятся от этой практики поиска варваров - они начнут использовать правильное именование, которое называется table.column. Так что проблема не в стиле именования, проблема в плохих инструментах, созданных для варваров.
alpav 17.02.2015 02:24:15
Ваш аргумент неверен. Проблема в том, что он работает в обе стороны и не добавляет никаких преимуществ. Вы говорите, чтобы решить это, просто всегда пишите table.column, так как вы уже пишете table_column. Ну, вы также можете сказать просто написать table_column, потому что вы уже пишете table.column. Другими словами, между вашим ответом нет никакой разницы, кроме того, что он вносит возможные ошибки и не обеспечивает соблюдения соглашений. По этой причине у нас есть «частное» ключевое слово. Мы могли бы доверять программистам, чтобы они всегда правильно использовали переменные класса, но ключевое слово применяет их и исключает возможные ошибки.
dallin 8.09.2015 23:11:20

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

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

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

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

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

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

25
23.10.2019 21:33:26