Ответ 1

Таблица • Имя

недавно выучил единственное число является правильным

Да. Остерегайтесь язычников. Множественное число в именах таблиц является верным признаком того, кто не читал ни одного из стандартных материалов и не знает теории баз данных.

Некоторые из замечательных вещей о стандартах:

• они все интегрированы друг с другом
• они работают вместе
• они были написаны умом, превосходящим наш, поэтому нам не нужно их обсуждать.

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

Отношения, глагольная фраза

В подлинных реляционных базах данных, которые были смоделированы (в отличие от систем хранения записей, реализованных в контейнере базы данных SQL):

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

Diagram_A

Конечно, эта связь реализована в SQL как ограничение внешнего ключа в дочерней таблице (подробнее, позже). Вот Фраза глагола (в модели), Предикат, который он представляет (для чтения из модели), и Имя ограничения FK:

    Initiates
    Each Customer Initiates 0-to-n SalesOrders
    Customer_Initiates_SalesOrder_fk

Таблица • Язык

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

    Each Customer initiates zero-to-many SalesOrders

не

    Customers have zero-to-many SalesOrders 

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

(Это не вопрос соглашения об именах; это вопрос разработки базы данных.) Не имеет значения, равен ли user::product 1 :: n. Важно то, является ли product отдельным объектом и является ли он независимой таблицей, т.е. оно может существовать само по себе. Поэтому product, а не user_product.

И если product существует только в контексте user, т.е. это зависимая таблица, поэтому user_product.

Diagram_B

И далее, если бы у меня было (по какой-то причине) несколько описаний продуктов для каждого продукта, это было бы "user-product-description" или "product-description" или просто "description"? Конечно, с правильными установленными внешними ключами. Назвать его только описанием было бы проблематично, так как у меня также может быть описание пользователя или описание учетной записи или что-то еще.

Это так. Либо user_product_description xor product_description будет правильным, основываясь на вышеизложенном. Он не должен отличать его от других xxxx_descriptions, но он должен дать имени ощущение того, где оно принадлежит, причем префикс является родительской таблицей.

А что если я хочу иметь чистую реляционную таблицу (от многих ко многим) только с двумя столбцами, как это будет выглядеть? "user-stuff" или что-то вроде "rel-user-stuff"? И если первый, что бы отличить это, например, "пользовательский продукт"?

1. Надеемся, что все таблицы в реляционной базе данных являются чисто реляционными нормализованными таблицами. Нет необходимости указывать это в имени (в противном случае все таблицы будут rel_something).

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

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

     Diagram_C

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

     Diagram_D

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

Соглашение об именовании

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

То, что вы делаете, очень важно, и это повлияет на простоту использования и понимания на каждом уровне. Итак, с самого начала полезно получить как можно больше понимания. Актуальность большей части этого не будет ясна, пока вы не начнете кодировать в SQL.

1. Дело является первым пунктом для решения. Все заглавные буквы недопустимы. Смешанный регистр - это нормально, особенно если таблицы доступны непосредственно пользователям. См. Мои модели данных. Обратите внимание, что когда ищущий использует какой-то безумный NonSQL, который имеет только строчные буквы, я даю это, и в этом случае я включаю подчеркивание (согласно вашим примерам).

2. Поддерживайте фокусировку на данных, а не на приложении или использовании. Ведь после 2011 года у нас была открытая архитектура с 1984 года, и предполагается, что базы данных не зависят от приложений, которые их используют.

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

3. Будьте очень внимательны и называйте таблицы и столбцы очень точно. Не используйте UpdatedDate если это тип данных DATETIME, используйте UpdatedDtm. Не используйте _description если он содержит дозировку.

4. Важно быть последовательным по всей базе данных. Не используйте NumProduct в одном месте, чтобы указать количество продуктов, а ItemNo или ItemNum в другом месте, чтобы указать количество товаров. Используйте NumSomething для номеров, а SomethingNo или SomethingId для идентификаторов последовательно.

5. Не user_first_name префикс имени столбца к имени таблицы или короткому коду, например, user_first_name. SQL уже предоставляет имя таблицы в качестве квалификатора:

       table_name.column_name  -- notice the dot
   

