Створювати окремі таблиці для різних типів товарів чи ні?

25

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

Типи виробів такі: Моделі, запчастини, комплекти запчастин та варіанти.

Варіант A (перший дизайн): я планував створити окремі таблиці для вищевказаних типів продуктів. Я б сказав, що приблизно 75% полів буде однаковим у кожній таблиці.

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

Варіант B: Замість того, щоб мати окремі таблиці, я міг би створити таблицю під назвою Продукт, яка включає в себе модель, частину, комплекти заміни та параметри. Я міг би мати одне поле під назвою типу для розмежування моделі, варіантів і т. Д. Я вважаю, що нижня сторона - кілька полів ніколи б не використовувались (ліві нулі) для певних типів продуктів. Я здогадуюсь, що саме тут почали грати "не найкращі практики".

Варіант B значно зменшить складність дизайну db. Мені також не доведеться турбуватися про посилання на купу таблиць під час витягу даних для запитів ...

database-design database-recommendation

— виплати
джерело

2

На цьому етапі я пропоную вам створити електронні таблиці, які імітують ваш макет таблиці та заповнюють їх даними. Це дозволить виявити будь-які слабкі місця, які можуть існувати.

— Майкл Райлі - AKA Gunny

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

— Ніл МакГуйган

8

Якби це було моїм дизайнерським рішенням, я, ймовірно, пішов би з більшою частиною "Варіант С" (модифікований варіант a).

По-перше, чому б не "Варіант B":

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

З іншого боку, стратегія індексації завжди вимагатиме переліку цього типу поля. Оскільки це лише 4 типи, то кардинальність індексу надзвичайно низька ( SELECT * FROM product_table WHERE type='X'в основному все-таки робимо повне сканування таблиці)

Варіант С

Створіть батьківську таблицю, у якій є лише стовпці, якими поділяються всі типи
Створіть кожен тип продукту як його власну таблицю з їх окремими стовпцями, з одним додатковим: Посилання на батьківську таблицю
Створіть кожну таблицю "посилань": Product_Option, Model_option тощо з посиланнями на відповідні клавіші.
Для тих, хто має зворотні посилання (MODEL_OPTION, OPTION_MODEL), продовжуйте створювати і ці таблиці. Це додасть ясності вашим приєднанням для тих, хто на це дивиться.

Мінусом є складність у тому, щоб уникнути сиріт, коли речі оновлюються / видаляються, і спочатку розробляють запити, які використовують ці таблиці.

— Дерек Дауні
джерело

5

Зараз існує лише 4 типи, але що робити, якщо більше буде додано пізніше? Я впевнений, що основну таблицю продуктів Amazon спочатку називали "Книги", але чи вважаєте ви, що зараз у них є окрема таблиця для кожного виду товару? Я не думаю, що кожен тип не повинен мати власну таблицю, але ви можете використовувати модель EAV для додаткових властивостей, які можуть мати спільний характер кожного типу.

— Аарон Бертран

1

@Aaron Справедлива думка про майбутнє збільшення видів продукції. Якби цей сценарій міг би розширитися на 10+ видів продукції, я б передумав. Але я вважаю, що конкретні таблиці продуктів - це справедливий вибір дизайну для невеликої кількості видів продукції.

— Дерек Дауні

1

Варіант С: Чи потрібна наявність таблиці посилань? Я думаю, що продукт Product_Option PK відповідав би PK таблиці продукту, і це створило би асоціацію для з'єднання обох таблиць.

— оплата

Використовуючи Product_option як приклад, схема буде (на мій погляд): id, productID, optionID. productIDбуло би ФК до product.id, і optionIDє ФК до option.id. Ось що я мав на увазі під таблицею посилань. І так, у цій конструкції необхідно дозволити одному продукту посилатися на кілька варіантів.

— Дерек Дауні

Добре, я зрозумів. Я неправильно прочитав те, що ви ввели .. На жаль.

