SQL :在“一个表多列”和“多个表多时间查询”之间

Question

我的网站有一个邮政系统，有3种类型的帖子。

1. 图片
2. 视频
3. 转贴

我使用4个表来管理这些数据。

1. 帖子
2. 图片
3. 视频
4. 转贴

每个图片，视频，转发，张贴到网站将有一个帖子行，以保持喜欢，评论，等等。

我不得不询问有多少次评论被喜欢或什么东西被删除。

我想知道在

1. 一个表，许多列，许多空行，一次查询
2. 多个表，较少的空行，多次查询

哪个更好，哪个更快？

Answer 1

“哪个更好，哪个更快？”

我不认为这两个选项都更好、更快--一个表通常更快，多个表更“好”，因为它更容易维护，不会导致重复数据。如果您主要关心的是检索速度，那么有一个表是合理的，否则我将坚持规范化normalization。

即使有多个表，好的索引也会对检索速度产生巨大的影响，正如其他人说的那样，可能值得考虑一个视图/存储过程来将数据集中在一起。

Answer 2

就像这些类型的问题一样，这个答案是“它取决于”。

我建议您尝试创建一个数据视图，将4个表编译成一个单行、多列的结果集。您甚至可以索引此视图，如果需要，还可以对视图进行INSERT INTO。这将使您很好地了解您希望如何建模您的数据。

你有一个极端：

• 需要多个索引的多个表(如果您希望保持所有的活力，就像它是一行一样)将需要更多的存储空间。
• 但这也意味着您可以将数据表存储在不同的文件组和存储区域中，这样更大、更昂贵的二进制数据就不会占用更昂贵的驱动器空间。

在另一个极端，您有：*一个不需要连接的表，它在那里就有它所需要的全部*但是有一个存储在一个文件文件组中的负担，并且随着您添加更多的post类型而失控地增长。

在中间的某个地方，你有(索引)视图。

Answer 3

这个问题没有简单的答案。

如果您将数据拆分到多个表上，那么您需要编写更复杂的SQL，但是数据库管理员可以将每个表放在不同的磁盘上，以便更快地加载数据。

搜索性能不受此影响，因为索引可以放在不同的磁盘上。

因此，这取决于数据库体系结构、数据量、索引以及它们如何分配给磁盘，以及数据库优化器是否选择正确的策略。