Sql server SQL Server中的完整数据库版本控制

首先，让我指出，我阅读了所有关于数据库版本控制的文章，但这并不是我想要的，但我找不到更好的标题（这里的“full”一词是关键）

我有一个“编译数据库”，它保存了公共交通路线规划人员的各种优化记录和统计数据，它是通过另一个数据库中的程序生成的。除了用户活动监视和缓存之外，已编译的数据库在活动时从不更改。有些表包含多达2-300000条记录

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

唯一合理的方法就是为每个版本创建不同的物理数据库，这既不难也不错，但我想问的是，您是否知道任何机制来对完整数据库进行版本控制（而不仅仅是其中的部分数据，就像其他帖子所要求的那样），以便使整个过程更具逻辑性和干净性

我使用的是SQLServer2012，但在服务器上可能是2008R2

---

如果您想在同一个数据库中存储版本化数据（并在每个表中添加一个VersionID列），请忘记它，因为在一个有2-300000条记录的表上，10个版本（在不到3个月的时间内累积）将意味着超过300万条记录，其中仅使用300000条记录，因此，不可能

我认为多数据库方法很好。您可以尝试执行存储级重复数据消除。这可能会大大减少存储使用量。只需确保创建新数据库作为旧数据库的备份和还原，以便它们基本上是字节相同的。

版本ID列无论如何都不好，因为新版本可能具有不同的架构。我可能会像你最初的预感一样使用单独的数据库。同意关于模式更改的评论。但是为什么您认为拥有一个版本列（因为大小）是一个问题呢？相反，如果数据的不同“版本”之间的模式相同，为什么不将它们都放在同一个数据库中呢？您可以使用表分区。真见鬼。。。即使它们有不同的模式，它们也可能都在同一个数据库中，只是使用不同的表名，如果这会让您感到不安的话。你对一个数据库模型有什么异议？@BenThul的确，模式是相同的，它从不改变。将它们存储在同一个数据库中的问题是，从性能角度看，这将是一场彻底的灾难，因为95%的情况下只使用了一个版本，但数据本身仅为10%，如果我有10个版本的话。因此，在95%的案例中，90%的人被毫无用处地查询。而且我不认为分区的目的是为了版本控制，优化查询（分区消除等等）将是一个混乱的局面@Tiby:IMO，这正是分区的目的。随着时间的推移而变化的数据，在任何给定的时间内，只有一部分数据正在被积极使用。至于分区消除是一个混乱的问题，如果您在VersionID（或任何您称之为VersionID）上进行分区并在数据查询中使用该分区，服务器会为您进行消除。重复数据消除是一种减少已用空间的解决方案，但我认为目前这不是一个真正的问题，因为即使我有超过100000条记录的表，它们主要是微小的整数，所以一个数据库不会超过50-100MB。我主要感兴趣的是将数据库作为单独的实体进行“链接”，但共享一个公共模式。好吧，这是不可能跨数据库的。可以将多个版本作为同一个表的单独分区。您可以引入一个分区键“VersionID smallint not null”。如果总是通过VersionID访问，则性能将与现在相同。