Связывание нескольких таблиц друг с другом в SQL - PullRequest
0 голосов
/ 21 июня 2010

Это более или менее вопрос наилучшей практики:

Я работаю над сайтом, который требует от меня привязки некоторых таблиц к нескольким различным таблицам. Например, у меня есть таблица комментариев, которую я хотел бы связать таким образом, чтобы можно было комментировать сущности в таблице A, но также и в таблице B отдельно.

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

Я затронул один метод, который подразумевает наличие слабой связи с таблицей отношений с PrimaryKey (Guid) и ForeignKey (Guid), а затем использование Guids в качестве первичного ключа как в таблице комментариев, так и в Rating- таблица - Однако это подразумевает, что мне понадобится Guid в качестве первичного ключа и в других таблицах.

У кого-нибудь есть здесь отличные идеи? С благодарностью:)

PS. Если это интересно, я создаю приложение ASP.NET MVC2 с ORM (EF, Linq2Sql или NHibernate .. на самом деле не имеет значения :))

Ответы [ 5 ]

1 голос
/ 21 июня 2010

Я стараюсь избегать использования одного столбца для ссылки на разные таблицы.

Я бы выбрал одну из этих трех возможностей - в порядке моих личных предпочтений:

Таблицы с несколькими комментариями

Если нет особой причины хранить все комментарии в одной таблице, я создаю таблицу комментариев всякий раз, когда она мне нужна: одна с внешним ключом для TableA, другая с внешним ключом для TableB и т. Д. Ссылочная целостность гарантируется, и тип данных столбца внешнего ключа может меняться от таблицы к таблице. Кроме того, это позволяет каждой таблице развиваться по-разному в будущем.

Одна таблица комментариев, несколько (обнуляемых) внешних ключей

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

Одна таблица комментариев, x таблиц "многие ко многим"

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

1 голос
/ 21 июня 2010

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

Comments
 - CommentID
 - CommentText

Posts
 - PostID
 - Other fields

Pages
 - PageID
 - Other fields

PostComments
 - PostID
 - CommentID

PageComments
 - PageID
 - CommentID
0 голосов
/ 21 июня 2010

Да, как вы указали, «свободные отношения», вероятно, самый простой вариант, если вы хотите отказаться от некоторых функций SQL, таких как целостность FK. Однако ради администратора запросов / администратора базы данных я бы также добавил столбец с именем таблицы, к которой относится строка. Например. Контакт (идентификатор guid), Сотрудник (идентификатор guid), а затем адрес (идентификатор независимо от , идентификатор EntityID, строка EntityType / int).

Это даст вам возможность прикрепить свой Адрес к любой таблице без ведения таблиц «многие ко многим» (где вы, возможно, добавляете проверочное ограничение для принудительного применения «один ко многим»). Кроме того, этот дизайн также позволит вам написать некоторый повторно используемый код в вашем клиенте - например,

public class Address
{
    public void Attach(IEntity entity)
    {
        // do stuff
    }
}

public interface IEntity
{
     Guid ID { get; }
}

Я впервые вспомнил, как видел это в действии в схеме базы данных MS CRM.

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

0 голосов
/ 21 июня 2010

Если возможно, я предлагаю внести некоторое наследование в базу данных - создать базовые таблицы для оцениваемых и комментируемых сущностей и ссылаться на эти базовые таблицы из таблицы комментариев и рейтингов.Это будет обычная таблица для каждой схемы наследования типов.Смотрите этот пост из блога команды ADO.NET для общего обзора отображения наследования с помощью структуры сущностей (но то же самое будет работать с большинством других картографов O / R).

0 голосов
/ 21 июня 2010

Один из способов, которым вы можете иметь прочные отношения, используя таблицу «многие ко многим» между таблицами ... Предполагая, что у вас есть таблицы «TableA», «TableB» и «Comment», у вас будет две дополнительные таблицы,один для отслеживания комментариев таблицы A, другой для отслеживания комментариев таблицы B, но только с использованием их идентификаторов.

TableAComment
    TableAId
    CommentId


TableBComment
    TableBId
    CommentId

Другой вопрос, который нужно задать себе: «Мне нужна только одна таблица комментариев?».В зависимости от дизайна остальной части приложения, попытка объединить все ваши комментарии в одну таблицу может означать больше работы, чем иметь по одному на каждого «родителя».И это может вызвать проблемы с производительностью позже, если эта таблица окажется очень большой.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...