Question

假设我想为社区网站设计一个包含博客，照片，论坛等的数据库，一种方法是单独列出“帖子”的概念，博客条目，博客评论，照片，照片评论，论坛帖子都可以被认为是帖子。所以，我可能有一个名为Post [PostID，PostType，Title，Body ....]的表，PostType将告诉它是什么类型的帖子。

或者我可以用更多的表格，BlogPost，PhotoPost，ForumPost来设计这整个事情，我会留下评论，只是它自己的表格带有一个CommentType列。

或者为所有类型的帖子都有一个Post表，但是有一个单独的Comment表。

要完成，我正在使用ADO.NET Entity Framework来实现我的DAL。

现在问题是，如果我采用上述任何可能影响我的数据库性能和可管理性，中间层设计和代码清晰度，EF性能等的路由，会产生哪些影响？

非常感谢！

雷

Answer 1

我问你这个问题：

如果从现在起两年后您决定添加“音乐帖子”作为博客类型，会发生什么？您是否必须为MusicPost创建一个新表，然后重新编写应用程序以对其进行集成？或者您更愿意登录到您的博客管理面板，在名为“音乐”的下拉框中添加博客类型，并以您的快乐方式进行？

在这种情况下，减少表格！

Answer 2

通常情况下，如果您可以将所有帖子放在一个表格中，那么生活会更容易：

少加入表演
维护较少的表格
表之间不重复共同属性
代码更通用

但是，您可能遇到一些问题：

如果每个子类型都有很多自己的属性，那么最终可能会有很多列 - 对于您的DBMS来说可能太多了
如果子类型具有属性（例如存储的图片），即使在未使用的情况下，DBMS也难以维护，您可能不希望所有行中都包含该列

如果你遇到这样的问题，你可以为该帖子类型的特定属性创建一个新表 - 例如：

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

问题类似于OO设计中层次结构应该有多深的问题。

OO术语中的一个简单方法是建立基类Post和BlogPost，ForumPost等子项。根据您的要求，Comment可以是Post的子项或其自己的层次结构。

然后如何将其映射到数据库表是一个完全不同的问题。 This classical essay by Scott Ambler处理不同的映射策略，并以相当详细的方式解释它们的优缺点。

数据库设计：更多的表与更少的表

3 个答案: