Сижу, БД проектирую.
В системе есть некий "обект", с которым можно что-то делать.
Назвал это что-то заданием - "Task" (по сути - только группировка логически связанных подзаданий.).
Каждое задание состоит из подзананий - "Entry" (выполняют конкретные действия над некими элементами).
Эти Entry привязанны к различным таблицам, в соответствии с их предназначением.

В остальном структура Task и Entry полностью совпадает.
Пример диаграммы прилагается.
И таких заданий еще пять штук . А потом может быть и больше.

Если немного конкретики - то допустим система управляет устройствами, обедененными в группы.
"Task1" для группы - смена конфигурации в зависимости от фазы луны. "Entry1" - смена конфигурации отдельного устройства.
Task2 - преобразование устройства в гигантского боевого человекоподобного робота. и т.д.


Вопрос: как бы все Task и все Entry объеденить в в одну таблицу соответственно?

Можно тупо оставить одну таблицу Task и одну таблицу Entry .
Прописать в Entry какое-нибуть поле Type и на его основе принимать решение какими связями пользоваться.
Но тогда и в таблицу Task поле Type тоже добавлять надо. Ибо по логике приложения плевало оно на то какие там подзадания.

Можно слить в одну таблицу только Task. И в зависимости от типа выбирать соответствующий Entry.
Но это тоже не кошерно - дублирование информации в разных таблицах...

Может кто-нибуть посоветовать что-нибуть лишенное этих недостатков?

KGP Amdei
Можно тупо оставить одну таблицу Task и одну таблицу Entry .
Прописать в Entry какое-нибуть поле Type и на его основе принимать решение какими связями пользоваться.
Но тогда и в таблицу Task поле Type тоже добавлять надо.
А зачем в Task поле Type? Почему на один кортеж Task не может быть несколько Entry, с разными Type?
По логике - не положено.
Все Entry функционально одинаковы и принадлежат только одному Task.

KGPЕсли у вас по логике в Task должны быть только однотипные Entry, то зачем Type в Entry?Ну, в общем ты прав. Можно оставить Type только в Task. И по мере надобности его оттуда вытаскивать.

Меня смущает другое: а именно то, что если забубенить все Entry в одну таблицу, и принимать решение о том, какие связи из Entry использовать на основани Type того Task которому они принадлежат - то таблица Entry распухнет от неиспользуемых связей.
А так как большая часть Entry имеет непересекающиеся связи, то все они должны быть необязательными.
И как её целостность тогда поддерживать? Страшными тригерами в больших количествах?

Bely1) Почему должна распухнуть таблица Entry?
Если в нее не добавлять несуществующие связи, то и пухнуть она не будет.
Я в том смысле что полей для связей там будет много. Часть из них будет использоваться (в зависимости от типа Task), часть - нет.

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

Допустим Task - "Покрасить все дома в районе".
Тогда Entry - "Покрасить дом №7"
Entry привязана к таблице "Краска" (из которой берет параметр "Цвет") и к таблице "Характеристики дома", из которой берет параметр "Площадь фасада".

Так нормально?

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

Вот что у меня в результате получилось (наследование Complete и Mutually Exclusive)+
(Generate Parent+Generate Children+Inherit Only Primary Attributes).

А, пардон, в таблице Task еще поле Type наличиствует.
По значению этого поля выбирается соответствующий наследник TaskEntry и из него - все необходимые атрибуты.

KGP AmdeiА, пардон, в таблице Task еще поле Type наличиствует.
По значению этого поля выбирается соответствующий наследник TaskEntry и из него - все необходимые атрибуты.

тогда верно отобразить Task Type как отдельную типовую сущность и связь
Task 0...n -> 1 TypeА есть ли в этом смысл, при условии что кол-во различных Type - ровно 6. И изменяться не будет. А даже если и будет, то это приведет к добавлению нового наследника от TaskEntry. Т.е. один хрен к редизайну базы?
Или в этом какие-то иные преимущества?