6. Исключения:

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

     • Обратите внимание, что это не имя таблицы, используемой в качестве префикса, а правильное описательное имя для компонента ключа: user_id - это столбец, который идентифицирует пользователя, а не id user таблицы.
       • (За исключением, конечно, в системах хранения записей, где к файлам обращаются суррогаты и нет реляционных ключей, там они одно и то же).
     • Всегда используйте одно и то же имя для ключевого столбца везде, где PK переносится (переносится) как FK.
     • Поэтому таблица user_product будет иметь user_id в качестве компонента своего PK (user_id, product_no).
     • Актуальность этого станет ясна, когда вы начнете кодировать. Во-первых, с id для многих таблиц легко запутаться в кодировании SQL. Во-вторых, кто-нибудь другой, первоначальный кодер понятия не имеет, что он пытается сделать. Оба из них легко предотвратить, если ключевые столбцы обрабатываются как указано выше.

   • Второе исключение - это когда более одного FK ссылаются на одну и ту же таблицу родительских таблиц, передаваемых в дочернем элементе. Согласно реляционной модели, используйте имена ролей, чтобы дифференцировать значение или использование, например. AssemblyCode и ComponentCode для двух PartCodes. И в этом случае не используйте недифференцированный PartCode для одного из них. Будь точным.

     Diagram_E

7. Префикс
   Если у вас более 100 таблиц, перед именами таблиц добавьте предметную область:

   REF_ для справочных таблиц
   OE_ для кластера ввода OE_ и т.д.

   Только на физическом уровне, а не на логическом (это загромождает модель).

8. Суффикс
   Никогда не используйте суффиксы для таблиц, и всегда используйте суффиксы для всего остального. Это означает, что при логическом, нормальном использовании базы данных подчеркивания отсутствуют; но на административной стороне подчеркивания используются в качестве разделителя:

   _V View (с основным TableName впереди, конечно)
   _fk ключ _fk (имя ограничения, а не имя столбца)
   _cac Cache
   _seg Сегмент
   Транзакция _tr (сохраненный _tr или функция)
   _fn Функция (_fn) и т.д.

   Формат представляет собой имя таблицы или FK, подчеркивание и имя действия, подчеркивание и, наконец, суффикс.

   Это действительно важно, потому что когда сервер выдает сообщение об ошибке:

   ____ blah blah blah error on object_name

   Вы точно знаете, какой объект был нарушен, и что он пытался сделать:

   ____ blah blah blah error on Customer_Add_tr

9. Внешние ключи (ограничение, а не столбец). Лучшее наименование для FK - использовать фразу глагола (минус "каждый" и количество элементов).

   Customer_Initiates_SalesOrder_fk
Part_Comprises_Component_fk
Part_IsConsumedIn_Assembly_fk

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

   ____ Foreign key violation on Vendor_Offers_PartVendor_fk.

   Это хорошо работает для людей, которые пытаются моделировать свои данные, где были определены глагольные фразы. В остальном, системы хранения записей и т.д. Используют Parent_Child_fk.

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

    U Уникальный или _ для неуникального
    C кластеризованный, или _ для некластеризованного
    _ разделитель

    Для остатка:

    • Если ключ один столбец или очень мало столбцов:
      ____ ColumnNames

    • Если ключ больше, чем несколько столбцов:
      ____ PK первичный ключ (согласно модели)
      ____ AK[*n*] альтернативный ключ (термин IDEF1X)

    Обратите внимание, что имя таблицы не обязательно указывать в имени индекса, потому что оно всегда отображается как table_name.index_name.

    Поэтому, когда Customer.UC_CustomerId или Product.U__AK появляется в сообщении об ошибке, оно сообщает вам что-то значимое. Когда вы смотрите на индексы на столе, вы можете легко их дифференцировать.

11. Найдите кого-то квалифицированного и профессионального и следуйте за ним. Посмотрите на их дизайн и изучите соглашения об именах, которые они используют. Задайте им конкретные вопросы о том, что вы не понимаете. И наоборот, бегите, как ад, от любого, кто демонстрирует мало внимания к соглашениям или стандартам именования. Вот несколько, чтобы вы начали:

    • Они содержат реальные примеры всего вышеперечисленного. Задавайте вопросы, переименовывая вопросы в этой теме.
    • Конечно, модели реализуют несколько других стандартов, помимо соглашений об именах; Вы можете либо игнорировать их сейчас, либо не стесняйтесь задавать конкретные новые вопросы.
    • Они состоят из нескольких страниц каждая, поддержка встроенного изображения в Qaru предназначена для птиц, и они не загружаются согласованно в разных браузерах; так что вам придется нажимать на ссылки.
    • Обратите внимание, что PDF файлы имеют полную навигацию, поэтому нажимайте на кнопки синего стекла или объекты, где указано расширение:
    • Читатели, не знакомые со стандартом реляционного моделирования, могут найти нотацию IDEF1X полезной.

Ввод и инвентаризация заказов по стандартным адресам

