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

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

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

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

SELECT person.Name
FROM People person

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

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

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

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

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

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

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

i.e.

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. Опять то же самое. Столбец FirstName действительно не следует называть FirstNames. Все зависит от того, что вы хотите изобразить с помощью столбца.
3. NO.
4. да. Дело для ясности. Если вам нужны столбцы, такие как «FirstName», используйте регистр для облегчения чтения.

В порядке. Это мои 0,02 доллара

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

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

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

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

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

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

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

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

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

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

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

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

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

   customer_category_customer_type_id

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

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

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

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

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

Я знаю, что это поздно для игры, и на этот вопрос уже дан очень хороший ответ, но я хочу высказать свое мнение по поводу № 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%';

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

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

Хотя кажется, что это имеет смысл для простого выбора (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

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

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

На мой взгляд:

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

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

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

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

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

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

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

1. Definitely keep table names singular, person not people
   2. Same here
   3. Нет. Я видел несколько ужасных префиксов, доходящих до того, что я имел дело с таблицей (tbl_) или процедурой сохранения пользователя (usp_). Затем следует имя базы данных ... Не делайте этого!
   4. да. Я стараюсь использовать PascalCase для всех имен своих таблиц

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

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

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

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

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