Есть несколько таблиц, в которых есть группы полей одинакового типа и содержания, но они все нужны в каждой.
Что-то типа



Параметры потомка уточняют параметры родителя, если в родителе что-то не задано, применяются параметры потомка и наоборот, по этому поля нужны и там и там.

И таких таблиц 4-5.
Вопрос в том, стоит ли вынести параметры в отдельную таблицу таким образом:

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

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

Насколько я понял, в таком случае надо обеспечить,чтобы ID родителей и потомков никогда не пересекались?

И как тогда протянутся связи по внешним ключам (откуда и куда)?

Спасибо, попробую.

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

Вот такая схема настройки репликации.
Есть варианты репликации (Replication), сервера (Host).
Общие настройки таблицы (Table) и ее полей (Field).
И частные настройки сервера для данного варианта репликации (HostInstance), частные настройки таблиц конкретного сервера в варианте репликации и их полей (TableInstance, FieldInstance).
Группа повторных параметров (active, direction, mode). На самом деле их больше, но это не важно.
Хочется отделить повторные параметры...

Картинка не прицепилась...

Еще раз...

В картинке глюк, связь от FieldInstance должна идти к TableInstance.
Прошу прощения.

Единственного корня нет. Родительские объекты - варианты репликации (Replication)

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

А вообще, как правильно проектировать такие структуры, может кто сталкивался?

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

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

Как можно вынести блок параметров в отдельную таблицу при том, что он должен быть связан с другими несколькими таблицами отношением 1 к 1?