【问题标题】：Enhancing the Database Design加强数据库设计
【发布时间】：2013-12-16 00:32:45
【问题描述】：

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

第一种方法：

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

分类：

分类帖子
分类类别
分类后类别

事件：

events_post.
events_category.
events_post-category。

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

数据库表太多。（这导致模型数量增加，控制器文件）
两个外键以避免关联表中的重复条目。

例如：
假设表 comments, ratings, images 属于 classified-post、events-posts 等，那么表的结构将是：
图像 [id, post_id, section] 必须存储并关联第二个 FK 部分，以避免重复发帖。

第二种方法：

这种方法将有单个帖子表，其中 section 列与每个帖子关联作为外键。即

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

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

【问题讨论】：

我很佩服那些尝试回答的人的勇气......我的 2 美分：如果你有资源，请选择选项 1。它更灵活，更容易扩展。但是，生产需要更长的时间。在采用泛化之前考虑未来的需求变化。
@Mohsen，我只是好奇为什么您必须将表名从分类帖子编辑为分类帖子，将类别编辑为类别！只是好奇..
Schema naming convention 标准化为非复数表名。
我尊重 Microsoft 对 SQL Server 数据库的命名约定。但是由于存储多个 cmets 或用户的 cmets 或 users 表，将其命名为 cmets，users 而不是（单数）评论，user 听起来更合乎逻辑。由于我正在为我当前的项目开发一个基于 Php 的框架，该框架严格遵循数据库表的复数名称，所以我最好坚持使用它。
命名完全基于意见，但请考虑一下：COMMENTS 表中的一行本身就是一个评论，就像 EMP 表中的员工一样。在这个视图中，表是由它们本身而不是它们的关系来处理的。似乎数据库设计是比微软或 PHP 更抽象的概念

标签： mysql database database-design

【解决方案1】：

出于一些考虑，我会赞成第二种方法。

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

规范化是组织字段和关系数据库的表，以最大限度地减少冗余和依赖性。
非规范化是尝试通过添加冗余数据或对数据进行分组来优化数据库的读取性能的过程。

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

可以看到一个很可能的例子here

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

【讨论】：

【解决方案2】：

方法一存在表太多的问题

方法 2 的列太多

考虑像方法 2 一样将数据存储在单个表中，但将所有可选的外键数据分开存储在 XML 中。

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

你的桌子可能看起来像

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

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

【讨论】：