具有相似结构的 SQL 表 - 最佳实践

Question

假设我们有一个网站，用户可以在其中阅读文章、查看照片、观看视频等等。每个“项目”都可能被注释，因此我们需要空间来将这些 cmets 保存在某个地方。让我们讨论一下这种情况下的存储可能性。

---

分布式解决方案

我们显然可以为每个“项目”创建单独的表格，这样我们就有了如下表格：

CREATE TABLE IF NOT EXISTS `article_comments` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `createdBy` int(11) DEFAULT NULL,
  `createdAt` int(11) DEFAULT NULL,
  `article` int(11) DEFAULT NULL,
  `content` text,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 AUTO_INCREMENT=1 ;

然后显然是photo_comments、video_comments，等等。这种方式的优点如下：

• 我们可以为每个“项目”表指定外键，
• 数据库分为逻辑部分。
• 此类数据的导出没有问题。

缺点：

• 很多表
• 可能难以维护（添加字段等）

---

集中式解决方案

另一方面，我们可以将所有这些表合并为两个：

CREATE TABLE IF NOT EXISTS `comment_types` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `name` varchar(255) DEFAULT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 AUTO_INCREMENT=1 ;

和

CREATE TABLE IF NOT EXISTS `comments` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `createdBy` int(11) DEFAULT NULL,
  `createdAt` int(11) DEFAULT NULL,
  `type` int(11) DEFAULT NULL,
  `content` text,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 AUTO_INCREMENT=1 ;

表comment_types是一个字典，它包含注释项“类型”及其名称的键值对，例如：

1:Articles
2:Photos
3:Videos

表comments 存储带有额外type 字段的常用数据。

优点：

• 维护（添加/删除字段），
• “即时”添加新的评论类型。

缺点：

• 更难迁移/导出，
• 查询大型数据集时性能可能下降。

---

讨论：

• 哪个存储选项在查询性能方面会更好（假设数据集足够大），
• 再次提高性能 - 在 type 上添加 INDEX 会消除还是大幅降低性能下降？
• 就管理和未来可能的迁移而言，哪种存储选项会更好（当然，分布式会更好，但让我们看看集中式存储是否离我们不远）

Answer 1

我不确定您为选项 2 列出的任何一个缺点是否严重，数据导出很容易通过简单的 WHERE 子句完成，而且我不担心性能问题。选项 2 已正确规范化，并且在现代关系数据库中性能应该非常出色（如有必要，可以使用适当的索引等进一步调整）。

如果我能证明它对于性能、可扩展性或其他原因是必要的，我只会考虑第一个选项 - 但必须说这似乎不太可能。