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

https://stackoverflow.com/questions/7662

08-06-2019
|

Вопрос

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

Должны ли имена таблиц быть во множественном числе?
Должны ли имена столбцов быть в единственном числе?
Должен ли я префикс таблиц или столбцов?
Должен ли я использовать любой регистр при именовании предметов?

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

Решение

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

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

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

Другие советы

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

Мой предпочтение множественное число
Да
Таблицы:*Обычно* лучше не использовать префиксы. Столбцы:Нет.
И таблицы, и столбцы:ПаскальКейс.

Разработка:

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

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

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

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

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

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

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

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

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

SELECT person.Name
FROM People person

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

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

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

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

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

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

Имя поля внешнего ключа должно совпадать с именем поля первичного ключа.

то есть

SELECT cust_nm, cust_add1, booking_dt
FROM reg_customer
INNER JOIN reg_booking
ON reg_customer.cust_id = reg_booking.cust_id

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

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

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

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

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

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

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

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

Должны ли имена таблиц быть во множественном числе?
Никогда.Аргументы в пользу того, что это коллекция, имеют смысл, но никогда не знаешь, что будет содержать таблица (0, 1 или несколько элементов).Правила множественного числа делают именование излишне усложненным.1 дом, 2 дома, мышь против мышей, человек против людей, а другие языки мы даже не рассматривали.

Update person set property = 'value' действует на каждого человека в таблице.
Select * from person where person.name = 'Greg' возвращает коллекцию/набор строк, состоящих из лиц.
Должны ли имена столбцов быть в единственном числе?
Обычно да, за исключением случаев, когда вы нарушаете правила нормализации.
Должен ли я префикс таблиц или столбцов?
В основном предпочтение платформы.Мы предпочитаем добавлять к столбцам префикс имени таблицы.Мы не добавляем префиксы к таблицам, но мы добавляем префиксы к представлениям (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).

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

customer_category_customer_type_id

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

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

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

Это позволяет избежать ошибок и ошибок, вызванных неоднозначностью множественного числа.Программисты не особо известны своими навыками правописания, а множественное число некоторых слов сбивает с толку.Например, слово во множественном числе заканчивается на «es» или просто на «s»?Это люди или люди?Когда вы работаете над проектом с большой командой, это может стать проблемой.Например, случай, когда член команды использует неправильный метод для формирования множественного числа создаваемой им таблицы.К тому времени, когда я взаимодействую с этой таблицей, она используется повсюду в коде, к которому у меня нет доступа или на его исправление уйдет много времени.В результате мне приходится запоминать неправильное написание таблицы каждый раз, когда я ее использую.Со мной произошло нечто очень похожее на это.Чем проще вы сможете сделать так, чтобы каждый член команды мог последовательно и легко использовать точные и правильные имена таблиц без ошибок и необходимости постоянно искать имена таблиц, тем лучше.С единственной версией гораздо проще работать в командной среде.
Если вы используете единственную версию имени таблицы И префикс первичного ключа с именем таблицы, теперь у вас есть преимущество, позволяющее легко определить имя таблицы по первичному ключу или наоборот с помощью только кода.Вам можно дать переменную с именем таблицы, объединить «Id» в конец, и теперь у вас есть первичный ключ таблицы через код, без необходимости выполнять дополнительный запрос.Или вы можете отрезать «Id» от конца первичного ключа, чтобы определить имя таблицы с помощью кода.Если вы используете «id» без имени таблицы для первичного ключа, вы не сможете с помощью кода определить имя таблицы по первичному ключу.Кроме того, большинство людей, которые используют имена таблиц во множественном числе и добавляют к столбцам PK префикс имени таблицы, используют версию имени таблицы в единственном числе в PK (например, statuses и statusId), что делает это вообще невозможным.
Если вы сделаете имена таблиц в единственном числе, вы сможете сделать так, чтобы они соответствовали именам классов, которые они представляют.Опять же, это может упростить код и позволить вам делать действительно изящные вещи, например создавать экземпляр класса, не имея ничего, кроме имени таблицы.Это также просто делает ваш код более согласованным, что приводит к...
Если вы сделаете имя таблицы единственным, это сделает вашу схему именования единообразной, организованной и простой в обслуживании в любом месте.Вы знаете, что в каждом экземпляре вашего кода, будь то имя столбца, имя класса или имя таблицы, это одно и то же имя.Это позволяет вам выполнять глобальный поиск, чтобы увидеть, где используются данные.Когда вы создаете имя таблицы во множественном числе, в некоторых случаях вы будете использовать версию имени этой таблицы в единственном числе (класс, в который она превращается в первичном ключе).Просто имеет смысл не иметь случаев, когда ваши данные упоминаются во множественном числе, а некоторые — в единственном числе.

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

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

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

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

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

Например.Учитывая таблицы «клиент» и «адрес», давайте воспользуемся префиксами «cust» и «addr» соответственно.«клиент» будет иметь «cust_id», «cust_name» и т. д.в этом.«адрес» будет иметь «addr_id», «addr_cust_id» (обратно к клиенту), «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) это имеет меньше смысла для ОО-эквивалента (Orders x = new Orders).

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

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

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

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

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

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

4) Что бы вы ни хотели, я бы посоветовал CapitalCase.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Имена таблиц в единственном числе.Допустим, вы моделировали связь между кем-то и его адресом.Например, если вы читаете DataModel, вы бы предпочли: «Каждый человек может жить в 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
);

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

Множественное число.Это совокупность сущностей.
Да.Атрибут представляет собой представление единственного свойства сущности.
Да, имя таблицы префиксов позволяет легко отслеживать имена всех индексов ограничений и псевдонимов таблиц.
Pascal Case для имен таблиц и столбцов, префикс + ВСЕ заглавные буквы для индексов и ограничений.

Лицензировано под: CC-BY-SA с атрибуция

Не связан с StackOverflow