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

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

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

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

Ответов (23)

Решение

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

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

  1. Единичные имена для таблиц
  2. Единичные имена для столбцов
  3. Имя схемы для префикса таблиц (например: SchemeName.TableName)
  4. Корпус Паскаля (он же верхний регистр верблюда)

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

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

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

  1. Имена таблиц во множественном числе : я предпочитаю множественное число
  2. Имена столбцов в единственном числе: Да
  3. Таблицы или столбцы префиксов:
  • Таблицы : * Обычно * без префиксов лучше.
  • Столбцы : No.
  1. Для именования элементов используйте любой регистр: PascalCase как для таблиц, так и для столбцов.

Доработка:

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

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

(2) Что вам, вероятно, следует делать.

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

(3) Что следует учитывать.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Хорошо, раз уж мы придерживаемся мнения:

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

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

SELECT person.Name
FROM People person

Немного похоже на LINQ «от человека к людям выбирают person.Name».

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

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

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

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

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

  1. да. Таблица - это группа записей , учителей или актеров , так что ... во множественном числе.
  2. да.
  3. Я ими не пользуюсь.
  4. База данных, которую я использую чаще всего - Firebird - хранит все в верхнем регистре, поэтому это не имеет значения. В любом случае, когда я программирую, я пишу имена так, чтобы их было легче читать, например, releaseYear .
  1. Определенно сохраняйте имена таблиц в единственном числе, человек, а не люди
    1. То же самое
    2. Нет. Я видел несколько ужасных префиксов, доходящих до того, что я имел дело с таблицей (tbl_) или процедурой сохранения пользователя (usp_). Затем следует имя базы данных ... Не делайте этого!
    3. да. Я стараюсь использовать PascalCase для всех имен своих таблиц
  1. Нет. Таблица должна быть названа в честь сущности, которую она представляет. Человек, а не люди - вот как вы бы отнеслись к тому, кого представляет одна из записей.
  2. Опять то же самое. Столбец FirstName действительно не следует называть FirstNames. Все зависит от того, что вы хотите изобразить с помощью столбца.
  3. НЕТ.
  4. да. Обсудите это для ясности. Если вам нужны столбцы, такие как «FirstName», используйте регистр для облегчения чтения.

Ok. Это мои 0,02 доллара

Мое мнение по этому поводу:

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

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

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

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

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

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

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

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

4) Что бы вы ни хотели, я предлагаю CapitalCase

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

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

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

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

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

Для полей мы ожидаем, что имена полей будут включать префикс / акрионм таблицы (например, cust_address1), и мы также предпочитаем использовать стандартный набор суффиксов (_id для PK, _cd для "кода", _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

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

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

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

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

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

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

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

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

--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. Паскаль Регистр для имен таблиц и столбцов, префикс + ВСЕ заглавные буквы для индексов и ограничений.

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

Некоторое время назад я писал об этом в блоге: Соглашения об именах ISO-11179

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

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

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

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

См. Название элемента данных в Википедии :

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

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

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

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

  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» во время отладки запроса, вы сразу узнаете, откуда он (таблица клиентов).

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

    customer_category_customer_type_id

    ... немного (!) длиннее.

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

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

Основные правила именования баз данных (и стиль) (щелкните здесь, чтобы получить более подробное описание)

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

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

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

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

Например, для данных таблиц «клиент» и «адрес» перейдем к префиксам «cust» и «addr» соответственно. "customer" будет содержать "cust_id", "cust_name" и т. д. "адрес" будет содержать "addr_id", "addr_cust_id" (FK обратно клиенту), "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%';

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

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

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

Корпус: это должен быть чехол Camel

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