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

Отже, якщо я отримав таблицю "користувач", а потім отримав продукти, які матиме лише користувач, чи повинна таблиця називатися "user_product" або просто "product"? Це стосунки один до багатьох.

І далі, якщо я мав би (чомусь) кілька описів продуктів для кожного продукту, це буде "user_product_description" чи "product_description" чи просто "опис"? Звичайно, з правильним набором іноземних ключів. Називати його лише описом було б проблематично, оскільки я можу також мати опис користувача чи опис облікового запису чи будь-що інше ..

Що робити, якщо я хочу мати чисту реляційну таблицю (багато-багато) із лише двома колонками, як це виглядатиме? "user_stuff" або, можливо, щось на кшталт "rel_user_stuff"? І якщо перший, що б відрізняло це від, наприклад, "user_product"?

Будь-яка допомога високо цінується, і якщо там є якийсь стандарт конвенції про іменування, який ви, хлопці, рекомендуєте, посилайтесь.

Дякую

Таблиця • Назва

нещодавно вивчена однина правильна

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

Деякі з чудових речей про Стандарти:

• всі вони інтегровані між собою
• вони працюють разом
• вони були написані розумами, ніж у нас, тому нам не доведеться їх обговорювати.

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

Відносини, словосполучення

У справжніх реляційних базах даних, які були змодельовані (на відміну від систем запису файлів до 1970 року [характеризуються Record IDsякими реалізовані в контейнері баз даних SQL для зручності):

• таблиці є Суб'єктами бази даних, таким чином вони знову є іменниками однини
• зв’язки між таблицями - це дії, що відбуваються між іменниками, таким чином вони є дієсловами (тобто вони не довільно пронумеровані та не названі)
• що є Predicate
• все, що можна прочитати безпосередньо з моделі даних (див. мої приклади в кінці)
• (Присудок для незалежної таблиці (найпопулярніший з батьків в ієрархії) полягає в тому, що він незалежний)
• таким чином, словосполучення дієслова ретельно вибирається, щоб воно було найбільш значущим, а загальних термінів уникати (це стає легше з досвідом). Словосполучення дієслова важливе під час моделювання, оскільки воно допомагає у вирішенні моделі, тобто. з'ясування зв’язків, виявлення помилок та виправлення назв таблиць.

Діаграма_А

Звичайно, взаємозв'язок реалізований у SQL як CONSTRAINT FOREIGN KEYдочірня таблиця (докладніше, пізніше). Ось фраза Глагола (в моделі), то предикат , що вона представляє (читати від моделі), а FK Constraint Ім'я :

    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 .

Діаграма_В

І далі, якщо я мав би (чомусь) кілька описів продуктів для кожного продукту, це був би "опис користувача-продукту" чи "опис продукту" або просто "опис"? Звичайно, з правильним набором іноземних ключів. Називати його лише описом було б проблематично, оскільки я можу також мати опис користувача чи опис облікового запису чи будь-що інше.

Це вірно. Будь-який user_product_descriptionxor product_descriptionбуде правильним, виходячи із сказаного. Це не відрізняти його від інших xxxx_descriptions, але це дати імені відчути, куди він належить, приставкою є батьківська таблиця.

Що робити, якщо я хочу мати чисту реляційну таблицю (багато-багато) із лише двома колонками, як це виглядатиме? "user-stuff" або, можливо, щось на кшталт "rel-user-stuff"? І якщо перший, що б відрізняло це від, наприклад, "користувач-продукт"?

1. Сподіваємось, всі таблиці в реляційній базі даних є чистими реляційними, нормалізованими таблицями. Не потрібно ідентифікувати це в імені (інакше всі таблиці будуть rel_something).

2. Якщо він містить тільки ПК двох батьків (який вирішує логічну залежність n :: n, яка не існує як сутність на логічному рівні, у фізичну таблицю), це асоціативна таблиця . Так, зазвичай ім'я є комбінацією двох імен батьківської таблиці.

   • Зауважте, що саме такі випадки словосполучення дієслова стосуються і читаються як від батьків до батьків, ігноруючи таблицю дитини, тому що її єдиною метою в житті є зв'язок двох батьків.

     Діаграма_C

   • Якщо це не Асоціативна таблиця (тобто, крім двох ПК, вона містить дані), тоді назвіть її відповідним чином, і до неї поширюються дієслівні фрази, а не батьківські в кінці відносин.

     Діаграма_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. Винятки:

   • Перший виняток стосується ПК, їм потрібна спеціальна обробка, оскільки ви постійно кодуєте їх, і ви хочете, щоб ключі виділялися з стовпців даних. Завжди використовуйте user_id, ніколи id.

     • Зверніть увагу , що це НЕ ім'я таблиці використовується в якості префікса, а власне описову назву для компонента ключа: user_idце стовпець , який ідентифікує користувача, а НЕ idв userтаблиці.
       • (За винятком звичайних систем реєстрації записів, де до файлів отримують доступ сурогати, а реляційних ключів немає, там вони одне і те саме).
     • Завжди використовуйте точно таке ж ім’я для стовпчика ключів, де б ПК не переносився (мігрував) як FK.
     • Тому user_productтаблиця буде user_idскладовою частиною ПК (user_id, product_no).
     • актуальність цього стане зрозумілою, коли ви почнете кодування. По-перше, за допомогою idбагатьох таблиць легко змішати кодування SQL. По-друге, будь-хто інший, що початковий кодер не має поняття, що він намагався зробити. І те, і інше легко запобігти, якщо ключові стовпці розглядаються як вище.

   • Другий виняток - коли існує більше однієї ФК, що посилається на одну і ту ж таблицю батьківської таблиці, що переноситься у дитині. Відповідно до реляційної моделі , використовуйте назви ролей, щоб диференціювати значення чи використання, наприклад. AssemblyCodeі ComponentCodeна двох PartCodes. І в цьому випадку не використовуйте недиференційовану PartCodeдля одного з них. Будьте точні.

     Діаграма_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. Іноземні ключі (обмеження, а не стовпець). Найкраще називати ФК - використовувати словосполучення дієслова (мінус «кожен» та кардинальність).

   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. Знайдіть когось кваліфікованого та професійного та дотримуйтесь їх. Подивіться на їхні проекти та уважно вивчіть правила використання назв, які вони використовують. Задайте їм конкретні запитання щодо всього, чого ви не розумієте. І навпаки, бігайте, як пекло, від усіх, хто демонструє мало уваги до іменування конвенцій чи стандартів. Ось декілька для початку:

    • Вони містять реальні приклади всього вищесказаного. Задайте питання щодо перейменування питань у цій темі.
    • Зрозуміло, моделі реалізують декілька інших стандартів, окрім конвенцій щодо іменування; ви можете або проігнорувати їх на даний момент, або не соромтесь задавати конкретні нові запитання .
    • На кожній сторінці розміщено кілька сторінок. Підтримка вбудованого зображення в "Переповнюванні стека" призначена для птахів, і вони не завантажуються послідовно у різних браузерах; тому вам доведеться натискати на посилання.
    • Зверніть увагу, що файли PDF мають повну навігацію, тому натисніть на кнопки синього скла або на об'єкти, де розпізнано розширення:
    • Читачі, які не знайомі зі стандартом реляційного моделювання, можуть вважати Повідомлення IDEF1X корисним.

Замовлення записів та інвентаризація з адресами, що відповідають стандартам

Проста між офісна бюлетень для PHP / MyNonSQL

Сенсорний моніторинг з повними тимчасовими можливостями

Відповіді на запитання

^{На це неможливо відповісти в просторі коментарів.}

Ларрі Люстіг:
... показує навіть найтривіальніший приклад ...
Якщо у Замовника є багато товарів, а в Продукті є компоненти, які є багатьма, а у Компонента є постачальники "багато-багато", а Постачальник продає нуль -Для багатьох компонентів і SalesRep є один-багато-багато клієнтів, які "природні" назви таблиць містять Клієнти, Продукти, Компоненти та Постачальники?

У вашому коментарі є дві основні проблеми:

1. Ви заявляєте, що ваш приклад є "найтривіальнішим", однак, це все, окрім. З такою суперечливістю я не впевнений, якщо ви серйозні, чи технічно спроможні.

2. Ця "тривіальна" спекуляція має кілька грубих помилок нормалізації (проектування БД).

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

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

   • Як тільки це буде нормалізовано, і потрібні таблиці будуть визначені, їхні назви стануть очевидними. Природно.

У будь-якому випадку я спробую обслуговувати ваш запит. Що означає, що мені доведеться додати певного сенсу до цього, не знаючи, що ви мали на увазі, тому, будь ласка, поводьтеся зі мною. Грубих помилок тут занадто багато, і враховуючи запасні характеристики, я не впевнений, що я їх виправив.

• Я буду вважати, що якщо виріб складається з компонентів, то продукт - це збірка, а компоненти використовуються в більш ніж одній збірці.

• Крім того, оскільки "Постачальник продає нульові компоненти для багатьох", вони не продають товари чи склади, вони продають лише компоненти.

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

Якщо ви не знаєте, різниця між квадратними кутами (незалежними) та круглими кутами (залежними) є істотною, зверніться до посилання IDEF1X Notation. Аналогічно суцільним лініям (Ідентифікація) проти пунктирними лініями (Неідентифікація).

... які "природні" назви таблиць містять Клієнти, Продукти, Компоненти та Постачальники?

• Замовник
• Товар
• Компонент (Або, AssemblyComponent, для тих, хто усвідомлює, що один факт ототожнює інший)
• Постачальник

Тепер, коли я вирішив таблиці, я не розумію вашої проблеми. Можливо, ви можете поставити конкретне запитання.

VoteCoffee:
Як ви поводитесь зі сценарієм, який Ронніс розмістив у своєму прикладі, коли між двома таблицями існує декілька відносин (user_likes_product, user_bought_product)? Я можу неправильно зрозуміти, але це, здається, призводить до дублювання назв таблиць із використанням детальної конвенції.

Якщо припустити, що помилок нормалізації немає, User likes Productце предикат, а не таблиця. Не плутайте їх. Зверніться до мого відповіді, де він стосується предметів, дієслів та присудків, і моя відповідь на Ларрі безпосередньо вище.

• Кожна таблиця містить набір фактів (кожен рядок - це факт). Присудки (або пропозиції) не є фактами, вони можуть бути, а можуть і не бути істинними.

  • Реляційна модель заснована на обчислення предикатів першого порядку (більш відомий як перший Order Logic). Присудок - це односкладне речення простою, точною англійською мовою, яке оцінюється як істинне чи хибне.

  • Крім того, кожна таблиця представляє або є реалізацією багатьох предикатів, а не однієї.

• Запит - це тест предиката (або декількох предикатів, зв'язаних разом), що призводить до істинного (Факт існує) або хибного (Факт не існує).

• Таким чином, таблиці повинні бути названі, як це детально описано в моєму відповіді (іменування умов), для рядка, факту та предикатів повинні бути задокументовані (якимось чином це частина документації на базу даних), але як окремий список предикатів .

• Це не припущення, що вони не важливі. Вони дуже важливі, але я цього не напишу тут.

• Швидко, значить. Оскільки реляційна модель заснована на FOPC, то всю базу даних можна сказати як набір декларацій FOPC, набір предикатів. Але (а) Є багато типів предикатів, і (б) таблиця не представляє собою один предикат (це фізична реалізація багатьох предикатів і різних типів присудка).

• Тому називати таблицю "присудком, що вона" представляє "- це абсурдне поняття.

• "Теоретики" знають лише декілька предикатів, вони не розуміють, що оскільки RM була заснована на FOL, вся база даних є набором предикатів і різних типів.

  • І звичайно, вони вибирають абсурдні з небагатьох, яких вони знають EXISTING_PERSON:; PERSON_IS_CALLED. Якби не так сумно, було б весело.

  • Зауважте також, що назва таблиці Стандарт або атомна таблиця (іменування рядка) працює чудово для всіх багатослівних (включаючи всі присудки до таблиці). І навпаки, ідіотична "таблиця представляє предикат" ім'я не може. Що добре для "теоретиків", які дуже мало розуміють предикати, але інакше відстають.

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

  1. Унарний предикат
     Перший набір є схематичним , а не текстовим: самі позначення . До них належать різні екзистенціальні; Орієнтованість на обмеження; і Дескриптор (атрибути) предикати.

     • Звичайно, це означає, що лише ті, хто може "прочитати" стандартну модель даних, можуть читати ці предикати. Ось чому «теоретики», які сильно покалічені своєю умовою, що стосується лише тексту, не можуть читати моделі даних, чому вони дотримуються свого лише тексту до 1984 року.

  2. Бінарний предикат
     Другий набір - це ті, що утворюють зв’язки між фактами. Це лінія відношення. Словосполучення (докладно вище) ідентифікує предикат, пропозицію , що було реалізовано (що може бути перевірено за допомогою запиту). Не можна отримати більш чіткого означення.

     • Тому тому, хто вільно володіє стандартними моделями даних, усі предикати, які є релевантними , задокументовані у моделі. Їм не потрібен окремий список предикатів (але користувачі, які не можуть "прочитати" все з моделі даних, роблять!).

• Ось модель даних , де я перерахував предикати. Я вибрав цей приклад, тому що він показує Екзистенційність тощо, предикати, а також ті, що стосуються стосунків, Єдині предикати, які не вказані, - це Дескриптори. Тут, завдяки рівню навчання шукача, я ставлюсь до нього як до користувача.

Тому подія більше однієї дочірньої таблиці між двома батьківськими таблицями не є проблемою, просто назвіть їх як Екзистенціальний Факт за їх змістом і нормалізуйте імена.

Тут грають правила, які я дав для дієслівних фраз для імен відносин для асоціативних таблиць. Ось обговорення предиката проти таблиці , що охоплює всі згадані моменти, підсумовуючи.

Щоб отримати хороший короткий опис про правильне використання предикатів та їх використання (що зовсім інший контекст для відповіді на коментарі тут), відвідайте цю відповідь та прокрутіть униз до розділу предикатів .

Чарльз Бернс:
Під послідовністю я мав на увазі об'єкт у стилі Oracle, що використовується виключно для зберігання числа та його наступного згідно з деяким правилом (наприклад, "додати 1"). Оскільки в Oracle не вистачає таблиць автоматичного ідентифікації, моїм типовим використанням є створення унікальних ідентифікаторів для ПК таблиць. ВСТУПИТИ В foo (id, somedata) VALUES (foo_s.nextval, "data" ...)

Гаразд, саме так ми називаємо таблицю Key або NextKey. Назвіть це як таке. Якщо у вас є SubjectAreas, використовуйте COM_NextKey, щоб вказати, що він поширений у базі даних.

До речі, це дуже поганий метод генерації ключів. Зовсім не масштабується, але тоді, з виступом Oracle, це, мабуть, "просто чудово". Далі це вказує на те, що у вашій базі даних є сурогати, а не реляційні в цих областях. Що означає надзвичайно низьку продуктивність та відсутність цілісності.

Однина проти множини: Виберіть один і дотримуйтесь його.

Стовпці не повинні бути префіксованими / суфіксальними / інфіксованими або будь-яким іншим чином фіксуватися посиланням на те, що це стовпець. Те саме стосується таблиць. Не називайте таблиці EMPLOYEE_T або TBL_EMPLOYEES, тому що вдруге замінюється видом, речі стають дійсно заплутаними.

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

На насправді, єдина хороша річ * виправлення я можу думати, що ви можете використовувати зарезервовані слова , як where_t, tbl_order, user_vw. Звичайно, у цих прикладах використання множини вирішило б питання :)

Не називайте всі ключі "ідентифікатор". Клавіші, що посилаються на одне і те ж, повинні мати однакове ім’я у всіх таблицях. Стовпчик ідентифікатора користувача може бути названий USER_ID в таблиці користувачів і всіх таблиць, що посилаються на користувача. Єдиний раз, коли він перейменований - це коли різні користувачі грають різні ролі, наприклад, повідомлення (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 - не впевнений у питанні точного характеру необхідних багато-до-багатьох.

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

Що стосується вашого запитання, якщо "Product" та "ProductDescription" - це поняття, що мають особистість (тобто особи) у вашій моделі, я б просто назвав таблиці "Products" та "ProductDescriptions". Для таблиць, які використовуються для реалізації відносин "багато-багато", я найчастіше використовую конвенцію іменування "SideA2SideB", наприклад "Student2Course".