对 SQL Server 中的数据进行版本控制，以便用户可以对数据进行一定的剪切
我有一个要求，在 SQL Server 支持的网站（本质上是一个大型 CRUD 应用程序）中，用户应该能够“回到过去”并能够导出给定时间点的数据。
我的问题是解决这个问题的最佳策略是什么？是否有一种系统的方法可供我采用并将其应用于所有桌子？
I have a requirement that in a SQL Server backed website which is essentially a large CRUD application, the user should be able to 'go back in time' and be able to export the data as it was at a given point in time.
My question is what is the best strategy for this problem? Is there a systematic approach I can take and apply it across all tables?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
根据您的具体需求，这可能相对容易，也可能很困难。
简单：为每个表创建一个历史表，在更新前或插入/更新后复制数据（即也有新内容）。切勿从原始表中删除，进行逻辑删除。
Hard：有一个 fdb 版本对每次更改进行计数，每个数据项都与开始和结束相关。这需要非常奇特的主键修改。
Depending on what exactly you need, this can be relatively easy or hell.
Easy: Make a history table for every table, copy data there pre update or post insert/update (i.e. new stuff is there too). Never delete from the original table, make logical deletes.
Hard: There is an fdb version counting up on every change, every data item is correlated to start and end. This requires very fancy primary key mangling.
只需对之前的答案添加一点评论即可。如果您需要返回所有用户，可以使用快照。
Just add a little comment to previous answers. If you need to go back for all users you can use snapshots.
最简单的解决方案是在每行发生更改时保存其副本。使用触发器可以最轻松地完成此操作。然后，您的 UI 必须提供搜索功能以返回并查找数据。
这确实会产生数据爆炸，当表频繁更新时，情况会变得更糟，因此下一步通常是对旧数据进行某种基于数据的清除。
The simplest solution is to save a copy of each row whenever it changes. This can be done most easily with a trigger. Then your UI must provide search abilities to go back and find the data.
This does produce an explosion of data, which gets worse when tables are updated frequently, so the next step is usually some kind of data-based purge of older data.
您可以查看的实现是 Team Foundation Server。它能够执行历史查询（使用 WIQL 关键字 ASOF）。后端是 SQL Server，因此那里可能有一些线索。
An implementation you could look at is Team Foundation Server. It has the ability to perform historical queries (using the WIQL keyword ASOF). The backend is SQL Server, so there might be some clues there.