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

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

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

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

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

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

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

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

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

Разработка:

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

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

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

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

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

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

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

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

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

SELECT person.Name
FROM People person

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

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

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

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

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

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

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

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

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

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

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

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

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

2. Если вы используете единственную версию имени таблицы И добавляете префикс первичного ключа к имени таблицы, у вас теперь есть преимущество в простом определении имени таблицы из первичного ключа или наоборот только с помощью кода. Вам может быть задана переменная с именем таблицы, конкатенировать «Id» до конца, и теперь у вас есть первичный ключ таблицы через код, без необходимости делать дополнительный запрос. Или вы можете обрезать «Id» в конце первичного ключа, чтобы определить имя таблицы с помощью кода. Если вы используете «id» без имени таблицы для первичного ключа, то вы не сможете с помощью кода определить имя таблицы из первичного ключа. Кроме того, большинство людей, которые множат имена таблиц и префикс столбцов PK с именем таблицы, используют единственную версию имени таблицы в PK (например, statuses и 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 и таблицей customer_type, указывает первичный ключ в таблице customer_type (customer_type_id), и, если вы когда-либо увидите «customer_customer_type_id» во время отладки запроса, вы сразу узнаете, откуда он (таблица customer).

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

   customer_category_customer_type_id

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

--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 для индексов и ограничений.