SQL Server 中的完整数据库版本控制答案

【问题标题】：Full Database Versioning in SQL ServerSQL Server 中的完整数据库版本控制
【发布时间】：2012-08-15 20:15:47
【问题描述】：

首先，让我指出，我阅读了所有关于数据库版本控制的帖子，但这并不是我想要的，但我想不出一个更好的标题（“完整”这个词这是关键）。

我有一个“编译数据库”，其中包含公共交通路线规划器的所有类型的优化记录和统计数据，它是通过另一个数据库中的程序生成的。编译的数据库在它处于活动状态时永远不会改变，除了用户活动监控和缓存。有些表包含多达 2-300,000 条记录。

一旦输入数据库发生更改，此编译数据库将完全更新。因此，任何新的数据库版本都不会以任何方式与任何其他先前版本进行交互。但我想单独存储每个版本，如果用户愿意，我有机会从程序中使用它（把它想象成公共交通地图的历史）。

唯一合理的方法是简单地为每个版本制作不同的物理数据库，这既不难也不错，但我想问你是否知道对完整数据库进行版本控制的任何机制（不仅仅是其中的部分数据，比如其他帖子正在询问），目的是使整个事情更加合乎逻辑和干净。

我使用的是 SQL Server 2012，但在服务器上可能是 2008 R2。

如果您考虑将版本化数据存储在同一个数据库中（并在每个表中添加一个 VersionID 列）忘记它，因为在具有 2-300,000 条记录的表上，10 个版本（将在更少的时间内累积超过 3 个月）意味着超过 300 万条记录，其中只有 300,000 条会被使用，所以，没办法！

【问题讨论】：

VersionID 列无论如何都不好，因为可能较新的版本可能具有不同的架构。我可能会像您最初的预感那样使用单独的数据库。
同意关于架构更改的评论。但是为什么你认为有一个版本列（因为大小）是一个问题？
只是为了逆向，如果数据的不同“版本”之间的模式相同，为什么不将它们都放在同一个数据库中呢？您可以使用表分区。哎呀......即使它们有不同的模式，它们也可能都在同一个数据库中，只是使用不同的表名，如果这会激起你的辣椒。您的反对单一数据库模型的原因是什么？
@BenThul 实际上，架构是相同的，它永远不会改变。将它们存储在同一个数据库中的问题在于，在性能方面这将是一场彻底的灾难，因为在 95% 的情况下只使用一个版本，但数据本身只是，假设我有 10 个版本，则为 10% .因此，在 95% 的情况下，90% 的查询是无用的。而且我不认为分区的目的是为了版本控制，优化查询（分区消除等）会一团糟
@Tiby：IMO，这正是分区的用途。随时间变化的数据，您只有其中的一部分在任何给定时间都在积极使用。至于分区消除是一团糟，如果您在您的 VersionID（或您所称的任何名称）上进行分区并在您的数据查询中使用它，服务器会为您进行消除。

【解决方案1】：

我认为多数据库方法很好。您可以尝试进行存储级重复数据删除。这可能会大大减少存储使用量。只需确保创建新数据库作为备份并从旧数据库恢复，以使它们大部分字节相同。

【讨论】：

重复数据删除是一种减少已用空间的解决方案，但我认为目前这不是一个真正的问题，因为即使我有超过 100,000 条记录的表，它们也主要是 tiny 和 smallints ，因此数据库不超过 50-100 mb。我主要对将数据库“链接”为单独的实体感兴趣，但共享一个通用架构。
好吧，这不可能跨数据库。您可以将多个版本保留为同一个表的单独分区。您可以引入分区键“VersionID smallint not null”。如果您始终通过 VersionID 访问，性能将与现在相同。