Лучшая архитектура sql для самостоятельного соединения, используемая в EF

Question

У меня архитектурный вопрос о самосоединении.

У меня есть таблица объектов с уникальным int-идентификатором.Объекты могут существовать изолированно или как часть набора объектов.Коллекция представлена ​​в виде объекта в той же таблице, но ее тип установлен как коллекция.

например,

1 | ObjectName | IsolatedObject
2 | CollectionName1 | CollectionObject
3 | CollectionName2 | CollectionObject

Объект ранее мог принадлежать 0 или более коллекциям, поэтому у меня был другойтаблица, в которой хранятся сопоставления

например,

2 | 1
3 | 1

Было принято решение, что теперь они могут принадлежать только 1 коллекции.Мой вопрос: лучше ли сохранить существующую дополнительную таблицу или изменить таблицу объектов, чтобы иметь поле ParentID, в котором хранится уникальный идентификатор?

Это также используется с EF, поэтому сопоставление отношений может усложниться.

Спасибо за любую помощь заранее.

Answer 1

Ваша таблица сопоставления является хорошим «расширяемым» решением, если в дереве есть несколько групп, но это излишне, если есть только один «уровень» группировки. IE: если коллекция объектов может иметь мастера и НЕ быть мастером для чего-либо еще, то непременно сделайте самостоятельное соединение. Однако, если коллекция объектов также может быть главной, ваше текущее решение для отображения будет лучше.

Причина этого в том, что "тебе нужно ходить по дереву?" Чтобы вернуть все отношения в SQL, вам потребуется запросить таблицу для каждого уровня (рекурсивный). Если только изолированные объекты могут быть основными, то один запрос может вернуть все значения

Answer 2

В целом применение ограничений целостности на уровне приложения (иначе говоря, оставление структуры данных без изменений) не вызовет проблем сразу, но, скорее всего, в долгосрочной перспективе.Оставлять структуру данных как есть может быть хорошим промежуточным решением до тех пор, пока конечные пользователи не смогут изменить все данные, чтобы они соответствовали новой политике / требованиям, но в моем офисе есть поговорка: «если данные можно будет поместить туда,это будет помещено туда ';Это означает, что если ссылочная целостность позволяет, вы можете поспорить, что это произойдет.

Я бы посоветовал как можно быстрее перейти к модели ParentID / Self-referenceinging, если это решение действительно моделирует требование.;конечно, это должно быть сбалансировано с бюджетом, временем, обязательствами пользователей и т. д. *