我将每周跟踪大约3000万个实体的几个变化的属性。被跟踪属性的值都是整数。
我无法决定如何以最佳方式储存它们。如果我创建第二个一对多表，在其中为每个属性输入一行，当观察到它时，我将创建3000万个实体*52周*每年的属性条目数。这个表会变得很大，但我可以查询特定时期，比较不同时期。。
另一方面，我可以将每周的数据点放在整数数组中，甚至字符串化的对象中，其中所有属性都是键，跟踪的整数是值，并为我的3000万个跟踪项中的每一个指定一行不断修改。现在我无法直接在DB中进行复杂的查询和比较，但我仍然可以提取特定项目的数据并显示它。我还不知道我想做的每一个比较，但至少我想我希望能够检查最大的赢家或输家。
我应该接受其中一种选择吗？我应该选择一个完全不同的数据库结构吗？为什么？我目前正在使用MariaDB。如果我的例子过于做作，那么将存储股市数据想象成最接近的类比，其中每个时间点(tick(都必须存储特定股票的几个属性。
SQL是用来处理具有固定长度列(如(的非常庞大的简单时间序列表的
id entity_id property_id datestamp value
BIGINT INT INT DATETIME appropriate type
每当系统中出现属性更改时，只需在该表中插入一行即可。
通过适当的索引，MySQL或任何其他RDBMS都可以处理千兆行的此类数据，而不会遇到太多麻烦。驱动器空间非常便宜，服务器的容量需要与访问它的程序数量相匹配，而不是与它所包含的历史数据量相匹配。因此，不要排除SQL。你的申请正处于最佳状态。
而且，使用SQL处理这些简单的行将比您建议的大对象读-修改-写方案效率高得多。该软件的编写、测试、故障排除和审计将简单得多。如果你投入生产，你需要轻松地完成所有这些事情。当你处理别人的钱时，它们很重要。
而且，MariaDb的最新版本具有值得研究的表的系统版本控制功能。