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




sqlite column names convention (16)

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

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

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


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

Хорошо. Это мои $ 0.02


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

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

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


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


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

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

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

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

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

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

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

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

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


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

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

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


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

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

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

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

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

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

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

Хорошо, поскольку мы взвешиваем мнение:

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

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

SELECT person.Name
FROM People person

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

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


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

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

Например, учитывая таблицы «клиент» и «адрес», давайте перейдем с префиксами «cust» и «addr» соответственно. «клиент» имел бы «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%';

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

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

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

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

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

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


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

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

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

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

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

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

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


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

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


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

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

Префикс Столы / Столбцы: Это огромная тема, которая будет обсуждаться позже.

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

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



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

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




naming-conventions