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

Question

想象一下，我们有一个网站，用户可以在那里阅读文章、查看照片、观看视频等等。每个“项目”都可能会被注释，所以我们需要空间来保存注释。让我们讨论一下这种情况下的存储可能性。

分布式解决方案

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

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，等等。这种方法的优点如下：

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

缺点：

许多tables

• probably难以维护(添加字段等)

集中式解决方案

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

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是一种字典，它包含注释项"type“及其名称的键值对，例如：

1:Articles
2:Photos
3:Videos

表comments使用附加的type字段存储通常的数据。

优势：

• 维护(添加/删除字段)，
• 添加新的注释类型“动态”。

缺点：

• 很难迁移/导出，在查询大型数据集时
• 可能会降低性能。

讨论：

• 哪个存储选项在查询性能方面会更好(假设dataset足够大到足以满足这种情况)，
• 再一次提高性能--将在type上添加索引以删除或大幅减少这种性能下降？
• ，哪个存储选项在管理和将来可能的迁移方面会更好(当然，分布式存储将更好，但让我们看看集中式存储是否在很远的地方)

。

Answer 1

我不确定您为选项2列出的任何一个缺点都是严重的，数据导出很容易用一个简单的WHERE子句完成，而且我不担心性能问题。选项2是正确标准化的，在现代关系数据库中，性能应该很好(如果需要，还可以使用适当的索引等进一步调整)。

我只会考虑第一个选择，如果我可以证明它是必要的性能，可伸缩性或其他原因-但必须说，这似乎是不可能的。