加强数据库设计

Question

我的CMS应用程序允许用户发布分类，文章，事件，目录，属性等，其数据库设计如下：

第一种方法：

每个部分（即“分类”，“事件”等）都有三个表，专门用于存储与之相关的数据：

分类

1. 分类-交
2. 分类类别
3. 分类-后类别

事件：

1. events_post。
2. events_category。
3. events_post类别。

同样适用于Articles, Properties, Directories等。每个部分有三个专门用于其职位，类别的表格 这种方法的问题是：

• 数据库表太多。 （导致模型数量增加， 控制器文件）
• 两个外键用于避免关联表中的重复条目。
  
  例如：
  可以说表comments, ratings, images属于classified-post，events-posts等，因此表的结构如下：
  图片 [id, post_id, section] 必须存储并关联第二个FK 部分以避免重复发帖。
  

第二种方法：

此方法将具有单个帖子表，其中部分列与每个帖子关联为外键。即

发布：id, section, title etc .... VALUES ( 1, 'classifieds','abc') (2,'events','asd') 虽然第二种方法在执行sql查询时有点麻烦，但它在执行关系表查询时会简化该过程。例如：表格图片，评级，评论属于帖子表。
图片 [ id, post_id (FK) ]
虽然这种方法看起来干净简单，但最终会在posts表中列出大量的列，它会包含与事件，分类，目录等相关的列，这会在查询行和列时导致性能问题。
这同样适用于类别。它可以是两种方法中的一种，将节列保存为第二个外键，或者为每个节具有单独的表（第一种方法）。

所以现在我的问题是，哪种方法被认为比另一方更好？这两种方法中的任何一种在性能方面都有益于另一种吗？或者在处理这些范例时解决的最佳方法是什么？

Answer 1

我会赞成第二种方法并考虑一些因素。

标准数据库设计指南是设计者应首先创建fully normalized dsign，然后出于性能原因执行选择性denormalization。

规范化是组织关系数据库的字段和表格以最小化 冗余 和 依赖关系的过程即可。
非规范化是尝试通过添加冗余数据或对数据进行分组来优化数据库的读取 性能 的过程。

提示： 构建第一个数据库的程序员通常主要关注性能。毫无疑问，表现很重要。糟糕的设计很容易导致数据库操作需要十到一百倍的时间。

可以看到一个非常可能的例子here

遵循上述方法的模型草案可以是：

Answer 2

方法1存在表格太多的问题

方法2有太多列

考虑将数据存储在单个表中，如方法2，但将所有可选外键数据存储为XML。

XML字段只包含特定部分所需的数据。如果添加了新的部分，那么您只需将这种数据添加到XML

您的表格可能如下

UserID  int FK
ImageID int FK
ArtifactCategory int FK
PostID int FK
ClassifiedID int FK
...
Other shared
...
Secondary xml

现在你既没有太多的列也没有太多的表