Вопрос о структуре базы данных: таблица со связями с таблицами прародителя / родителя / потомка

Question

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

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

Поэтому я могу выбрать одну LeakTests таблицу с общим полем FK для хранения идентификатора элемента, к которому относится тест, вместе с индикатором, показывающим, к какой таблице относится FK:

PK: LeakTestID, Int
FK: LeakTestItemID, Int
FK: LeakTestTypeID, Int
LeakageRate, Float
Result, Bit

Хранить ли FK для каждого типа в отдельном поле?

PK: LeakTestID, Int
FK: ChildID, Int
FK: ParentID, Int
FK: GrandparentID, Int
LeakageRate, Float
Result, Bit

Или я выберу 3 таблицы испытаний на утечку, по одной на каждый уровень предмета.

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

Есть мысли? Я боюсь, что требования для этой системы едва определены, и часть моей работы - бороться с бизнесом и нижестоящими клиентами, чтобы придавить обе стороны. Но как бы то ни было, я не могу быть уверен, как будут использоваться данные, и если / как, вероятно, изменятся требования.

Разъяснение : Я думаю, что бит g-parent / parent / child бросил людей - 3 уровня не идентичны, они совершенно разные, например:

ATS:
PK: ATSID, Int
MeasurementA char()
MeasurementB char()
MeasurementC char()

SleevedPair:
PK: SleevedPairID, Int
MeasurementD char()
MeasurementE char()

SleevedItem:
PK: SleevedItemID
MeasurementG char()
MeasurementH char()
MeasurementI char()
MeasurementJ char()
MeasurementK char()

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

Answer 1

Конечно, у каждого есть свои преимущества, но я думаю, что мне нравится ваш последний вариант, использующий таблицу утечек для каждого уровня объекта. Вот мои рассуждения:

Ваша первая структура, которая идентифицирует typeID и itemID, является приличной, но в результате таблица будет больше и сложнее в использовании, чем 3 отдельных.

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

Я не эксперт, только мои два цента.

Answer 2

Мой дедушка (Стив) - родитель моего родителя (Энн).

ID     Name     ParentID
1      Steve
2      Anne       1
3      Steph      2
4      Amy        3
5      Sue        3

Нет смысла хранить

ID     Name     ParentID  GparentID ChildID
1      Steve
2      Anne       1
3      Steph      2         1         4
4      Amy       ....

Я могу получить деда Стива, проверив родителей моих родителей,Кроме того, нет необходимости хранить мои дочери Эми и Сью, потому что я просто проверяю столбец parentID в первой таблице на предмет моего идентификатора (ParentID = 3).Это в конечном итоге гибко, если эти неоднозначные требования изменятся.Единственная вещь, которую иерархия не будет поддерживать, это множественные родители.Если каждый узел не может иметь не более одного дочернего элемента, вы просто переворачиваете дерево и определяете parentID как ChildID, а затем вы можете иметь несколько родителей на каждого дочернего элемента.Но только один ребенок на одного родителя.Если вам нужно много родителей и много детей, вам нужен картографический стол «многие ко многим».