DB Design: Parent / Child, который учитывает как общих, так и уникальных детей

Question

[Обновлено]: см. Мой ответ ниже.

Я, вероятно, не собираюсь объяснять это очень хорошо, но в любом случае я собираюсь привести его в движение, потому что этоя ломал голову:

Простое объяснение цели : я хочу разработать отношения родитель / ребенок, которые, начиная с родителя, позволят группе / подгруппе иметьодин или несколько из:

1. подгруппа,
2. один уникальный элемент группы без дочерних элементов или
3. ссылка на общий список предметов (см. ниже).

Стена, которую я натолкнул : я знаю, что могу установить базовые отношения между родителями и детьми внутри одной таблицы с помощью parent_id столбец, но проблема в том, что многие из моих родительских / дочерних групп будут совместно использовать некоторую часть той же информации ( "список" ), и ввод и обслуживание этих подпунктов / групп в дубликате станет действительноутомительный.То, что я хотел бы получить, лучше всего изобразить с помощью следующей диаграммы и объяснения:

Groups |  Shared Lists   |  Unique Lists
-------|-----------------|--------------
Studs  |                 |  StudType
     \ |                 | /
       > Widths > Gauges >
     / |                 | \
Track  |                 |  TrackType

Пояснение ( оставить комментарий, если это не имеет смысла ):

• У меня есть два канонических родителей : Studs и Track.
• У меня есть четыре списка : Widths, Gauges, StudType и TrackType.
• ОБА * Stud и Track имеют общий список Widths.
• * 1057Элемент * EACH в Widths имеет тот же список Gauges.
• EACH Элемент в Gauges, на который ссылалась группа Studs, будет ссылаться на StudType list.
• EACH Элемент в Gauges, на который ссылалась группа Track, будет ссылаться на список TrackType.

(Примечание: я понимаю, что могу начать с конкретных и переходить к общим спискам по мере детализации (т. Е. Studs> StudType> Widths> Gauges), но для этого я хотел бы предположить,объяснение / схема выше, как это должно быть сделано.)

Мой вопрос (ы) [обновлено] : Это даже правильный способ думать о моей проблеме с повторяющимися записями?Я на правильном пути или далеко отсюда?Кто-нибудь есть какие-либо предложения о том, как я должен реализовать / переосмыслить это? Если предположить, что дизайн правильный, как, если это возможно, я мог бы ссылаться на одну комбинацию за раз, даже если они по существу существуют только в виртуальнойотношения? Я был бы очень признателен за любую помощь / направление в моей ситуации.

Answer 1

Возможное альтернативное решение

Я не специалист по дизайну БД, поэтому я хотел получить вход Пита Уилсона в свои мысли, прежде чем я продолжу дальше ...

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

* material_lists
id   name         
---+------------+
1  | Widths     |
2  | Gauges     |
3  | TrackType  |

* material_list_items
id   name         list_id
---+------------+---------+
1  | 3 5/8      | 1       | 
2  | 6          | 1       |
3  | 25ga       | 2       |
4  | 20ga       | 2       |
5  | Regular    | 3       |
6  | Deflection | 3       |

Группы материалов . material_groups был бы способ создать каскад отношения между набором материалов. Каждая группа / подгруппа может быть способ A) сгруппировать дополнительные подгруппы и / или B) назначить material_list группе, элементы которой относятся к отношениям. Каждая группа может иметь один список (хотя список можно использовать повторно).

* material_groups
id   name         parent_id   list_id 
---+------------+-----------+---------+
1  | Studs      | null      | null    |
2  | Widths     | 1         | 1       |
3  | Gauges     | 2         | 2       |
4  | Track      | null      | null    |
5  | Widths     | 4         | 1       |
6  | Gauges     | 5         | 2       |
7  | TrackType  | 6         | 3       |

