Question

我们有一个体面的面向对象的应用程序。每当应用程序中的对象发生更改时，对象更改都会保存回DB。然而，这已经不太理想了。

目前，交易存储为一个事务和一组transactionLI。

事务表包含who，what，when，why，foreignKey和foreignTable的字段。前四个是不言自明的。 ForeignKey和foreignTable用于确定哪个对象发生了变化。

TransactionLI具有时间戳，键，val，oldVal和transactionID。这基本上是一个key / value / oldValue存储系统。

问题是这两个表用于应用程序中的每个对象，因此它们现在是相当大的表。将它们用于任何事情都很慢。索引只有很多帮助。

所以我们正在考虑其他方法来做这样的事情。到目前为止我们考虑过的事情： - 通过类似时间戳的方式对这些表进行分片。 - 对两个表进行非规范化并将它们合并为一个。 - 上述两者的组合。 - 在更改后将每个对象序列化并将其存储在subversion中。 - 可能是其他的东西，但我现在想不到它。

整个问题是我们希望有一些机制来正确存储和搜索事务数据。是的，你可以强制进入关系数据库，但实际上，它是交易数据，应该相应地存储。

其他人在做什么？

Answer 1

我们采取了以下方法： -

所有对象都是序列化的（使用标准XMLSeriliser），但是我们使用序列化属性修饰了类，以便生成的XML要小得多（例如，将元素存储为属性并在字段名称上删除元音）。如有必要，可以通过压缩XML来进一步采取这一步骤。
通过SQL视图访问对象存储库。视图前面有许多表结构相同但表名附加GUID的表。当前一个表达到临界质量（预定行数）时会生成一个新表
我们运行一个夜间归档例程，生成新表并相应地修改视图，以便调用应用程序看不到任何差异。
最后，作为隔夜例程的一部分，我们会将不再需要的任何旧对象实例归档到磁盘（然后是磁带）。

Answer 2

我从未找到针对此类问题的最佳解决方案。您可以尝试的一些事情是，如果您的数据库支持分区（或者即使它不能实现您自己的相同概念），但按对象类型分配此日志表，然后您可以按日期/时间或由您进一步分配对象ID（如果你的ID是一个数字，这很好用，不确定guid会如何分配）。

这将有助于维护表的大小，并将所有相关事务保持为对象的单个实例。

您可以探索的一个想法是，您可以将数据存储为blob（文本或二进制），而不是将每个字段存储在名称值对表中。例如，将对象序列化为Xml并将其存储在字段中。

这样做的缺点是，当您的对象发生变化时，您必须考虑如果您使用Xml会如何影响所有历史数据，那么有更简单的方法来更新历史xml结构，如果您使用二进制文件有方法，但您必须更加努力。

我已经取得了很大的成功，存储了一个相当复杂的对象模型，它具有大量的互联作为blob（.net中的xml序列化程序没有处理对象之间的关系）。我很容易看到自己存储二进制数据。将其存储为二进制数据的一个巨大缺点是，要访问它，如果使用像MSSQL这样的现代数据库，则必须使用Xml将其从数据库中取出。

最后一种方法是拆分两个模式，你可以定义一个差异模式（我假设一次更改一个属性），例如想象存储这个xml：

<objectDiff>
<field name="firstName" newValue="Josh" oldValue="joshua"/>
<field name="lastName" newValue="Box" oldValue="boxer"/>
</objectDiff>

这将有助于减少行数，如果使用MSSQL，您可以定义XML Schema并获得围绕对象的一些丰富的查询功能。您仍然可以对表进行分区。

约什

Answer 3

根据您的特定应用程序的特征，另一种方法是将实体本身的修订保留在各自的表中，以及每个修订版的人员，内容，原因和时间。谁，什么以及什么时候仍然是外键。

虽然我会非常小心地使用这种方法，因为这仅适用于每个实体/实体类型具有相对少量更改的应用程序。

Answer 4

如果查询数据很重要，如果您有SQL Server的企业版，我会在SQL Server 2005及更高版本中使用true Partitioning。我们在当月按年分配了数百万行 - 您可以按照应用程序的要求进行细化，最多可以有1000个分区。

或者，如果您使用的是SQL 2008，则可以查看已过滤的索引。

这些解决方案使您能够保留简化的结构，同时提供查询数据所需的性能。

显然应该考虑拆分/存档较旧的更改。