Структура базы данных для системы комментирования сайта

Question

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

• Комментарии должны быть в состоянии разместить что-либо. Включение предметов в будущие таблицы.
• Комментарии должны быть быстро (и легко?) Запрашиваемыми.

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

Решение, которое я нашел, покажется удачным, но я также открыт для других идей. Мое решение состоит в том, чтобы использовать UUID в качестве первичного ключа для каждой таблицы элементов (университет, колледж, здание, комната), а затем использовать идентификатор ссылки в таблице комментариев, который будет UUID. Хотя я не думаю, что смогу создать систему внешних ключей, чтобы связать все, я полагаю, что ничто не сломается, поскольку только доступные элементы могут иметь комментарии, поэтому элемент может не иметь комментариев или, если он удален, то комментарии просто никогда не будут возвращены.

University:
    UniversityID - CHAR(36)  //UUID()       & primary key
    ...

Comments:
    CommentID - CHAR(36)     //UUID()       & primary key
    CommentItemID - CHAR(36) //UUID of item & indexed
    CommentUserID - INTEGER
    CommentBody - TEXT

И тогда запросы будут выглядеть так:

SELECT * FROM University, Comments WHERE UniversityID = CommentItemID;

Так что вы все думаете? Будет ли эта система масштабироваться с большими объемами данных, или есть лучший способ (может быть, Best Practice или Pattern)?

Заранее благодарю.

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

В обоих ответах Себастьяна Гуда и Брайана М. предложено, чтобы двойной первичный ключ из двух целых чисел был чем-то вроде ItemID и TableID. Мое единственное сомнение в этом методе состоит в том, что мне нужно будет либо иметь новую таблицу, в которой перечислены идентификаторы таблиц и соответствующие им имена строк строк, либо ввести в мой код глобальные переменные, ссылающиеся на них. Если нет другого метода, который мне не хватает, это похоже на дополнительный код, которого мне можно избежать.

Что вы все думаете?

Answer 1

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

UNIVERSITY
  UniversityID // assuming primary key

COMMENTS
  CommentID // assuming primary key
  TypeID  // Foreign Key
  Type    // Name of the table where the foreign key is found (ie, University)

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

Answer 2

Если вы используете UUID, трудно понять, из какой таблицы он пришел. Если вы когда-нибудь захотите посмотреть от сущности к комментариям, как в вашем запросе, все будет работать нормально. Если вы хотите посмотреть на комментарий и выяснить, на что он был направлен, вам нужно будет просмотреть все возможные таблицы (университеты, здания и т. Д.), Чтобы выяснить это.

Одна возможность, которая позволяет вам использовать простые последовательные целые числа для ключей ваших базовых сущностей (что часто желательно для удобочитаемости, фрагментации индекса и т. Д.), Состоит в том, чтобы ключ таблицы ваших комментариев содержал два столбца. Одним из них является имя таблицы, к которой относится комментарий. Второй ключ этой таблицы. Это похоже на подход, предложенный Брайаном М., хотя учтите, что вы не сможете определить внешние ключи из таблицы комментариев для всех возможных родителей. Ваши запросы будут работать в обоих направлениях, если это необходимо, и вам не нужно беспокоиться об идентификаторах UUID, поскольку сочетание имени таблицы + идентификатора будет уникальным для всей базы данных.

Answer 3

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