Дизайн БД: больше таблиц против меньшего количества таблиц

Question

Скажем, я хочу создать базу данных для сайта сообщества с блогами, фотографиями, форумами и т. Д., Один из способов сделать это - выделить понятие «пост», как запись в блоге, комментарий в блоге, фото, фото-комментарий, сообщение на форуме все можно продумать как пост. Таким образом, я мог бы потенциально иметь одну таблицу с именем Post [PostID, PostType, Title, Body ....], PostType сообщит, какой это тип записи.

Или я мог бы спроектировать все это с большим количеством таблиц, BlogPost, PhotoPost, ForumPost, и я оставлю Comment только его собственную таблицу со столбцом CommentType.

Или иметь таблицу сообщений для всех типов сообщений, но иметь отдельную таблицу комментариев.

Для завершения я использую ADO.NET Entity Framework для реализации моего DAL.

Теперь вопрос, каковы некоторые из последствий, если я пойду с любым маршрутом, описанным выше, который будет влиять на производительность и управляемость моей БД, дизайн среднего уровня и чистоту кода, производительность EF и т. Д.?

Большое спасибо!

Ray.

Answer 1

Позвольте мне спросить вас:

Что произойдет, если через два года вы решите добавить «музыкальный пост» в качестве типа блога? Нужно ли вам создавать новую таблицу для MusicPost, а затем перекодировать ваше приложение для его интеграции? Или вы бы предпочли войти в панель администратора вашего блога, добавить тип блога в раскрывающемся списке «Музыка» и быть в курсе?

В этом случае меньше таблиц!

Answer 2

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

• меньше объединений для выполнения
• меньше таблиц для обслуживания
• общие атрибуты не повторяются между таблицами
• код более общий

Однако вы можете столкнуться с некоторыми проблемами:

• если у каждого подтипа много собственных атрибутов, вы можете получить много столбцов - возможно, их слишком много для вашей СУБД
• если подтип имеет атрибут (например, сохраненное изображение), который дорого обходится вашей СУБД, даже если он не используется, вы можете не захотеть этот столбец во всех строках

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

create table posts (post_id number primary key, 
                    post_date date,
                    post_title ...); /* All the common attributes */

create table photo_post (post_id references posts, photograph ...);

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

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

Answer 3

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

Простой подход в терминах ОО состоит в том, чтобы иметь базовый класс Post и потомков для BlogPost, ForumPost и так далее. Comment может быть дочерним элементом Post или его собственной иерархии, в зависимости от ваших требований.

Тогда как это будет отображаться в таблицах БД - это совершенно другой вопрос. Это классическое эссе Скотта Амблера посвящено различным стратегиям картирования и довольно подробно объясняет их преимущества и недостатки.