Запись таблицы комментариев в базу данных - PullRequest
3 голосов
/ 28 ноября 2008

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

Ответы [ 6 ]

4 голосов
/ 28 ноября 2008

Одна таблица комментариев - более элегантный дизайн, я думаю. Вместо нескольких FK рассмотрим промежуточную таблицу - CommentedItem. Таким образом, Friend, Event, Group и т. Д. Имеют FK для CommentedItem, и вы создаете строку CommentedItem для каждой новой строки в каждой из этих таблиц. Теперь для комментариев нужен только один FK, чтобы CommentedItem. Например, чтобы получить все комментарии для данного друга:

SELECT * FROM Comment c
JOIN CommentedItem ci on c.CommentedItemId = ci.CommentedItemId
JOIN Friend f on f.CommentedItemId = ci.CommentedItemId
WHERE f.FriendId = @FriendId
2 голосов
/ 28 ноября 2008

Я сделал оба, и ответ зависит от ситуации. Для того, что вы пытаетесь сделать, я бы создал ОДНУ таблицу «Комментариев», а затем разделил таблицы «компоновщиков». Это даст вам максимальную производительность, так как вы можете достичь " Perfect Index ".

Я бы также рекомендовал поместить поле «CommentTypeID» в таблицу «Комментарии», чтобы дать «подсказку» относительно того, из какой таблицы компоновщика вы будете извлекать дополнительные детали.

РЕДАКТИРОВАТЬ: поле CommentTypeID не должно использоваться в индексах, а только для использования в коде.

0 голосов
/ 27 января 2009

На самом деле вы, вероятно, можете перейти к http://www.zazazine.com и просмотреть их статьи. Вы можете найти ответ там

0 голосов
/ 28 ноября 2008

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

0 голосов
/ 28 ноября 2008

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

Я полагаю, что оракул предлагает выполнить модель нормализации примерно 3-й нормальной формы.

0 голосов
/ 28 ноября 2008

Этот вопрос эквивалентен этому .

РЕДАКТИРОВАТЬ: Исходя из комментария, не ясно, что это эквивалентный вопрос, поэтому я изложу его ниже.

Оба вопроса задают о проектах (оба являются социальными сетями, но это просто совпадение), где возникает вопрос о производительности базы данных. Оба имеют разнообразный набор объектов, которые совместно используют общую коллекцию атрибутов (в одном это События, которые происходят в каждом объекте, в другом это Комментарии, которые происходят в каждом объекте).

Оба вопроса эффективно задают вопрос: эффективнее ли создать запрос UNION, который объединяет разнородные общие функции, или выделить их в общую таблицу с соответствующими внешними ключами.

Я вижу их как эквивалент; лучший ответ на один будет в равной степени относится и к другому.

(Если вы не согласны, я рад услышать почему; пожалуйста, оставьте комментарий.)

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