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

Question

Мне нужна помощь в структуре SQL. Я пишу статьи и хочу поделиться ими в Интернете на своем веб-сайте, чтобы пользователи могли прокомментировать их.

Каждая статья содержит имя, абзацы, разделы и блоки содержимого. Вы можете посмотреть на него как на дерево: article => paragraph => sections => блоки содержимого. Каждая статья имеет много абзацев, каждый абзац имеет много разделов, и в каждом разделе есть много блоков контента.

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

Мой вопрос - это лучший способ справиться с динамической частью, где хранить комментарии пользователей? Какое здесь самое лучшее решение?

Спасибо.

Answer 1

Мои рекомендации это создать таблицу на каждый объект, который, где хранятся комментарии.

Так, например, вы можете создать следующие таблицы:

• article_comments
• paragraph_comments
• section_comments
• blockscontent_comments

поэтому каждая таблица будет хранить родительский объект Id , идентификатор пользователя (если зарегистрирован или null, если не зарегистрирован) и комментарий.

Причина, почему я рекомендую ие использовать различные таблицы, а не только один являются следующим:

• Это масштабируемое решение в том смысле, что в будущем вы можете добавить пользовательские поля для каждой таблицы комментариев которые относятся только к родительскому объекту. Если вы сделаете это с одной таблицей в будущем, структура таблицы может стать беспорядочной с множеством полей пустой или нулевой строки.

• Ваши таблицы будут выглядеть отсортированными и структурированными.

• Если в будущем у вас будет большое количество комментариев, то ваша RDBMS займет меньше времени на запросы из разных таблиц вместо одной таблицы (а запросы становятся тяжелыми и медленнее, когда используются длинные поля text/blobs).

• Легко настроить внешние ограничения только с одной родительской таблицей, а проверки ссылочной целостности потребуют меньше времени.

Answer 2

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

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

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

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