Группировка записей с или без ограничения внешнего ключа

Question

У меня есть таблица, содержащая объекты, что-то вроде этого:

PK ObjectId 
FK ObjectTypeId 
Description 
etc 

объекты должны быть сгруппированы. Мне дали ряд предложений, все из которых «работают», а некоторые мне нравятся больше, чем другие. Ни одна из них не идеальна, поэтому я изо всех сил пытаюсь обосноваться на какой-либо конкретной модели.

1/Добавить самореферентный внешний ключ. Это чисто, но не идеально, потому что (а) нет логического родителя (это группа, а не иерархия), и (б) это потенциальная боль для LINQ-to-SQL для прохождения самореферентной иерархии - потребуется проверьте, чтобы увидеть, если текущий объект является «родителем» или «ребенок» объект и т.д.

PK ObjectId 
FK ParentObjectId 

2/Добавить родительскую таблицу & внешнего ключа. Это добавляет ограничения, но таблица Group не содержит никакой полезной информации - она ​​существует только для предоставления идентификатора GroupId &.

Table Object 
PK ObjectId 
FK GroupId 

Table Group 
PK GroupId 

3/Добавить GroupID без ограничений или внешнего ключа. Нет целостности данных. Теория состоит в том, что при вставке новой группы объектов каждому объекту присваивается GroupId = первый назначенный ObjectId. Вероятно, самое простое решение &.

например.

ObjectId GroupId 
... 
15   10 
16   16 
17   16 
... 
21   16 
22   22 

Вопрос, какой из них является лучшим в теории и/или практике, и почему. Или, пожалуйста, скажите мне лучший способ сделать это! Мне лично нравится (2), потому что это нормализовано, но мне говорят, что таблица с одним полем плохой дизайн. Мысли и предложения?

Answer 1

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

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

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

Answer 2

Для второго варианта вы всегда можете добавить дополнительные поля, для описаний, заказов на отображение и GroupParentID для нескольких уровней группировки. Кроме того, вы можете реализовать Securit для этих структур группировки.

В нашем приложении мы используем эту структуру.