我有不同类型的测量。它们彼此不相关。假设A,B和C。它们三个都具有相同的结构，ID (integer), value (float), experiment_id (integer)（与实验表相关）。
我不知道存储此信息的最佳方式。
A) 使用三个表（A、B和C）会更好吗？
B）或者最好将它们全部存储在一个名为的表中measurements，并添加一个名为的附加列measurement_type来存储A、B或C（包括索引）的信息。
在我的应用程序中，我想要三个模型，分别称为A、B和C。
解决方案应该很快，因为对于每种测量类型，一天可能有数亿甚至数十亿的条目。此外，有一天可能会有测量类型D, E, ..., Z。
顺便说一句，我使用的是 Oracle Enterprise 数据库。
根据您的评论，并假设您关注的是查询性能（而不是 INSERT 性能），看起来您需要一个类似于以下的模型：
ORGANIZATION INDEX在表上使用MEASUREMENT（也可以考虑 usingCOMPRESS子句，因为会有很多行共享相同的前导EXPERIMENT_ID）。
索引I1包括：{FEATURE_ID, EXPERIMENT_ID, MEASUREMENT_TYPE, VALUE}，按此顺序。考虑使用COMPRESS子句，因为会有许多行共享相同的前导FEATURE_ID)。
这给了我们2个B树：
PK，即索引组织表本身。I1。可以通过B 树EXPERIMENT_ID中的单个索引范围扫描和没有表堆访问（堆不存在）来满足查询。B-Tree 自然地将属于同一实验的行存储在物理上靠得很近，因此 I/O 最小化。PKPK
单个范围扫描（在B 树中）FEATURE_ID也可以满足查询。I1这I1是一个覆盖索引，因此不需要对PKB-Tree 进行双重查找。B-Tree 自然地将I1属于同一特征的行存储在物理上靠近在一起，因此 I/O 被最小化。
我会回避在 上对MEASUREMENT表进行水平分区MEASUREMENT_TYPE，除非您对具有代表性的数据量进行了测量并得出结论，它提供了更适合您需求的性能折衷。
由于测量类型可以增长并且不限于 A、B 和 C，因此建议使用选项 B)，因为它在需要时支持其他测量类型。