我想将分层的二维科学数据集存储在关系数据库（MySQL 或 SQLite）中。每个数据集都包含一个具有任意列数的数值数据表。此外，每个数据集可以有一个或多个与其表的给定行关联的相同类型的子级。每个数据集通常有 1 到 100 列和 1 到 1.000.000 行。数据库应该能够处理许多数据集（>1000）并且数据的读取/写入应该相当快。
存储此类数据的最佳数据库架构是什么？是否有一个“主”表，其中包含各个数据集的名称、ID 和关系，并且每个数据集有一个包含数值的表？
【问题讨论】：
是否有一个“主”表，其中包含各个数据集的名称、ID 和关系以及每个数据集一个包含数值的表？
我就是这样做的。
我不确定“任意列”是如何工作的，因为数据通常不会那样工作。无论如何，听起来像将它存储为 row,col,val 可能会很好地工作。
老实说，如果您不需要搜索它（最大值、最小值等），最好使用某种平面文件。
另一种可能有趣的设置是使用 SQLite，每个数据集都有一个单独的数据库文件，外加一个主文件。
无论您选择什么，它的效果如何实际上取决于您将如何处理数据。
【讨论】：
我认为，您最终会牺牲灵活性来换取性能。 您可以对您的数据库架构进行硬编码，这听起来像是您想要避免的，但会为您提供最佳性能，或者
保留在运行时确定的架构，存储在“主”表中，这会增加您的灵活性，但会降低您强制执行参照完整性和设置数据类型的能力。
有一段时间，您可以尝试这两种方法，直到您有足够的信息确定哪种方法更适合您的任务。
【讨论】：
如果不了解问题域，很难具体化，但如果您的数据本质上是关系型的，请使用关系模型。如果您的数据本质上不是相关的，我不会为了它而尝试将其强制转换为关系模型 - 所有数据集碰巧都有一个 ID 的事实并不意味着这些 ID 是相同的。甚至它们适合用作主键。
我建议首先将每个数据集放在自己的表中（如果有子记录，则为表），并在需要时创建一个主表。
我会分享 zebediah49 的问题：“你真的要为此使用数据库吗？平面文件不是更好吗？”
【讨论】：
我们将大量这样的数据存储在他们自己的平面文件中。文件的标题包含足够的信息（时间戳、行数/列数...等），以便可以读取它。然后有关此数据的元信息在数据库中。至少这是文件位置，但可能包含有关数据的其他信息。例如，我们将数据聚合到代理变量中，这些代理变量在高层次上总结了细节。通常，此摘要数据就足够了，但必要时我们可以阅读该文件以了解所有详细信息。
【讨论】：