mysql - 加强数据库设计

Question

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

第一种方法:

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

分类:

1. 分类帖子
2. 分类类别
3. 分类后类别

事件:

1. events_post。
2. events_category。
3. events_post-category.

这同样适用于文章、属性、目录等。每个部分都有三个专门用于其帖子、类别的表格。
这种方法的问题是:

• 数据库表太多。 (这导致模型数量增加， Controller 文件)
• 两个外键以避免关联表中的重复条目。
  
  例如:
  假设表 comments, ratings, images 属于 classified-post, events-posts 等，所以结构的表将是:
  图片 [id, post_id, section]必须存储和关联第二个 FK 部分，以避免重复发布。
  

第二种方法:

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

post: id, section, title 等 ....VALUES ( 1, 'classifieds','abc') (2, 'events' ,'asd')虽然第二种方法在执行 sql 查询时有点麻烦，但在执行关系表查询时简化了过程。 ex: table images, ratings, comments 属于 posts 表。
图片 [ id, post_id (FK) ]
虽然这种方法看起来简洁明了，但最终会在 posts 表中包含大量列，其中包含与事件、分类、目录等相关的列，这将在查询行和列时导致性能问题。
这同样适用于类别。它可以是两种方法中的一种，要么将 section 列保存为第二个外键，要么为每个部分设置单独的表(第一种方法)。

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

Answer 1

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

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

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

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

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

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