Соглашение об именах реляционных таблиц

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

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

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

Как насчет того, хочу ли я иметь чистую реляционную таблицу (многие для многих) только с двумя столбцами, что бы это выглядело? «user_stuff» или, может быть, что-то вроде «rel_user_stuff»? И если первый, что бы отличить это от, например, «user_product»?

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

благодаря

    Таблица • Имя

    недавно изученное единственное правильное

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

    Некоторые из замечательных вещей о Стандартах: все они объединены друг с другом; они работают вместе; и они были написаны умами, большими, чем наши, поэтому нам не нужно обсуждать их. Имя стандартной таблицы относится к каждой строке в таблице, которая используется во всех формулировках, а не к общему содержимому таблицы (мы знаем, что таблица 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 

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

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

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

    Diagram_B

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

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

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

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

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

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

        Diagram_C

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

        Diagram_D

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

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

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

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

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

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

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

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

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

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

        table_name.column_name -- notice the dot 
    6. Исключения:

      • Первое исключение – для ПК, им нужна специальная обработка, потому что вы все время кодируете их в соединениях, и вы хотите, чтобы клавиши выделялись из столбцов данных. Всегда используйте 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_ для кластера ввода заказа и т. Д.

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

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

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

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

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

      ____ blah blah blah error on object_name

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

      blah blah blah error on Customer_Add_tr ____ blah blah blah error on Customer_Add_tr

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

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

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

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

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

    Мониторинг датчиков с полной временной поддержкой

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

    Это не может быть разумным ответом в пространстве комментариев.

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

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

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

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

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

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

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

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

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

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

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

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

    … Каковы «естественные» названия таблиц, в которых хранятся клиенты, продукты, компоненты и поставщики?

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

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

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

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

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

      • Реляционная модель основана на исчислении предикатов первого порядка (более известная как логика первого порядка). A Predicate – это предложение с одним предложением в простом, точном английском языке, которое оценивается как true или false.
    • Запрос – это тест Предиката (или нескольких Предикатов, соединенных вместе), что приводит к истинному (факт существует) или ложному (факт не существует).

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

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

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

    • Следовательно, обозначение таблицы для «предиката», которое оно представляет, является абсурдной концепцией.

    • «Теоретики» знают только несколько Предикатов, они не понимают, что, поскольку RM был основан на FOL, вся firebase database представляет собой набор Predicates и разных типов.

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

      • Также обратите внимание, что стандартное или атомное имя таблицы (обозначение строки) отлично работает для всех формулировок (включая все предикаты, прикрепленные к таблице). И наоборот, идиотская «таблица представляет предикат» не может. Это хорошо для «теоретиков», которые очень мало разбираются в Predicates, но отстают в противном случае.

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

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

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

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

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

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

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

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

    Для хорошего краткого описания повторите правильное использование Predicates и их использование (что совсем не так, как в комментариях к комментариям здесь), посетите этот ответ и прокрутите вниз до раздела Predicate .


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

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

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

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

    Столбцы не должны быть префиксами / суффиксами / исправленными или в любом случае фиксированными ссылками на то, что это столбец. То же самое касается таблиц. Не называйте таблицы 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 .

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

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

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

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

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

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

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

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

    Так:

     User UserProduct (it is a users products after all) 

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

     UserProductDescription 

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

     ProductDescription 

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

     UserProduct_Stuff 

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

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

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

    Interesting Posts
    Давайте будем гением компьютера.