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

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

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

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

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

Спасибо

Таблица • Имя

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

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

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

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

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

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

В подлинных реляционных базах данных, которые были смоделированы (в отличие от систем хранения записей до 1970-х годов [отличающихся тем, Record IDsчто для удобства реализованы в контейнере базы данных SQL):

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

Diagram_A

Конечно, связь реализована в SQL как CONSTRAINT FOREIGN KEYв дочерней таблице (подробнее позже). Вот фраза глагола (в модели), предикат, который она представляет (для чтения из модели), и имя ограничения 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_descriptionxor 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. 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_для кластера ввода заказов и т. д.

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

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

   _VПросмотр ( TableNameконечно, с основным впереди)
   _fkвнешнего ключа (имя ограничения, а не имя столбца) Операция сегмента
   _cacкэша (сохраненный процесс или функция) Функция (нетранзакционная) и т. Д.
   _seg
_tr
_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Уникальный, или _для неуникального
    CClustered, или _для некластеризованного
    _разделителя

    Для остатка:

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

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

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

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

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

    • Они содержат реальные примеры всего вышеперечисленного. Задавайте вопросы, переименовывая вопросы в этой теме.
    • Конечно, модели реализуют несколько других стандартов, помимо соглашений об именах; Вы можете либо игнорировать их сейчас, либо не стесняйтесь задавать конкретные новые вопросы .
    • Они по несколько страниц каждая, встроенная поддержка изображений в Stack Overflow предназначена для птиц, и они не загружаются согласованно в разных браузерах; так что вам придется нажимать на ссылки.
    • Обратите внимание, что 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это предикат, а не таблица. Не путайте их. Обратитесь к моему ответу, где он относится к предметам, глаголам и предикатам, и к моему ответу Ларри непосредственно выше.

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

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

  • Кроме того, каждая таблица представляет или является реализацией множества предикатов, а не одного.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Singular vs. Plural: выберите один и придерживайтесь его.

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

Множественное число неплохо, если его использовать последовательно, но мое предпочтение - единственное число.

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

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

Так:

User

UserProduct (it is a users products after all)

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

UserProductDescription

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

ProductDescription

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

UserProduct_Stuff

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

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

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