经济数据库体系结构可能性w/不同长度的数据

Question

我正在设计一个MySQL数据库(InnoDB)，该数据库保存了大量的经济数据，我们的应用程序对此进行了评分。经济数据的大小差别很大:一些指标，如百分比变化，只是百分之一的分数；其他指标，如国债数字，则是14+位数。此外，我们有一个业务要求，说明一些数据点需要正确到小数点第6位。

我们目前在遗留数据库中有500,000多行，但预计在将来会有更多的行，因为我们正在构建新的数据库时考虑到点时点，而且在大多数情况下，不会删除或更新行，只会添加新行并取代旧行。

载有这一经济数据的所有潜在表格的结构如下：

id | country_id | period_id | [economic_data] | data_type | date_created | date_superseded

我的问题是：

是否最好：

1. 考虑到数据大小不同，将所有这些单独的经济数据序列划分到各自的表中，或者
2. 考虑到所有经济数据表的相同结构以及它为编写查询提供的简单性，将所有这些数据合并成一个庞大的表？

我们收集了超过200个数据系列，并计划每年增加这个数字，因此选项1将需要创建和维护200+表。

选项2似乎是最容易开发和维护的，但我想知道它对查询性能和存储可能有什么影响。

有什么想法或建议吗？

Answer 1

我会把问题分成交易和分析--基于这个问题，你似乎在试图找到一种对两者都是最优的设计。

从设计的角度--在逻辑层面上--我会使用这样的东西，而不会担心表格的数量。此外，每个属性都有适当的数据类型，等等。

由此，您可以定期(每天)发布到更易于分析的结构(平面OLAP表、数据集市.)。根据性能--以及用户期望--公开5NF视图可能足够好。

在身体层面上，我不太确定

像这样的结构通常以平面视图(5NF)和实时点函数的形式向用户公开。这里的主要问题是问题被标记为MySQL。MySQL对连接(61)中出现的表的数量有限制，而且查询优化器不支持消除表；因此，忘记视图。您必须使用应用程序级别来“运行”，并根据ID和日期连接表；应用程序可能是导出到分析表的ETL代码。

因此，现在取决于如何向最终用户公开这一点--如果他们应该编写自定义查询，这将无法工作。

在逻辑级别上设计DB而不考虑目标DB是一种常见的方法，但在这种情况下，DB的选择限制了设计选项。