Простая межведомственная система бюллетеней для PHP/MyNonSQL

Сенсорный мониторинг с полной временной возможностью

Ответы на вопросы

^{На это нельзя разумно ответить в поле для комментариев.}

Ларри Люстиг:
... даже самый тривиальный пример показывает...
Если у Клиента имеется ноль ко многим Продуктам, а у Продукта есть один ко многим Компонентов, а у Компонента есть один ко многим Поставщикам, а Поставщик продает ноль ко многим Компонентам, а у SalesRep есть один ко многим Клиентам Каковы "естественные" названия таблиц, содержащих клиентов, продукты, компоненты и поставщиков?

В вашем комментарии есть две основные проблемы:

1. Вы объявляете свой пример "самым тривиальным", однако это не что иное, как. С таким противоречием я не уверен, если вы серьезны, если технически способны.

2. Это "тривиальное" предположение имеет несколько грубых ошибок нормализации (DB Design).

   • Пока вы не исправите их, они неестественны и ненормальны, и они не имеют никакого смысла. Вы можете также назвать их abnormal_1, abnormal_2 и т.д.

   • У вас есть "поставщики", которые ничего не поставляют; циркулярные ссылки (незаконные и ненужные); клиенты, покупающие продукты без какого-либо коммерческого инструмента (например, Invoice или SalesOrder) в качестве основы для покупки (или клиенты "владеют" продуктами?); неразрешенные отношения "многие ко многим"; и т.п.

   • Как только это нормализуется, и необходимые таблицы определены, их имена станут очевидными. Естественно.

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

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

• Кроме того, поскольку "Поставщик продает компоненты с нуля ко многим", они не продают продукты или сборки, они продают только компоненты.

Спекуляция против нормализованной модели

Если вы не в курсе, разница между квадратными углами (независимыми) и закругленными углами (зависимыми) является значительной, обратитесь к ссылке на обозначение IDEF1X. Аналогично сплошные линии (Идентификация) против пунктирных линий (Неидентификация).

... каковы "естественные" названия таблиц, содержащих клиентов, продукты, компоненты и поставщиков?

• Покупатель
• Товар
• Компонент (или AssemblyComponent, для тех, кто понимает, что один факт идентифицирует другой)
• поставщик

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

VoteCoffee:
Как вы справляетесь со сценарием, который Роннис опубликовал в своем примере, где между двумя таблицами существует несколько взаимосвязей (user_likes_product, user_bought_product)? Я могу неправильно понять, но это, кажется, приводит к дублированию имен таблиц, используя соглашение, которое вы подробно описали.

Предполагая, что ошибок нормализации нет, User likes Product - это предикат, а не таблица. Не путайте их. Обратитесь к моему ответу, где он относится к предметам, глаголам и предикатам, и к моему ответу Ларри непосредственно выше.

• Каждая таблица содержит набор фактов (каждая строка представляет собой факт), а не предикаты. Предикаты (или предложения) не являются фактами, они могут быть или не быть правдой.

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

• Запрос - это проверка Предиката (или нескольких Предикатов, связанных вместе), который приводит к истине (Факт существует) или ложь (Факт не существует).

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

• Это не предположение, что они не важны. Они очень важны, но я не буду писать это здесь.

• Тогда быстро. Поскольку реляционная модель основана на FOL, можно сказать, что вся база данных представляет собой набор объявлений, набор предикатов. Но (а) существует много типов предикатов, и (б) таблица не представляет предикат (это физическая реализация многих предикатов и разных типов предикатов).

• Следовательно, называть таблицу "Предикатом, который она" представляет "- абсурдная концепция.

• "Теоретики" знают только о нескольких Предикатах, они не понимают, что, поскольку РМ была основана на ВОЛС, вся база данных представляет собой набор Предикатов и разных типов.

  • И, конечно же, они выбирают нелепых из немногих, кого они знают: EXISTING_PERSON; PERSON_IS_CALLED. Если бы это не было так грустно, это было бы весело.

  • Также обратите внимание, что стандартное или атомарное имя таблицы (с именем строки) отлично работает для всех слов (включая все предикаты, прикрепленные к таблице). И наоборот, идиотское имя "таблица представляет предикат" не может. Что хорошо для "теоретиков", которые очень мало понимают в предикатах, но в остальном отстают.

• Предикаты, которые имеют отношение к модели данных, выражаются в модели, они бывают двух видов.

  • Первый набор в схематической, а не текстовой форме: обозначение. К ним относятся различные экзистенциальные; Ограничение-ориентированный; и дескриптор (атрибуты) предикаты.

  • Конечно, это означает, что только те, кто может "читать" Стандартную модель данных, могут читать эти Предикаты. Вот почему "теоретики", которые серьезно пострадали от своего только текстового мышления, не могут читать модели данных, поэтому они придерживаются своего текстового мышления до 1984 года.

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

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

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

