博客网站的数据库设计

Question

我想知道这是否是一个很好的博客数据库：

这是一个具有以下特性的博客系统的数据模型：

• 用户可以注册
• 用户可以有不同的角色，例如。作者、管理员、评论员
• 博客帖子可以用eg建立。标题、内容、图片
• 博客文章可以属于许多类别。
• 博客文章可以用许多标签来标记。
• 博客文章可以有不同的状态，例如。草稿、出版、存档、隐藏

数据模型(设计)必须包括：

• 具有属性和键规范的实体
• 与基数和参与规格的关系

这是一个学校的项目，我是一个初学者。

Answer 1

我有几点意见和建议：

当您只需要为DATE的日期创建一个元素(列)时，不要创建POST表。一般来说，只有一个没有意义的ID和另一列的表很好地表明，您需要仔细研究是否真正需要的是非键列。

以CATEGORY为例，它也只有它的ID和类别描述。这是一个独立桌子的好候选人吗？有两件事需要考虑：

1. 是否可能有其他属性依赖于该类别？换句话说，职类是否应从员额中正常化？
2. 是否有可能存在没有员额的类别？换句话说，类别列表是否需要由管理员或创建帖子的人以外的人来管理？

关于另一个主题:您的模型表明，POST可以由许多USERs编写。我不确定这在您的系统中是否真的可行，因为您没有提到协作作者。然而，一个几乎可以肯定的问题是，每个用户都只能写一篇文章。我相信这不是你的意思。

要解决这个问题，您需要将USER和POST之间关系中的外键移动到post端，或者如果post可以有多个作者，则需要创建一个交叉实体。

同样的..。您的业务规则指出，文章可以有多个CATEGORY和TAG分配，但是，您的模型没有反映这一点。在您的模型中，每个帖子都可以有其中的一个。

要解决这个问题，您需要为每个标记和类别实现多到多的关系。这将在每种情况下产生一个交集表。

最后:为什么您的一些用户信息被隔离到与主用户表有多到多关系的另一个表中？可能有很好的理由将密码信息与其他用户信息单独保存在一个表中，但我认为您的业务规则中没有说明任何理由。而且，你的用户记录中的密码不太可能是多对多的.

Answer 2

作为一个新手，我建议你不要在你的系统中包含太多的实体。

• 尝试使用必要的实体(post、类别等)来完成初始项目。
• 然后，你可以考虑一些复杂的关系，并扩展你的起源系统。

你可以得到更好的设计，同时再检查你的设计。