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

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

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. Пожалуй, самое простое и практичное решение.

e.g. 

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

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


sql sql-server group-by foreign-keys database-design
person Kirk Broadhurst    schedule 30.09.2009    source источник
comment
реализованы ли ограничения FK на сервере sql, и вы пытаетесь их отслеживать, или вы разрабатываете базу данных с метаданными базы данных?   -  person Nick Kavadias    schedule 30.09.2009
comment
Не уверен, какой пример вы имеете в виду. Я пытаюсь сгруппировать объекты, и это предлагаемые реализации для облегчения этого требования.   -  person Kirk Broadhurst    schedule 30.09.2009

Ответы (2)


arrow_upward
1
arrow_downward

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

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

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

person KM.    schedule 30.09.2009

arrow_upward
2
arrow_downward

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

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

person Adriaan Stander    schedule 30.09.2009
comment
Совершенно верно, но пока я предполагаю, что мне не понадобится ни один из них. - person Kirk Broadhurst; 30.09.2009