Таким образом, событие более чем одной дочерней таблицы между двумя родительскими таблицами не является проблемой, просто назовите их в качестве Existential Fact для их содержимого и нормализуйте имена.

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

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

Чарльз Бернс:
По порядку я имел в виду объект в стиле Oracle, который просто используется для хранения числа и его следующего по некоторому правилу (например, "добавить 1"). Поскольку в Oracle отсутствуют таблицы автоидентификации, я обычно использую уникальные идентификаторы для таблиц PK. INSERT INTO foo (id, somedata) VALUES (foo_s.nextval, "data"...)

Хорошо, это то, что мы называем таблицей Key или NextKey. Назовите это так. Если у вас есть SubjectAreas, используйте COM_NextKey, чтобы указать, что он является общим для всей базы данных.

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

Ответ 2

Нет "правильного" об единственном числе множественного числа - это в основном вопрос вкуса.

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

• Поскольку вам, вероятно, понадобится "пользователь" в таблице, другой "продукт", а третий для подключения пользователей к продуктам, вам понадобится таблица "user_product".

• Поскольку описание относится к продукту, вы должны использовать "product_description". Если каждый пользователь не называет каждый продукт для себя...

• Таблица "user_product" является (или может быть) примером таблицы с идентификатором продукта и идентификатором пользователя и не более того. Вы называете таблицы с двумя атрибутами одним и тем же общим способом: "user_stuff". Декоративные префиксы, такие как 'rel_', действительно не помогают. Например, вы увидите, что некоторые люди используют "t_" перед каждым именем таблицы. Это не очень помогает.

Ответ 3

Сингулярное против множественного числа: выберите один и придерживайтесь его.

Столбцы не должны быть префиксными/суффиксными/фиксированными или в любом случае фиксированными ссылками на то, что это столбец. То же самое касается таблиц. Не называйте таблицы EMPLOYEE_T или TBL_EMPLOYEES, потому что во-вторых, это заменяет вид, все становится очень запутанным.

Не вставляйте информацию типа в имена, такие как "vc_firstname" для varchar или "flavour_enum". Также не вставляйте ограничения в имена столбцов, такие как "department_fk" или "employee_pk".

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

Не называйте все ключи "ID". Ключи, ссылающиеся на одно и то же, должны иметь одно и то же имя во всех таблицах. Столбец идентификатора пользователя можно было бы назвать USER_ID в таблице пользователя и всех таблицах, ссылающихся на пользователя. Единственный раз, когда он переименовывается, когда разные пользователи играют разные роли, такие как Message (sender_user_id, receiver_user_id). Это действительно помогает при работе с более крупными запросами.

Что касается CaSe:

thisiswhatithinkofalllowercapscolumnnames.

ALLUPPERCAPSISNOTBETTERBECAUSEITFEELSLIKESOMEONEISSCREAMINGATME.

CamelCaseIsMarginallyBetterButItStillTakesTimeToParse.    

i_recommend_sticking_with_lower_case_and_underscore

В общем случае лучше назвать "таблицы сопоставления" в соответствии с описываемым им отношением, а не с именами ссылочных таблиц. Пользователь может иметь любое количество отношений с продуктами: user_likes_product, user_bought_product, user_wants_to_buy_product.

Ответ 4

Плодуны не плохие, если они используются последовательно, но единственное мое предпочтение.

Я бы обойтись без подчеркивания, если вы не хотите наметить отношения "многие ко многим"; и использовать начальный капитал, потому что он помогает различать вещи в ORM.

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

Итак:

User

UserProduct (it is a users products after all)

Если только один пользователь может иметь любой продукт, то

UserProductDescription

Но если продукт используется пользователями:

ProductDescription

Если вы сохраните свои подчеркивания для отношений "многие ко многим", вы можете сделать что-то вроде:

UserProduct_Stuff

чтобы сформировать M-to-M между UserProduct и Stuff - не уверенность в вопросе о точном характере требуемого количества-ко-многим.

Ответ 5

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

О вашем вопросе, если "Продукт" и "ProductDescription" - это концепции с идентификатором (т.е. сущностями) в вашей модели, я бы просто назвал таблицы "Продукты" и "ProductDescriptions". Для таблиц, которые используются для реализации отношений "многие ко многим", я чаще всего использую соглашение об именах "SideA2SideB", например "Student2Course".