database - SQL/Postgres，大表VS多表，如何进行性能测试？

Question

我在 Postgres 数据库上工作，其中有一些记录会一直被查询/访问，并且它们有数量不限的可选“元数据”，这些数据将随着时间的推移而收集。

为了说明这个想法，考虑一个像全国汽车经销商网络这样的案例。你可以有一个像这样的表:

Vehicles
--------
id
type
status
location

几乎每个查询都需要这些信息。但是还有一些可选的额外信息，例如制造商、型号、年份、里程、颜色、前车主、厂商建议零售价、蓝皮书值(value)等。

这些可能只是 Vehicles 表中的字段，或者它们可能是不同表中的字段，例如 VehicleMetadata，带有指向特定车辆的外键。

作为一个 SQL 外行，我真的不知道在一个表或两个表中这样做会有什么不同。我有兴趣了解:

1. 作为数据库专家，您将如何比较和测试这些不同的架构选项并确定哪个方案表现最佳？

2. 一种方法或另一种方法通常被认为是更传统或更标准的做法吗？

谢谢!

Answer 1

因此，对于与您的问题极为相关的背景阅读，请参阅 this link on database normalization .

让我简化一下，无论您是将所有数据存储在一起，还是存储在单独的表中，归结为查询性能与数据冗余之间的权衡。我无法告诉您应该做什么，因为我不知道您的查询负载，但这是您的想法。

冗余和查询性能之间的权衡

您拥有所有这些额外的可选字段，例如品牌(“本田”)。如果您在每辆汽车记录中存储 make=Honda，那么您将存储 Honda 数以千计或数百万次，因为 Hondas 非常受欢迎。另一方面，如果将 make 拆分到一个单独的表中，则可以存储一次 Honda 并通过主键/外键引用它。您还可以将其他数据附加到该本田值。因此，如果您将它作为一个单独的表来执行，那么每次您需要本田“事实”时，您都必须进行连接。关系数据库擅长连接，但它们仍然比将数据存储在表中慢。执行此连接的好处是您将大大减少数据库中的冗余量。如果本田被收购，更新名称会更容易，您的数据库需要的存储空间也会更少。

所以这个例子 (make=Honda) 可能会重复你的许多其他属性。从纯理论的角度来看，最好规范化您的数据库，并尽可能减少/消除冗余。从实际的角度来看，您的查询必须运行良好，并且首先必须合理编写。因此，对于大多数人来说，正确的答案是平衡这两种观点，同时了解您的查询负载是如何工作的。

好的默认建议

作为基本建议，请查阅那些规范化 Material ；我建议将 3NF(第三范式)作为您所做的大多数事情的默认基线，但需要注意的是，您可以对此做出妥协，并根据用例和查询负载进行更多(或更少)规范化。通常，您会发现高度非规范化的表(您不进行连接，所有内容都在一个表中)对于大型查询会执行得更好(假设一个好的索引策略)

性能测试

一般来说，除非您有真正需要最高性能的核心原因，否则我不会这样做。有句老话“过早的优化是万恶之源”，它也适用于数据库。要诚实地进行性能测试，您必须做对很多事情，并确保正确调整数据库的许多方面。设置此实验以获得良好的数据并不简单，大多数人发现，除非数据库变得非常庞大，否则他们根本不需要这样做。