用于度量存储的关系数据库模式设计
Relational Database schema design for metric storage
考虑具有以下特征的系统：
- 存储从多个 sensors/inputs 收集的时间序列 data/metrics。
- 数据点（指标）是在不同时间从许多不同系统收集的。
- 这些指标中的每一个通常都是一个数据点（例如，温度和湿度不会同时报告，而是单独报告，并且会有不同的时间戳）
- 收集的指标类型将随着时间的推移而扩展 - 系统是开放的，并且随着时间的推移将支持额外的输入（例如，今天我们收集温度、湿度和 cpu，明天可能会添加一个传感器监测二氧化碳和内存）。
- 需要通过查询获取给定时间段的所有指标的摘要，这可能是最常见的查询场景。
我可以想到三种建模方法。
1.宽 table - 每个类别 table（涵盖）
注意：由于数据点是单独收集的，所以有很多稀疏值。存储新指标需要一个新列
2。缩小 table - 每个指标 table（涵盖）
注意：新指标的存储需要新的 table
3。键入 table（未涵盖）- 具有单一指标 table（未涵盖）
注意：新指标的存储只需要在 metricType table 中添加一个新行，无需更改架构。尽管按时间桶对所有指标进行分组不需要连接，因此可能会更快，但是否担心块大小对性能的影响？
我想知道是否有人可以发表评论或提供的选项，向我指出一些性能基准，包括 3 以及 1 和 2，或者一般就每种方法的适用性提供任何建议。我计划 运行 我自己的实验，完成后我会 post 结果，但在此阶段的任何见解都将不胜感激。 :)
请注意，不要建议 nosql 解决方案，我知道其中的选项 space 并且正在单独评估该选项
这在很大程度上取决于您需要 运行 的查询类型。我认为性能可能不是你最关心的问题，如果像你说的那样
A summary of all metrics for a given time bucket needs to be obtained
via a query and it likely to be the most common querying scenario.
由于所有场景中的查询都会命中可索引的时间戳列，这实际上只是连接性能的问题，而且几乎每个关系数据库都非常擅长于此。
如果您的查询真的只是 "show data for a time range"，从开发工作的角度来看，您的选项 3（entity/attribute/value design）是最有效的。 .
您的查询将具有单个内部联接，并且时间戳列将提供良好的索引。正如您所说，在收集新的测量点时，您不需要更改架构或查询。
替代设计需要每个 table 的外部连接。就性能而言，这没什么大不了的，但管理模式和相关查询会很痛苦。
但是，如果您还必须回答类似 "on what day was CPU above 30% while humidity was below 56% for more than 3 hours" 的问题，您的 EAV 模型将变得 非常 难以使用。这些查询很快就会变得非常难以编写和理解 - 每个条件都至少变成 1 个自连接。
确实，方式3是一种关系存储上的EAV建模，包括时间戳到EAV密钥中。
+---------+ +-----+ +-------------+
| Sensors | -- 1:M --< | EAV | >-- M:1 -- | Value kinds |
+---------+ +-----+ +-------------+
A summary of all metrics for a given time bucket needs to be obtained
via a query and it likely to be the most common querying scenario
如果查询不需要连接但需要按时间分组，timestamp 列上的聚集索引可确保性能。
但是，任何带有连接的查询（即比较不同传感器的值）都有降低性能的风险。解决方案可以是单独的 OLAP 存储，用于收集的 EAV 数据。
从开发者的角度，我更推荐第三种方案。在第三个选项中，您可以考虑在 MetricType（即 typeId）和 timestamp 列上建立索引，这将极大地优化查询性能。
而您的第一个 table 需要系统停机时间，因为当需要插入新列时，您需要先关闭您的实时系统以添加该列，使用一些默认值或空值进行初始化，然后让系统恢复正常。在我看来，从它被添加到系统中开始，它将包含前几行不必要的数据（垃圾）。数据库 table 的大小将非常大，并且可能包含大量垃圾数据，从而影响查询时间。
第二个想法比第一个想法有所改进，但是，尽管有垃圾数据，这将需要连接多个 tables，这将随着时间的推移提高查询性能。您不能像第三个选项那样在多个 table 上建立索引。
所以我觉得第三个方案是最有效的。 table 被规范化，有效的索引将提供高效的查询结果。
我想提出另一件事。您也可以考虑使用单独的 table 来包含聚合数据。例如，如果您的系统需要聚合数据，您可以考虑将非规范化样式的数据放在单独的 table 中，其中可以存储特定时间线的聚合值，以便您可以从原始 table 中删除数据=24=] 已被处理。我指的是您可能考虑查看的 OLAP 数据库。
我不推荐 ERD 设计，无论何时添加传感器都需要进行更改（只要您知道自己会这样做）。这就是为什么我认为您应该消除选项 1。每当您更改 table 时，您将获得大量空值和代码中可能有的不必要的工作。
这同样适用于选项 2，可能除了空值，但无论何时向系统添加新数据源，您仍然会进行不必要的工作。
选项 3 看起来很适合我，因为它可以扩展数据源并保持数据干净整洁。
1 个提案
"宽table"
存在严重的规范化错误（而且，如果认真对待，它会存在大量空值和完整性问题）。无法使用，无需进一步评论。
"窄table"
没有错误，但规范化尚未完成。
"已输入 table"
这有点完整，是您的三个场景中的“最佳”场景。但它通过狭隘的视角来看待问题，并且完全脱离问题存在的背景。因此，由于您查询的原因以外的原因，它是错误的。
2个问题
第一个问题是你在比较三个不合理可比、不合理相等的东西。
第二个问题，EAV是当月的味道，吸引了很多人。但是，它存在重大问题，如果要实现具有一定数据完整性，则需要一组额外的“元数据”table。关键是，不需要EAV。
3 解
The types of metrics that are collected will expand over time - the system is open and additional inputs will be supported over time (e.g. today we collect temp, humidity and cpu, tomorrow a sensor maybe added that monitors co2 and RAM).
这实际上是一个straight-forward关系型数据库问题，通过完美普通的Relational设计解决，提供了充分的Relation Power；关系完整性；和速度（其他设计不会有）。
3.1 警告
但是有一些注意事项，因为作为“关系”销售的并不是关系。
去掉Record ID字段，它们是anti-Relational.
Record IDs 将您的架构缩减为 1970 年代风格的记录归档系统（为方便起见，位于 SQL 容器中）。Record IDs 不提供 关系模型 所要求的行唯一性。- 此外，每个文件需要一个附加字段和一个附加索引。
在对数据库建模时（关系或非关系），将数据视为数据，除了数据之外别无其他。不要根据您需要的 GUI 或某些查询或其他方式查看数据。
在此（建模）阶段关注性能问题是错误的。先把它弄好。第二，要快。不要颠倒规定的顺序。
关系键提供意义，以及关系完整性（这是逻辑的，与引用完整性不同，后者是 SQL 的物理设施）。这解决的是对象存在的上下文。
- A
Sensor 不是孤立存在的（除非它在商店货架上的包裹中......但即便如此，它也存在于商店库存的上下文中）
- 活动的
Sensor 仅 存在于其所在对象的上下文中。您尚未提供任何相关信息。让我们把这个东西 Article 称为通用标签。
- 此外，
Article 要求限制传感器测量的指标（用于 out-of-range 警报等），而不是传感器本身。 （传感器可能有一个范围，这是另一回事。）
- 同样，
Sensor存在于Location中，这是第二个向量。否则，Article存在于Location中，Article Key携带Location。我模拟了后者。
3.2 数据模型
解决方法如下：
Sensor Data Model
内联图形可能不会在某些浏览器中显示。在那种情况下，这里是 PDF.
满足OLTP和OLAP(Dimension-Fact)需求
- 如果您提供更多的背景信息，我们可以精确地建模。这可能需要一点 to-and-fro.
仅限于提供的信息。
- 我把
MetricType和SensorType当成了同义词
Article 显示为依赖于（存在于）Location，或者它们可以是单独的向量。无论如何，Article 和 Location 一起符合条件 Sensor。- 因为
SensorSerialNo是唯一的（AK2），所以Reading(SensorSerialNo, DateTime)也是唯一的。不需要索引。但是，如果仅通过 SensorSerialNo 对Reading 有很多查询，这样的索引将提高性能。
欢迎提问，我会一一解答
IDEF1X新手请参考IDEF1X Introduction.
熟悉IDEF1X，只想要一个brush-up的朋友，参考IDEF1X Anatomy.
4 性能
您对性能的关注不错，但在现阶段应用还为时过早。首先获得正确的数据模型，其次快速获得数据结构。原因有很多，其中最重要的是，当数据被规范化时，关系结构已经非常快了。此外，永远不要针对特定查询进行优化（如果需要，可以在第二阶段添加索引）。
不过，我会回应您提出的问题。
- 例如。规定的
Reading PK 上的 ClusteredIndex 将：
- 服务大多数查询，大多数维度（使用
SensorSerialNo 单独 的查询除外，在这种情况下我建议使用额外的索引）
- 服务所有 OLTP 事务并确保最高并发性，因为
Sensors 分布在现实世界中：跨越 Locations 和文章。
- 而
Record ID 上的索引保证了每个 INSERT 上的热点。非常适合制造死锁。
4.1 基准
我确实有大约一百个这样的数据结构基准，这些基准是在过去四十年中为 OLTP 和 OLAP 使用收集的。我的大多数客户都是银行（想一想：传感器读数非常像在一天内变化的股票价格；几个向量（维度）；数十亿行）。银行对保密性非常严格，所以我不能按原样发布基准测试，并且编辑它们需要时间和精力。
我确实有一个非常相似的要求的基准，即 public。事实上，它已包含在针对固定 DDL（时间序列数据）和总体的 Sybase ASE 与 Oracle 10.2 基准测试的 Answer to a SO Question re Time Series data, but the seeker got the moderators to excise it (it is embarrassing to Oracle). Here is the Benchmark Summary 中。
最后，所需的结构和代码非常简单，您可以运行自己的基准测试。
5 对其他答案的回应
Re Neville 的评论：
However, if you also have to answer questions like "on what day was CPU above 30% while humidity was below 56% for more than 3 hours", your EAV model becomes really hard to work with. Those queries would rapidly become really hard to write and understand - every criterium becomes at least 1 self-join.
注意到他的评论与 EAV 有关，但这可能意味着它同样适用于主题 table（普通关系数据库 table (non-EAV) Reading) 在这种情况下，因为它涉及查询类型（而不是 EAV 概念与关系概念）：
该声明不适用于关系 tables（它很可能适用于 EAV；由于记录 ID 而引入的大量问题；等等）
只要你有
- 真正的关系数据库模式（如我所建议的），以及
- 一个真正的SQL平台（不是假冒的“sql”，它不符合规定但冒用了名称），并且
- 你了解
IN和NOT IN，以及如何比较集在SQL
...这样的查询是straight-forward代码。
6 条评论回复
记录 ID 为 Anti-Relational
Do you have any links on the record_id being anti-relational, I don't disbelieve you for a second but I'm interested to learn more about why this anti-pattern is so prevalent.
在 anti-science 的混乱中，学术界制造并设计出各种 关系模型 中不存在的“问题解决方案”，然后关于 non-problem 的哪个更正更好或更差，你有第二层无休止的“辩论”。
您不需要链接，因为没有什么可“辩论”的，而且您可能碰巧读到的任何“辩论”都忽略了上述要点。
唯一的权威是伟大的 E F Codd 博士。所有声称与关系模型有关的书籍和教科书的作者，除了 Codd，实际上都是假的，他们是关于实施 1970 年代风格的记录归档系统，并且 anti-Relational（没有关系权力；没有关系完整性；没有关系速度）。他们犯了一个错误，从 1970 年开始，他们试图将 RM 融入他们 1970 年代的 RFS 思维模式，而不是发布它并采用 RM 思维模式。在过去的五年里，他们一直在强化这一点，甚至用“数学定义”来证明这一点； 17“关系代数”； 42种异常的“正常形式”。全部完全anti-Relational。他们互相引用，所以他们发表了。
第二个问题是，像SO这样的网站是建立在民粹主义基础上的。流行的答案不是最好或正确的答案。为此，你需要一个权威（这对民粹主义者来说非常可怕）和 objective，绝对真理。 （人们喜欢他们的相对或主观的“真理”，它们一直在变化）。
因此，你只需要单一的、权威的定义，原始论文，Relational model。
- 是的，这些术语是 out-dated，现在还不是很了解。
- 是的，它是开创性的（字字珠玑，意义深远）。
- 不，您不需要阅读第 2 部分（数学）。
你需要从中收集信息，即：
关系键是“由数据组成”（我的解释是，对于几个条目，它们是 RM 中的层），它是合乎逻辑
代理人 (a) 不仅违反该定义，(b) 他们pre-Relational 范例，即 Physical 指针，RM 所取代的东西，并且 (c) 明确禁止。
非常重要，你不仅要了解Relational Key的定义，还要了解whys和wherefores。
- 例如。它超越了 import/export 系统存在的 pointer-based 问题。
- 例如。时间定义（开创性的；8 个字母；可怕的）。
因此，没有争论，没有“争论”。
- 任何反对的人都是 anti-Relational。不是因为我这么说，而是因为它与事实证明和单一权威相矛盾。
- 我已经指出了正确使用 RM 的明确技术优势（关系能力；关系完整性；关系速度），但是扩展它需要大量的努力
- 不遵守 RM 的后果是，您将获得 (a) none 的好处，并且 (b) 您会遇到 pre-Relational 记录归档系统存在的全部问题1970 年，以及 (c) 从未奏效的“学术界”提供的人为“解决方案”。
如果你需要扩展RM的那些好处，当然你需要一定程度的了解，因为每一个都很深很重要，我能提供的最好的是这个。正如您所想象的，这是一场我必须为与该主题相关的每个答案而战的战斗，因此多年来，我 post 编辑了很多答案。
- 转到我的个人资料，select 所有答案，然后阅读与此主题相关的任何内容。
为什么这个记录 ID anti-pattern 如此流行？
简短的回答是，人们热爱他们的无知，他们的主观“真理”，并且会竭尽全力保护它。他们很快接受并重复任何保持不变的理由。从他们所知道的东西中学习范式转变的东西是非常可怕的，因为它威胁到他们的舒适 table 无知，并暴露它的真实面目。他们将不得不承认，他们已经写了五个十年的东西是错误的。这就是民粹主义蓬勃发展的原因。无知中。
稍微长一点的答案是这样的。只要看看互联网。在过去，对于任何特定主题，我们都有一个来源，一个绝对权威：例如。购买大英百科全书；整个童年都在吞噬它。永恒的真理。诚实的历史。但是现在任何人只要有一个键盘和两个手指加上一些结缔组织（不需要大脑）就可以 post。作为即时的“权威”。网络是 chock-full 的 (a) 肤浅的答案（anti-thesis 的“现在这就是答案”）(b) 由于民粹主义 (d) 而受到支持的多种口味 (c)离正确或完整的答案还很远。大众可以很容易理解的声音片段。很少有人想要完整答案的深度。
即使建立了某种权威（例如维基百科；Stack Overflow），它也很容易被颠覆，因为实际上有数百万人更改条目（因此，只要某些东西不变，真理就不会改变正在改变，这不是事实）。主要是为他们的政治立场服务；他们的意识形态；他们的 re-writes 历史让过去变得错误（不是，它已经发生了），而现在的疯狂“很好”。
最终的答案是：学术羡慕。 Codd 的 关系模型 花了整整十年的时间才被理解和接受。即便如此，也只有少数人。 IBM 和 Britton-Lee（成为 Sybase）在精神和语言上实现了 Codd 的 RM。 （Digital Equipment Corp 也这样做，但他们已经不复存在了。）那些看似与 Codd 合作的学者实际上是在反对他（根据证据）。他们讨厌这样的事实，因为他们不是自己想出来的，一个人想出了第一个真正的模型，有声音；合乎逻辑的；数学，基础，完成关系代数。全部集成。当天的所有要求（例如材料清单问题）都得到了答复。这经受住了时间的考验：五年来没有添加或更改任何内容。
通常他们会声明，“但 Codd 没有定义这个或那个，所以我在这里定义它......”。所以他们想出了自己的 RA。现在他们有 17 个，都无关紧要。和异常的“正常形式”将他们的记录归档系统的碎片部分提升为看起来“相关”。现在他们有 42 个，都无关紧要。还有很多书，号称是“关系”，但事实证明，anti-Relational。每个“学术”都试图加强他们的“学术”地位，以对抗所有其他人。
这就是为什么我再次说，去找唯一的作者泰。不要阅读 anti-Relational 人群中的内容，因为它会削弱您对 RM 的理解（最好的情况），或者毒害您的思想（最坏的情况）。
一个澄清
如果您检查关系 PK（例如）Location.Location，它可能看起来很奇怪。这是用户实际使用的 %Code 或 %ShortName 数据。通常为 4 到 6 个字符，最多 12 个。与必须存在的长 Name 不同，它是备用键。当然，它绝对不是任何类型的数字（这不是数据，不是用户使用的东西）。用户也喜欢他们的简短形式。显然，如果存在国际标准，请使用任何国际标准。
Key必须是stable（不是静态的，宇宙中没有什么是静态的），在现实世界中用来唯一标识对象（数据行）的。
例如。对于Security，这是一家在证券交易所上市的公司，在美国是TickerSymbol，在澳大利亚是ASXCode。 ISO 代码，一个 ISINCode，是一个 AlternateKey。
对于城市，使用其中一种地理位置标准：ISO； FIPS；等等（我使用 Statoids 因为它早于其他人存在，但那些日子已经屈指可数了）。在最坏的情况下，使用机场代码。
正版SQL平台
What do you consider to be genuine SQL? Sql Server, Postgres, MySQL, Oracle I guess all would be?
没有。我的意思是任何 实际上符合 已发布的 SQL 标准，因此可以 实际上支持 关系 table 的平台；集合的关系处理；和 ACID 交易。
- 这自动排除了 freeware/vapourware/nowhere/“开源”，其中的位由遍布整个宇宙的 10,000 名开发人员编写，没有任何管理原则。例如。没有 ACID 事务或它所需的结构，每个代码段都需要这些。现在插入太迟了，因为它需要 100% re-write，但愿...服务器架构。
商业
这意味着 paid-for 和支持，也很重要。要么您有维护合同并且支持是即时的，要么您 post 错误报告并且您每天检查未来一年或三年的更新。
服务器架构
如果需要可伸缩性或性能（高吞吐量；高并发；低延迟），那么服务器架构是最重要的。同样，这不包括免费软件和 Oracle，因为它们没有体系结构，它们是大量交互程序的集合，可以 o/s 执行架构数据库服务器通常执行的所有功能。
检查此 Comparison of Oracle vs Sybase Architecture。
- 同样适用于 PostgreSQL 和其他免费软件。 PostgreSQL（彻底失败的 Ingres 之子）因压力大而失败，大量锁定问题和非常低的并发性。
1 High-End，商业，SQL 合规
大约 5% 的市场份额，但占金融服务和自动化市场的 95%。伟大的建筑，无望的营销。
- **Sybase ASE
- IBM DB2**
2 商业，SQL 合规
- MS SQL 服务器
很容易成为最常见的。 Good Architecture（最初是从 Sybase 偷来的），然后以通常的疯狂 MS 风格“进步”。使用痛苦；大量的开销；与各种 add-ons 和 must-uses. 的集成不佳
3 商业，SQL Non-Compliant
无望的架构，伟大的营销。
甲骨文
通常，Oracle 开发人员非常擅长以使其正常工作所需的方式使用该产品，但这意味着他们已经偏离 关系模型.
- 例如。在 Time Series benchmark 中，重点是，当请求子查询时，Oracle 会自行处理，因此它必须使用“内联视图”。 OP 声称它与子查询一样快（避免了它需要更多代码的事实，并且编码器必须跳出关系思维模式）。在每个测试场景中，基准被证明是非常错误的（Oracle 在
COUNT() 上比 Sybase 慢 3 到 4.8 倍，26 到 36 倍 在 SUM() 上较慢
- ...并且必须在 120 分钟.
后放弃子查询（Sybase 2.1 秒）
- 例如。 Oracle 是 non-compliant re ACID Transactions，开发人员在一定程度上解决了这个障碍，但 Phantom Updates 和 Lost Updates（技术术语）根本无法避免。如果 work-arounds 没有正确写入，整行（
UPDATES 或 INSERTS 都会丢失）。
- 所有适用于以下...
4 Non-Commercial, SQL Non-Compliant
这些人花了大量时间开发 n 个“功能”关系数据库不需要，但对 anti-Relational 记录 ID 归档系统非常有吸引力。
- 例如。 “延迟约束检查”；
ENUMs;等等
- 他们缺乏 SQL 合规的基础知识。例如。没有真正的 ACID 交易。
此外，如上所述，零架构。这导致系统在 single-use 下表现出色，并在并发或可伸缩性的任何压力下惨败。
由于他们 non-compliance 与 SQL 的要求，他们煞费苦心地 post 在命令手册的每一页上都写了一个合规通知。 （只需要手册前面的一个合规声明即可。）当然，缺少的命令只是缺少，所以哎呀，他们没有合规声明。
PostgreSQL
自 Ingres 时代以来我不得不检查的最糟糕的软件。深受“学术”人群的喜爱，只因它是一位“学术”同胞的潦草涂鸦。
5 user max，或者处理并发问题（粗略看一下SO上报的问题）。
MySQL
高于 PostgreSQL，但仍属于此类。
- InnoDB 引擎在性能方面明显更好，但远不及 Sybase/DB2 水平（仍然不是真正的服务器架构）。 SQL non-compliance部门没有喘息的机会。
5 摘要
一分钱一分货。
- 服务器架构，最明显的是在每个场景中的性能。
- SQL 合规性，经过深思熟虑，并在每个适用的代码段中实施。
- 最后但同样重要的是，支持。
无论您选择什么，请记住，当您将其移植到另一个平台时，您的 SQL 代码将需要一个完整的 check-and-change，因为 SQL（或 NON-sql) 非常不同。对于 Non-Commercial 程序套件，这意味着完全重写。因此慎重选择，着眼于长期实施。
TimescaleDB 的文档讨论了宽数据模型与窄数据模型：
https://docs.timescale.com/timescaledb/latest/overview/data-model-flexibility/
总结：
- “如果您独立收集每个指标，那么窄模型是有意义的。它允许您通过添加新标签来添加新指标，而无需正式更改架构。”
- “如果您通常一起查询多个指标，以宽 table 格式存储它们会更快、更容易”
考虑具有以下特征的系统：
- 存储从多个 sensors/inputs 收集的时间序列 data/metrics。
- 数据点（指标）是在不同时间从许多不同系统收集的。
- 这些指标中的每一个通常都是一个数据点（例如，温度和湿度不会同时报告，而是单独报告，并且会有不同的时间戳）
- 收集的指标类型将随着时间的推移而扩展 - 系统是开放的，并且随着时间的推移将支持额外的输入（例如，今天我们收集温度、湿度和 cpu，明天可能会添加一个传感器监测二氧化碳和内存）。
- 需要通过查询获取给定时间段的所有指标的摘要，这可能是最常见的查询场景。
我可以想到三种建模方法。
1.宽 table - 每个类别 table（涵盖）
注意：由于数据点是单独收集的，所以有很多稀疏值。存储新指标需要一个新列
2。缩小 table - 每个指标 table（涵盖）
注意：新指标的存储需要新的 table
3。键入 table（未涵盖）- 具有单一指标 table（未涵盖）
注意：新指标的存储只需要在 metricType table 中添加一个新行，无需更改架构。尽管按时间桶对所有指标进行分组不需要连接，因此可能会更快，但是否担心块大小对性能的影响？
我想知道是否有人可以发表评论或提供的选项，向我指出一些性能基准，包括 3 以及 1 和 2，或者一般就每种方法的适用性提供任何建议。我计划 运行 我自己的实验，完成后我会 post 结果，但在此阶段的任何见解都将不胜感激。 :)
请注意，不要建议 nosql 解决方案，我知道其中的选项 space 并且正在单独评估该选项
这在很大程度上取决于您需要 运行 的查询类型。我认为性能可能不是你最关心的问题，如果像你说的那样
A summary of all metrics for a given time bucket needs to be obtained via a query and it likely to be the most common querying scenario.
由于所有场景中的查询都会命中可索引的时间戳列，这实际上只是连接性能的问题，而且几乎每个关系数据库都非常擅长于此。
如果您的查询真的只是 "show data for a time range"，从开发工作的角度来看，您的选项 3（entity/attribute/value design）是最有效的。 .
您的查询将具有单个内部联接，并且时间戳列将提供良好的索引。正如您所说，在收集新的测量点时，您不需要更改架构或查询。
替代设计需要每个 table 的外部连接。就性能而言，这没什么大不了的，但管理模式和相关查询会很痛苦。
但是，如果您还必须回答类似 "on what day was CPU above 30% while humidity was below 56% for more than 3 hours" 的问题，您的 EAV 模型将变得 非常 难以使用。这些查询很快就会变得非常难以编写和理解 - 每个条件都至少变成 1 个自连接。
确实，方式3是一种关系存储上的EAV建模，包括时间戳到EAV密钥中。
+---------+ +-----+ +-------------+
| Sensors | -- 1:M --< | EAV | >-- M:1 -- | Value kinds |
+---------+ +-----+ +-------------+
A summary of all metrics for a given time bucket needs to be obtained via a query and it likely to be the most common querying scenario
如果查询不需要连接但需要按时间分组，timestamp 列上的聚集索引可确保性能。
但是，任何带有连接的查询（即比较不同传感器的值）都有降低性能的风险。解决方案可以是单独的 OLAP 存储，用于收集的 EAV 数据。
从开发者的角度，我更推荐第三种方案。在第三个选项中，您可以考虑在 MetricType（即 typeId）和 timestamp 列上建立索引，这将极大地优化查询性能。
而您的第一个 table 需要系统停机时间，因为当需要插入新列时，您需要先关闭您的实时系统以添加该列，使用一些默认值或空值进行初始化，然后让系统恢复正常。在我看来，从它被添加到系统中开始，它将包含前几行不必要的数据（垃圾）。数据库 table 的大小将非常大，并且可能包含大量垃圾数据，从而影响查询时间。
第二个想法比第一个想法有所改进，但是，尽管有垃圾数据，这将需要连接多个 tables，这将随着时间的推移提高查询性能。您不能像第三个选项那样在多个 table 上建立索引。
所以我觉得第三个方案是最有效的。 table 被规范化，有效的索引将提供高效的查询结果。
我想提出另一件事。您也可以考虑使用单独的 table 来包含聚合数据。例如，如果您的系统需要聚合数据，您可以考虑将非规范化样式的数据放在单独的 table 中，其中可以存储特定时间线的聚合值，以便您可以从原始 table 中删除数据=24=] 已被处理。我指的是您可能考虑查看的 OLAP 数据库。
我不推荐 ERD 设计，无论何时添加传感器都需要进行更改（只要您知道自己会这样做）。这就是为什么我认为您应该消除选项 1。每当您更改 table 时，您将获得大量空值和代码中可能有的不必要的工作。
这同样适用于选项 2，可能除了空值，但无论何时向系统添加新数据源，您仍然会进行不必要的工作。
选项 3 看起来很适合我，因为它可以扩展数据源并保持数据干净整洁。
1 个提案
"宽table"
存在严重的规范化错误（而且，如果认真对待，它会存在大量空值和完整性问题）。无法使用，无需进一步评论。
"窄table"
没有错误，但规范化尚未完成。
"已输入 table"
这有点完整，是您的三个场景中的“最佳”场景。但它通过狭隘的视角来看待问题，并且完全脱离问题存在的背景。因此，由于您查询的原因以外的原因，它是错误的。
2个问题
第一个问题是你在比较三个不合理可比、不合理相等的东西。
第二个问题，EAV是当月的味道，吸引了很多人。但是，它存在重大问题，如果要实现具有一定数据完整性，则需要一组额外的“元数据”table。关键是，不需要EAV。
3 解
The types of metrics that are collected will expand over time - the system is open and additional inputs will be supported over time (e.g. today we collect temp, humidity and cpu, tomorrow a sensor maybe added that monitors co2 and RAM).
这实际上是一个straight-forward关系型数据库问题，通过完美普通的Relational设计解决，提供了充分的Relation Power；关系完整性；和速度（其他设计不会有）。
3.1 警告
但是有一些注意事项，因为作为“关系”销售的并不是关系。
去掉
Record ID字段，它们是anti-Relational.Record IDs将您的架构缩减为 1970 年代风格的记录归档系统（为方便起见，位于 SQL 容器中）。Record IDs不提供 关系模型 所要求的行唯一性。- 此外，每个文件需要一个附加字段和一个附加索引。
在对数据库建模时（关系或非关系），将数据视为数据，除了数据之外别无其他。不要根据您需要的 GUI 或某些查询或其他方式查看数据。
在此（建模）阶段关注性能问题是错误的。先把它弄好。第二，要快。不要颠倒规定的顺序。
关系键提供意义，以及关系完整性（这是逻辑的，与引用完整性不同，后者是 SQL 的物理设施）。这解决的是对象存在的上下文。
- A
Sensor不是孤立存在的（除非它在商店货架上的包裹中......但即便如此，它也存在于商店库存的上下文中） - 活动的
Sensor仅 存在于其所在对象的上下文中。您尚未提供任何相关信息。让我们把这个东西Article称为通用标签。 - 此外，
Article要求限制传感器测量的指标（用于 out-of-range 警报等），而不是传感器本身。 （传感器可能有一个范围，这是另一回事。） - 同样，
Sensor存在于Location中，这是第二个向量。否则，Article存在于Location中，Article Key携带Location。我模拟了后者。
- A
3.2 数据模型
解决方法如下： Sensor Data Model
内联图形可能不会在某些浏览器中显示。在那种情况下，这里是 PDF.
满足OLTP和OLAP(Dimension-Fact)需求
- 如果您提供更多的背景信息，我们可以精确地建模。这可能需要一点 to-and-fro.
仅限于提供的信息。
- 我把
MetricType和SensorType当成了同义词 Article显示为依赖于（存在于）Location，或者它们可以是单独的向量。无论如何，Article和Location一起符合条件Sensor。- 因为
SensorSerialNo是唯一的（AK2），所以Reading(SensorSerialNo, DateTime)也是唯一的。不需要索引。但是，如果仅通过SensorSerialNo对Reading有很多查询，这样的索引将提高性能。
- 我把
欢迎提问，我会一一解答
IDEF1X新手请参考IDEF1X Introduction.
熟悉IDEF1X，只想要一个brush-up的朋友，参考IDEF1X Anatomy.
4 性能
您对性能的关注不错，但在现阶段应用还为时过早。首先获得正确的数据模型，其次快速获得数据结构。原因有很多，其中最重要的是，当数据被规范化时，关系结构已经非常快了。此外，永远不要针对特定查询进行优化（如果需要，可以在第二阶段添加索引）。
不过，我会回应您提出的问题。
- 例如。规定的
ReadingPK 上的 ClusteredIndex 将：- 服务大多数查询，大多数维度（使用
SensorSerialNo单独 的查询除外，在这种情况下我建议使用额外的索引） - 服务所有 OLTP 事务并确保最高并发性，因为
Sensors分布在现实世界中：跨越Locations和文章。
- 服务大多数查询，大多数维度（使用
- 而
Record ID上的索引保证了每个INSERT上的热点。非常适合制造死锁。
4.1 基准
我确实有大约一百个这样的数据结构基准，这些基准是在过去四十年中为 OLTP 和 OLAP 使用收集的。我的大多数客户都是银行（想一想：传感器读数非常像在一天内变化的股票价格；几个向量（维度）；数十亿行）。银行对保密性非常严格，所以我不能按原样发布基准测试，并且编辑它们需要时间和精力。
我确实有一个非常相似的要求的基准，即 public。事实上，它已包含在针对固定 DDL（时间序列数据）和总体的 Sybase ASE 与 Oracle 10.2 基准测试的 Answer to a SO Question re Time Series data, but the seeker got the moderators to excise it (it is embarrassing to Oracle). Here is the Benchmark Summary 中。
最后，所需的结构和代码非常简单，您可以运行自己的基准测试。
5 对其他答案的回应
Re Neville 的评论：
However, if you also have to answer questions like "on what day was CPU above 30% while humidity was below 56% for more than 3 hours", your EAV model becomes really hard to work with. Those queries would rapidly become really hard to write and understand - every criterium becomes at least 1 self-join.
注意到他的评论与 EAV 有关，但这可能意味着它同样适用于主题 table（普通关系数据库 table (non-EAV) Reading) 在这种情况下，因为它涉及查询类型（而不是 EAV 概念与关系概念）：
该声明不适用于关系 tables（它很可能适用于 EAV；由于记录 ID 而引入的大量问题；等等）
只要你有
- 真正的关系数据库模式（如我所建议的），以及
- 一个真正的SQL平台（不是假冒的“sql”，它不符合规定但冒用了名称），并且
- 你了解
IN和NOT IN，以及如何比较集在SQL
...这样的查询是straight-forward代码。
6 条评论回复
记录 ID 为 Anti-Relational
Do you have any links on the record_id being anti-relational, I don't disbelieve you for a second but I'm interested to learn more about why this anti-pattern is so prevalent.
在 anti-science 的混乱中，学术界制造并设计出各种 关系模型 中不存在的“问题解决方案”，然后关于 non-problem 的哪个更正更好或更差，你有第二层无休止的“辩论”。
您不需要链接，因为没有什么可“辩论”的，而且您可能碰巧读到的任何“辩论”都忽略了上述要点。
唯一的权威是伟大的 E F Codd 博士。所有声称与关系模型有关的书籍和教科书的作者，除了 Codd，实际上都是假的，他们是关于实施 1970 年代风格的记录归档系统，并且 anti-Relational（没有关系权力；没有关系完整性；没有关系速度）。他们犯了一个错误，从 1970 年开始，他们试图将 RM 融入他们 1970 年代的 RFS 思维模式，而不是发布它并采用 RM 思维模式。在过去的五年里，他们一直在强化这一点，甚至用“数学定义”来证明这一点； 17“关系代数”； 42种异常的“正常形式”。全部完全anti-Relational。他们互相引用，所以他们发表了。
第二个问题是，像SO这样的网站是建立在民粹主义基础上的。流行的答案不是最好或正确的答案。为此，你需要一个权威（这对民粹主义者来说非常可怕）和 objective，绝对真理。 （人们喜欢他们的相对或主观的“真理”，它们一直在变化）。
因此，你只需要单一的、权威的定义，原始论文，Relational model。
- 是的，这些术语是 out-dated，现在还不是很了解。
- 是的，它是开创性的（字字珠玑，意义深远）。
- 不，您不需要阅读第 2 部分（数学）。
你需要从中收集信息，即：
关系键是“由数据组成”（我的解释是，对于几个条目，它们是 RM 中的层），它是合乎逻辑
代理人 (a) 不仅违反该定义，(b) 他们pre-Relational 范例，即 Physical 指针，RM 所取代的东西，并且 (c) 明确禁止。
非常重要，你不仅要了解Relational Key的定义，还要了解whys和wherefores。
- 例如。它超越了 import/export 系统存在的 pointer-based 问题。
- 例如。时间定义（开创性的；8 个字母；可怕的）。
因此，没有争论，没有“争论”。
- 任何反对的人都是 anti-Relational。不是因为我这么说，而是因为它与事实证明和单一权威相矛盾。
- 我已经指出了正确使用 RM 的明确技术优势（关系能力；关系完整性；关系速度），但是扩展它需要大量的努力
- 不遵守 RM 的后果是，您将获得 (a) none 的好处，并且 (b) 您会遇到 pre-Relational 记录归档系统存在的全部问题1970 年，以及 (c) 从未奏效的“学术界”提供的人为“解决方案”。
如果你需要扩展RM的那些好处，当然你需要一定程度的了解，因为每一个都很深很重要，我能提供的最好的是这个。正如您所想象的，这是一场我必须为与该主题相关的每个答案而战的战斗，因此多年来，我 post 编辑了很多答案。
- 转到我的个人资料，select 所有答案，然后阅读与此主题相关的任何内容。
为什么这个记录 ID anti-pattern 如此流行？
简短的回答是，人们热爱他们的无知，他们的主观“真理”，并且会竭尽全力保护它。他们很快接受并重复任何保持不变的理由。从他们所知道的东西中学习范式转变的东西是非常可怕的，因为它威胁到他们的舒适 table 无知，并暴露它的真实面目。他们将不得不承认，他们已经写了五个十年的东西是错误的。这就是民粹主义蓬勃发展的原因。无知中。
稍微长一点的答案是这样的。只要看看互联网。在过去，对于任何特定主题，我们都有一个来源，一个绝对权威：例如。购买大英百科全书；整个童年都在吞噬它。永恒的真理。诚实的历史。但是现在任何人只要有一个键盘和两个手指加上一些结缔组织（不需要大脑）就可以 post。作为即时的“权威”。网络是 chock-full 的 (a) 肤浅的答案（anti-thesis 的“现在这就是答案”）(b) 由于民粹主义 (d) 而受到支持的多种口味 (c)离正确或完整的答案还很远。大众可以很容易理解的声音片段。很少有人想要完整答案的深度。
即使建立了某种权威（例如维基百科；Stack Overflow），它也很容易被颠覆，因为实际上有数百万人更改条目（因此，只要某些东西不变，真理就不会改变正在改变，这不是事实）。主要是为他们的政治立场服务；他们的意识形态；他们的 re-writes 历史让过去变得错误（不是，它已经发生了），而现在的疯狂“很好”。
最终的答案是：学术羡慕。 Codd 的 关系模型 花了整整十年的时间才被理解和接受。即便如此，也只有少数人。 IBM 和 Britton-Lee（成为 Sybase）在精神和语言上实现了 Codd 的 RM。 （Digital Equipment Corp 也这样做，但他们已经不复存在了。）那些看似与 Codd 合作的学者实际上是在反对他（根据证据）。他们讨厌这样的事实，因为他们不是自己想出来的，一个人想出了第一个真正的模型，有声音；合乎逻辑的；数学，基础，完成关系代数。全部集成。当天的所有要求（例如材料清单问题）都得到了答复。这经受住了时间的考验：五年来没有添加或更改任何内容。
通常他们会声明，“但 Codd 没有定义这个或那个，所以我在这里定义它......”。所以他们想出了自己的 RA。现在他们有 17 个，都无关紧要。和异常的“正常形式”将他们的记录归档系统的碎片部分提升为看起来“相关”。现在他们有 42 个，都无关紧要。还有很多书，号称是“关系”，但事实证明，anti-Relational。每个“学术”都试图加强他们的“学术”地位，以对抗所有其他人。
这就是为什么我再次说，去找唯一的作者泰。不要阅读 anti-Relational 人群中的内容，因为它会削弱您对 RM 的理解（最好的情况），或者毒害您的思想（最坏的情况）。
一个澄清
如果您检查关系 PK（例如）Location.Location，它可能看起来很奇怪。这是用户实际使用的 %Code 或 %ShortName 数据。通常为 4 到 6 个字符，最多 12 个。与必须存在的长 Name 不同，它是备用键。当然，它绝对不是任何类型的数字（这不是数据，不是用户使用的东西）。用户也喜欢他们的简短形式。显然，如果存在国际标准，请使用任何国际标准。
Key必须是stable（不是静态的，宇宙中没有什么是静态的），在现实世界中用来唯一标识对象（数据行）的。
例如。对于
Security，这是一家在证券交易所上市的公司，在美国是TickerSymbol，在澳大利亚是ASXCode。 ISO 代码，一个ISINCode，是一个 AlternateKey。对于城市，使用其中一种地理位置标准：ISO； FIPS；等等（我使用 Statoids 因为它早于其他人存在，但那些日子已经屈指可数了）。在最坏的情况下，使用机场代码。
正版SQL平台
What do you consider to be genuine SQL? Sql Server, Postgres, MySQL, Oracle I guess all would be?
没有。我的意思是任何 实际上符合 已发布的 SQL 标准，因此可以 实际上支持 关系 table 的平台；集合的关系处理；和 ACID 交易。
- 这自动排除了 freeware/vapourware/nowhere/“开源”，其中的位由遍布整个宇宙的 10,000 名开发人员编写，没有任何管理原则。例如。没有 ACID 事务或它所需的结构，每个代码段都需要这些。现在插入太迟了，因为它需要 100% re-write，但愿...服务器架构。
商业
这意味着 paid-for 和支持，也很重要。要么您有维护合同并且支持是即时的，要么您 post 错误报告并且您每天检查未来一年或三年的更新。
服务器架构
如果需要可伸缩性或性能（高吞吐量；高并发；低延迟），那么服务器架构是最重要的。同样，这不包括免费软件和 Oracle，因为它们没有体系结构，它们是大量交互程序的集合，可以 o/s 执行架构数据库服务器通常执行的所有功能。
检查此 Comparison of Oracle vs Sybase Architecture。
- 同样适用于 PostgreSQL 和其他免费软件。 PostgreSQL（彻底失败的 Ingres 之子）因压力大而失败，大量锁定问题和非常低的并发性。
1 High-End，商业，SQL 合规
大约 5% 的市场份额，但占金融服务和自动化市场的 95%。伟大的建筑，无望的营销。
- **Sybase ASE
- IBM DB2**
2 商业，SQL 合规
- MS SQL 服务器
很容易成为最常见的。 Good Architecture（最初是从 Sybase 偷来的），然后以通常的疯狂 MS 风格“进步”。使用痛苦；大量的开销；与各种 add-ons 和 must-uses. 的集成不佳
3 商业，SQL Non-Compliant
无望的架构，伟大的营销。
甲骨文
通常，Oracle 开发人员非常擅长以使其正常工作所需的方式使用该产品，但这意味着他们已经偏离 关系模型.- 例如。在 Time Series benchmark 中，重点是，当请求子查询时，Oracle 会自行处理，因此它必须使用“内联视图”。 OP 声称它与子查询一样快（避免了它需要更多代码的事实，并且编码器必须跳出关系思维模式）。在每个测试场景中，基准被证明是非常错误的（Oracle 在
COUNT()上比 Sybase 慢 3 到 4.8 倍，26 到 36 倍 在SUM() 上较慢
- ...并且必须在 120 分钟. 后放弃子查询（Sybase 2.1 秒）
- 例如。 Oracle 是 non-compliant re ACID Transactions，开发人员在一定程度上解决了这个障碍，但 Phantom Updates 和 Lost Updates（技术术语）根本无法避免。如果 work-arounds 没有正确写入，整行（
UPDATES或INSERTS都会丢失）。 - 所有适用于以下...
- 例如。在 Time Series benchmark 中，重点是，当请求子查询时，Oracle 会自行处理，因此它必须使用“内联视图”。 OP 声称它与子查询一样快（避免了它需要更多代码的事实，并且编码器必须跳出关系思维模式）。在每个测试场景中，基准被证明是非常错误的（Oracle 在
4 Non-Commercial, SQL Non-Compliant
这些人花了大量时间开发 n 个“功能”关系数据库不需要，但对 anti-Relational 记录 ID 归档系统非常有吸引力。
- 例如。 “延迟约束检查”；
ENUMs;等等 - 他们缺乏 SQL 合规的基础知识。例如。没有真正的 ACID 交易。
此外，如上所述，零架构。这导致系统在 single-use 下表现出色，并在并发或可伸缩性的任何压力下惨败。
由于他们 non-compliance 与 SQL 的要求，他们煞费苦心地 post 在命令手册的每一页上都写了一个合规通知。 （只需要手册前面的一个合规声明即可。）当然，缺少的命令只是缺少，所以哎呀，他们没有合规声明。
PostgreSQL
自 Ingres 时代以来我不得不检查的最糟糕的软件。深受“学术”人群的喜爱，只因它是一位“学术”同胞的潦草涂鸦。
5 user max，或者处理并发问题（粗略看一下SO上报的问题）。MySQL
高于 PostgreSQL，但仍属于此类。- InnoDB 引擎在性能方面明显更好，但远不及 Sybase/DB2 水平（仍然不是真正的服务器架构）。 SQL non-compliance部门没有喘息的机会。
5 摘要
一分钱一分货。
- 服务器架构，最明显的是在每个场景中的性能。
- SQL 合规性，经过深思熟虑，并在每个适用的代码段中实施。
- 最后但同样重要的是，支持。
无论您选择什么，请记住，当您将其移植到另一个平台时，您的 SQL 代码将需要一个完整的 check-and-change，因为 SQL（或 NON-sql) 非常不同。对于 Non-Commercial 程序套件，这意味着完全重写。因此慎重选择，着眼于长期实施。
TimescaleDB 的文档讨论了宽数据模型与窄数据模型：
https://docs.timescale.com/timescaledb/latest/overview/data-model-flexibility/
总结：
- “如果您独立收集每个指标，那么窄模型是有意义的。它允许您通过添加新标签来添加新指标，而无需正式更改架构。”
- “如果您通常一起查询多个指标，以宽 table 格式存储它们会更快、更容易”