Материалы . Таблица materials будет "сгенерированным" набором данных, с каждой записью, представляющей возможные отношения между material_list_items и material_groups. Колонна item_id будет представлять начальную точку для любых возможных отношений, которые может каскадом вниз от него. Например, начиная с первой записи (Studs > 3 5/8), дополнительные дочерние записи, которые будут ссылаться на эту строку будет Studs > 3 5/8 > 25ga & Studs > 3 5/8 > 20ga. Колонка group_id будет ссылка на группу, к которой принадлежит материал, который позволит повторно использовать material_list_items, при этом создавая отдельные отношения. Записи, которые не заканчиваются (не имеют детей), будут «не ссылочными» вне этот стол. Следующая таблица / пример показывает эту связь (обратите внимание на # рядом с описаниями для каждой строки для моей идеи "без ссылки").

* materials (a "generated" list)
id   item_id   parent_id  group_id
---+---------+-----------+---------+
1  | 1       | null      | 2       | # Studs > 3 5/8
2  | 2       | null      | 2       | # Studs > 6
3  | 3       | 1         | 3       |   Studs > 3 5/8 > 25ga
4  | 4       | 1         | 3       |   Studs > 3 5/8 > 20ga
5  | 3       | 2         | 3       |   Studs > 6 > 25ga
6  | 4       | 2         | 3       |   Studs > 6 > 20ga
7  | 1       | null      | 5       | # Track > 3 5/8
8  | 2       | null      | 5       | # Track > 6
9  | 3       | 7         | 6       | # Track > 3 5/8 > 25ga
10 | 4       | 7         | 6       | # Track > 3 5/8 > 20ga
11 | 3       | 8         | 6       | # Track > 6 > 25ga
12 | 4       | 8         | 6       | # Track > 6 > 20ga
13 | 5       | 9         | 7       |   Track > 3 5/8 > 25ga > Regular
14 | 6       | 9         | 7       |   Track > 3 5/8 > 25ga > Deflection
15 | 5       | 10        | 7       |   Track > 3 5/8 > 20ga > Regular
16 | 6       | 10        | 7       |   Track > 3 5/8 > 20ga > Deflection
17 | 5       | 11        | 7       |   Track > 6 > 25ga > Regular
18 | 6       | 11        | 7       |   Track > 6 > 25ga > Deflection
19 | 5       | 12        | 7       |   Track > 6 > 20ga > Regular
20 | 6       | 12        | 7       |   Track > 6 > 20ga > Deflection

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

Должен ли я пойти на что-то более упрощенное или это кажется хорошей идеей?

---

Ответ Пита: Быстро: ваше альтернативное решение похоже на ваше первое предложенное решение, поэтому мои замечания относятся к alt sol. Затем: какую возможную реальную выгоду вы ожидаете получить, навязывая структуру, не связанную с БД, в чем заключается проблема проектирования БД? Помимо того, что это эстетически приятно для вас, я не вижу никакой награды. Затем: все ваши столы перепутаны. Для БД вы выбираете почти самый неверный путь, который только можно выбрать. Опять же, почему вы настаиваете на структуре, которая НЕ является решением БД? В следующем месяце вы будете стрелять себе в голову, если будете упорствовать. Любые «каскадные отношения» должны быть (должны быть, если вы хотите оставаться в здравом уме) выраженными / реализованными так, как вы обращаетесь к к БД, не имеющей структуры .

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

Answer 2

Все следующее - мое мнение, но это хорошая практика: хорошо, наконец-то до меня дошло, что вы получаете.Да, в инвентаре, списке деталей или в любой коллекции предметов, которые вы пытаетесь отследить, может быть символ ОО (т. Е. Родитель-потомок): каждый item имеет показатель, имеет-класс, имеет-ширина, имеет-материал, имеет-перфорированные / не перфорированные, имеет-длина, имеет-финиш и т. д. прямо через список возможных атрибутов для любого элемента, включая стад, трек, #2 сосновых доски, кусок каменной породы.и так далее.И отношения родитель-потомок, которые вы хотите установить, элегантны и лаконичны.

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

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

Итак, ваш главный столдолжно быть что-то вроде этого:

  SKU  Name   length  width   On-hand   Reorder-level   Supplier
------------+-------+-------+---------+---------------+--------------- 
  321  stud    6'     2.5      21          4           Studs 'R' Us
  654  stud    8'     3.5      10          8           Studs and More        
  987  stud   10'     2.5      15         10           All Metal Stuff
  101  track  10'     1.0      45         25           Try Us First
  111  track  12'     1.5      22         15           Main St. Track
------------+-------+-------+---------+---------------+--------------- 

Ваша таблица измерений (не только калибр, тем не менее) может быть:

  SKU         Gauge   Type     Finish   Application  
------------+-------+--------+--------+------------- 
 321          .05    Normal    shiny     Outdoor    
 654          .05    Normal    dull      Out/In   
 987          .08    Light     paint     Indoor
 101          .08    HvyDuty   dull      Outdoor
 111          .60    Normal    shiny     Out/In

Возможно, вы также захотите поле максимальной нагрузки, когда клиентзвонит и спрашивает «сколько светильников я могу повесить на 4-футовую длину трека?»

Может быть, вы хотите таблицу цен:

  SKU          Qty    Price  
------------+-------+-------- 
 321          each      3.50    
 321            25     86.00    
 321           100    330.00    
 654          each      3.15  
 987          each      2.75
 101          each      4.25
 111           100     46.75

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

Теперь вы можете применить родительский элемент.Дочерние отношения путем ВЫБОРА из одной или нескольких (сколько угодно) таблиц по любым полям, которые вам нравятся, например: дайте мне все блестящие шпильки, которые стоят менее пяти долларов каждая в отдельных количествах.Или покажи мне все шпильки калибра .08 или меньше.Или [остановите меня, прежде чем я утомляю всех!], Может быть, «покажите мне все SKU и названия предметов, количество которых в наличии меньше или равно количеству уровня заказа».

То же самое с треками.

Именно так поступил бы любой дизайнер баз данных подмастерьев, и у этого макета есть еще одно преимущество: он "нормализован" (Google google).У вас есть , чтобы сделать что-то подобное.

Удачи!

HTH