Стоит ли создавать отдельные таблицы для разных видов продукции?

25

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

Типы продукции: модели, детали, комплекты запасных частей и опции.

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

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

Вариант B: вместо отдельных таблиц я мог бы создать таблицу с именем Product, которая включает модели, детали, комплекты запасных частей и опции. Я мог бы иметь одно поле с именем type, чтобы различать модель, опции и т. Д. Я предполагаю, что недостатком является то, что несколько полей никогда не будут использоваться (оставлены пустыми) для определенных типов продуктов. Я предполагаю, что именно здесь "не лучшие практики" вступят в игру ..

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

database-design database-recommendation

— payling
источник

2

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

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

Как вы будете указывать внешние ключи на разные продукты, если они находятся в разных таблицах? Читайте о наследовании таблицы, пожалуйста.

— Нил Макгиган

8

Если бы это было мое дизайнерское решение, я бы, вероятно, выбрал больше «Вариант C» (модифицированный вариант a).

Во-первых, почему бы не «Вариант B»:

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

С другой стороны, стратегия индексирования всегда требует, чтобы это поле типа было указано в списке. Так как это всего 4 типа, количество элементов индекса крайне низкое ( SELECT * FROM product_table WHERE type='X'в любом случае, в основном выполняется полное сканирование таблицы)

Вариант С

Создайте родительскую таблицу, которая содержит только столбцы, которые разделяют все типы
Создайте каждый тип продукта как отдельную таблицу со своими отдельными столбцами, с одним дополнительным: ссылка на родительскую таблицу
Создайте каждую таблицу ссылок: Product_Option, Model_option и т. Д. Со ссылками на соответствующие ключи.
Для тех, у кого есть взаимные ссылки (MODEL_OPTION, OPTION_MODEL), также создайте эти таблицы. Это добавит ясности в ваши объединения для всех, кто на это смотрит.

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

— Дерек Дауни
источник

5

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

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

1

@ Аарон Справедливое замечание о будущем увеличении типов продуктов. Если бы этот сценарий мог предположительно расшириться до 10+ типов продуктов, я бы пересмотрел. Но я считаю, что конкретные таблицы продуктов - это правильный выбор дизайна для небольшого количества типов продуктов.

— Дерек Дауни

1

Вариант C: Нужно ли иметь таблицу ссылок? Я предположил бы, что PK Product_Option будет соответствовать PK таблицы Product, и это создаст ассоциацию для связи обеих таблиц.

— Выплата

Используя Product_option в качестве примера, схема будет (на мой взгляд): id, productID, optionID. productIDбудет FK для product.id, и optionIDявляется FK для option.id. Вот что я имел в виду под таблицей ссылок. И да, в этом проекте необходимо разрешить одному продукту ссылаться на несколько вариантов.

— Дерек Дауни

Хорошо я понял. Я неправильно понял, что вы напечатали .. Ой.

— Выплата

7

Я бы посоветовал вам начать с «правильной» реляционной модели, вашего варианта А. Если типичное использование этой модели ведет вас к денормализации в некоторых областях, не бойтесь делать это.

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

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

— Марк Стори-Смит
источник

2

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

Вся глава очень хорошо прочитана, а конкретный раздел, посвященный вашей проблеме «многие ко многим», можно найти на страницах 416–419.

Это лучшее обсуждение, которое я видел в отношении типа данных с разнесенными частями .

— Майкл Райли - AKA Gunny
источник

Это решение выглядит аналогично варианту B (если я правильно понимаю, что я не уверен, что я понимаю). У меня была бы основная таблица (Products) и таблица «link» (также называемая смежной таблицей / BillsofMaterials) для создания связей между моделями, опциями, наборами и т. Д. Это правильно?

— Payling

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

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

Запчасти не имеют «вариантов» в моем дизайне. Я определяю опцию как нечто, что входит в модель, которая предоставляет ему расширенную функциональность. Опция состоит из частей. Модель может иметь много разных вариантов. Опция может подходить для многих моделей.

— оплата

Это не так, как вы сформулировали свой вопрос. Цитата: «Например, у Модели может быть много опций, а у опции может быть много моделей. У опции также может быть много деталей, и у детали может быть много опций ... и так далее ..." В этом пункте я предлагаю вам создавать электронные таблицы, которые имитируют макет вашей таблицы и заполнять их данными. Это разоблачит любые слабости, которые могут существовать.

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

0

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

Вместо того, чтобы оставлять много неиспользуемых пустых полей в таблице Product, почему бы не добавить таблицу ModelProduct, таблицу PartProduct, таблицу ReplacementPartKitProduct и иметь только те поля, которые различны для этих типов в этих таблицах? Используйте для этих таблиц тот же первичный ключ, что и для таблицы Product. Присоединитесь к таблице Product и ModelProduct, если вы хотите работать с моделями. Нужно определить, является ли запись Продукта вашей Частью? Просто выполните левое соединение между Product и PartProduct, и если PartProduct. [PrimaryKey] не равен NULL, у вас есть деталь. Если это ноль, это не часть. Кроме того, вы можете добавить поле ProductType в таблицу Product.

— Алан Макби
источник

Пустые поля будут минимальными, потому что примерно 75% полей будут использоваться в каждой таблице. Думаю, меня больше беспокоит связь между типами продуктов. У меня будет три или около того таблицы ссылок, указывающих на одну и ту же таблицу. Model_has_Option два первичных ключа, оба идентификатора продукта таблицы продуктов, если бы я использовал только одну таблицу для представления типов продуктов. Меня больше волнует, правильно ли это делать или нет.

— выплаты

Хотя существует много факторов, которые влияют на «правильное» решение, необходимо учитывать два основных фактора. 1: общие требования к производительности; 2: адаптивность / сложность / ремонтопригодность. Один из этих двух, вероятно, немного важнее другого. Если вам нужна скорость, денормализуйте, придерживаясь варианта А. У вас будет дублирование; это ожидается. Если вам нужно регулярно работать со схемой, а скорость - это НЕ САМЫЙ важный фактор, тогда Вариант B. Вы понимаете это «правильно», зная свои приоритеты, а не придерживаясь «чужих лучших практик».

— Алан Макби