PostgreSQL——把所有东西都放在一张表里？答案

【问题标题】：PostgreSQL -- put everything into one table?PostgreSQL——把所有东西都放在一张表里？
【发布时间】：2015-06-06 21:02:07
【问题描述】：

所以我正在尝试学习一些基本的数据库设计原则，并决定下载一份USDA 提供的sr27 数据库副本。该数据库正在存储有关食物的营养信息，以及有关这些营养价值如何获得的统计信息。

当我第一次开始这个项目时，我的想法是：嗯，我希望能够搜索食物名称，并且我可能想要对你最常见的营养价值（如卡路里、蛋白质、脂肪）做一些基本的统计建模等等。所以，想法很简单，只需制作 3 个如下所示的表格：

食物名称一张表
常见营养价值表（与名称的 1-1 关系）
其他营养价值的表格（与名称的 1-1 关系）

但是，尚不清楚这是否有必要。根据以下想法对列（或值）进行分区是否有任何收获：我喜欢对名称进行搜索，所以让我们将其保留为一张表以减少开销，我喜欢对常见营养价值进行数据计算，所以让我们保留它作为另一张桌子。（问题 1）或者正确的索引是否使这个没有实际意义？

我的下一个问题是：美国农业部到底为什么决定使用 12 张桌子？这是否被认为是良好的数据库设计实践，或者合并很多这些表会更好？（此节选摘自上面 USDA 链接中提供的 PDF，第 29 页）

【问题讨论】：

标签： sql postgresql database-design

【解决方案1】：

您是否从基于分区的列（或值）中获得了什么？关于这个想法：我喜欢搜索名字，所以让我们将其保留为一个表开销更少，我喜欢对常见的数据计算营养价值所以让我们把它作为另一张桌子。（问题 1）还是正确的索引使这没有意义？

如果您只有一个项目列表，并且只想总结其中的一些，那么索引是解决性能问题的方法，而不是任意将一些拆分到另一个表中。

另外，请阅读规范化。

我的下一个问题是：美国农业部到底为什么决定使用 12张桌子？这是否被认为是良好的数据库设计实践，或者会他们最好合并很多这些表？（这段摘录摘自上面 USDA 链接中提供的 PDF，第 29 页）

可能是因为他们想问的问题类型与您想问的问题类型不完全相同。

他们显然有关于每种食物的更多信息——比如组别、营养成分、重量，而且他们显然也在跟踪源数据的来源......

【讨论】：

感谢您的回复。所以我阅读了关于 DB Normalization 的 Wiki。看来我的方案偏向于特定的查询，应该避免这种情况。因此，为了应用这些实践，在构建逻辑方案时，我基本上应该将任何实体（名称、组、营养、统计数据等）假装我需要对其进行修改并寻找可能的异常情况。例如，将食物组与名称放在一起会使组重命名潜在异常。基本上我正在学习我应该将逻辑设计和物理设计分开？
当然逻辑不等于物理。但不仅如此，您需要每一行基本上代表一个且仅一个事实或真相，然后将一堆这些与其他行链接以获得有意义的信息。这部分需要练习，您可以学习一些规则，了解如何在各种“范式”中实现这一点

【解决方案2】：

有一些与设计关系数据库相关的重要规则 - Normal forms - 可以减少一些人工制品并减少 IO 操作。这种设计对于 OLTP 数据库很常见——我有可能看到可怕的慢速数据库，因为开发人员对此一无所知。分析型数据库 OLAP 略有不同 - 使用了宽表，并且一些具有列存储的现代 OLAP 数据库支持它。

PostgreSQL 是经典的行存储数据库 - 所以一张表并不常见，这不是一个好的策略。您可以使用view 创建一些典型且经常使用的数据视图 - 这样复杂的模式对您来说是不可见的（透明的）。

【讨论】：

我明白了。（我们假装我的食物数据库很大）。因此，如果我的数据有两种用途：一种用于搜索和修改，另一种用于大数据分析，那么我最好有两个不同的数据库来做这件事？我只是想确保我理解您的回复:)
这取决于数据库的大小-对于小型项目分析数据库不是必需的-对于一些大数据（超过100GB）-具有针对分析优化的数据的特殊数据库是常见的。