我在为具有版本控制的动态属性设计架构时遇到了一些问题。假设以下用例:
我有一个名为的表Actor
,其中包含id
和 a name
(为简单起见)。我的情况的上限是,该表包含大约 100 万个条目。
此外,每个演员都会获得分配给他们的属性。因为当时不知道属性,所以需要一张表来管理属性。我想到了一个Property
-table。生成的 n:m 关系将通过一个包含主键和属性值(类型?)之间的表来Actor
解决Property
。
目前,这似乎很容易处理。如果有一百万个条目,每个条目有 10 个属性,则该ActorProperty
表将有一千万个节点。我相信使用btree
索引 (log2(n)) 这应该没问题。
现在是我正在努力的部分。应该以某种方式跟踪属性。随着时间的推移,这些属性会发生变化,但历史不应丢失。很可能会使用时间戳来完成。请注意,多个属性会同时更新。一个例子是:我每天拍摄所有演员的快照,如果发生变化,我将同时更新所有更改的属性。这导致每年有 365 个时间戳。
如果我使用另一个表来管理版本(时间戳)并向ActorProperty
表中添加另一个外键,我将获得 365 * 1000 万个条目。这应该是我能得到的最大值。大多数情况下,数据集会明显变小。
我现在的问题是更多地解决性能问题。我阅读了以下有关索引的答案:数据库索引如何工作。查询具有这么多条目的表不是很慢吗?一个示例查询是:前 100 个演员,其所有属性都在给定的时间戳 id=x 处。我也觉得我正在考虑的模式可能不是最好的。是否有人对具有更高可扩展性的模式有任何建议或想法?
顺便说一句,我目前也在评估 NoSql 方法,所以我想暂时专注于关系方法。我的目标是收集不同技术的优缺点,然后为所描述的用例建立一个理论架构或模型。在关系数据库上使用最佳模型的性能似乎很难评估或发现。
谢谢!