— оплата

7

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

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

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

— Марк Сторі-Сміт
джерело

2

Це звучить дуже схоже на Bills матеріалів / кількох кардинальних heirarcy , що Пол Нільсен описує в главі 17 з SQL Server 2008 Біблії .

Весь розділ - це дуже добре прочитане, а специфічний розділ, який стосується вашої проблеми багато хто, є на сторінках 416-419.

Це найкраща дискусія, яку я бачив стосовно проектування даних про вибухові частини .

— Майкл Райлі - AKA Gunny
джерело

Це рішення схоже на варіант B (якщо я правильно його розумію, чого я не впевнений). У мене буде головна таблиця (Продукти) та таблиця «посилання» (він же сусідня таблиця / BillsofMaterials) для створення асоціацій між моделями, параметрами, наборами тощо. Це правильно?

— оплата

Я думаю, що проблема затуманена через варіанти. Дозволяє вивести з дискусії варіанти лише на трохи. Частини - це найменша одиниця. Група деталей складає модель. Група запасних частин у вигляді комплекту складає підмножину моделі. Все йде нормально. Тепер у деталях є варіанти, які дозволяють припустити для простоти, це включає дві категорії кольорів (чорний, червоний, хром) та матеріал (метал, дерево, пластик). Ви також згадали, що у моделей є варіанти. Чи відрізняються параметри моделі від варіантів деталей чи здаються, що моделі мають лише варіанти, оскільки деталі роблять моделі різними?

— Майкл Райлі - AKA Gunny

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

— оплата

Це не те, як ви фразували своє запитання. Цитата: "Наприклад, Модель може мати багато варіантів, а опція може мати багато моделей. Опція також може мати багато деталей, а частина може мати багато варіантів ... і так далі ..." У цьому питанні я пропоную вам створити електронні таблиці, які імітують макет таблиці та заповнюють їх даними. Це дозволить виявити будь-які слабкі місця, які можуть існувати.

— Майкл Райлі - AKA Gunny

0

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

Замість того, щоб залишати багато невикористаних зведених полів у таблиці Product, чому б не додати таблицю ModelProduct, таблицю PartProduct, таблицю ReplacementPartKitProduct і мати лише поля, які в цих таблицях відрізняються для цих типів? Використовуйте той же первинний ключ у цих таблицях, що і таблиця Product. Приєднуйтесь до таблиці продуктів та моделей продуктів, коли ви хочете працювати з моделями. Потрібно визначити, чи є у Вас запис продукту? Просто приєднайте ліву частину від продукту до PartProduct, і якщо PartProduct. [PrimaryKey] не є нульовим, у вас є частина. Якщо це недійсне значення, це не частина. Можна також додати поле ProductType до таблиці Product.

— Алан Макбі
джерело

Нульові поля були б мінімальними, оскільки приблизно 75% полів буде використовуватися в кожній таблиці. Напевно, мене більше турбують відносини між видами продукції. У мене є три або близько таблиці зв’язків, що вказують на ту саму таблицю. Модель_has_Option два первинні ключі, обидва ідентифікатори продукту таблиці продукту, якби я використовував лише одну таблицю для представлення типів продуктів. Мене більше хвилює, чи правильно це робити чи ні.

— оплата

Хоча є багато факторів, які впливають на "правильне" рішення, слід враховувати два широких фактори. 1: загальні вимоги до продуктивності; 2: адаптованість / складність / ремонтопридатність. Одне з цих двох, мабуть, трохи важливіше, ніж інше. Якщо вам потрібна швидкість, денормалізуйте, дотримуючись Варіант А. У вас буде дублювання; це очікувано. Якщо вам потрібно регулярно поспілкуватися зі схемою, а швидкість - це НЕ найважливіший фактор, тоді Варіант B. Ви отримуєте це "правильно", знаючи свої пріоритети, а не дотримуючись "чужих кращих практик".

— Алан Макбі