20 个解决方案
#1
你不应该用快照来存变更吧？不然快照一大堆。
#2
只要做好日志备份，你的想法就可以实现了，没必要搞快照，一个OLTP系统一天可能有过万操作，每个操作难道你也搞快照？要不是你的是2005，还有新方法给你，但是这只能在2008用：
http://blog.csdn.net/dba_huangzj/article/details/8130448
http://blog.csdn.net/dba_huangzj/article/details/8130448
#3
我先看看，谢啦。。。。
#4
#5
快照只用来记录变更前数据，然后和变更后数据 做一下对比，把变更的数据记录到新表里。。。
#6
难道你的变更不是连续的？而是一条就那么固定时间的几次？如果是这样，倒可以，否则，你的快照文件会非常多。
#7
不是固定时间，只要用户在系统里有增删改的操作 需要把用户的操作记录下来，同时还记录 变更数据，供日后恢复数据使用（误操作），而且还要求方法很通用的，要在不同 产品里调用
#8
不一定局限于数据库快照 ，我的几种方案都会有各自的短板（要么不够通用，调用起来较复杂【逻辑在呗调用方法里】；要么存储过程里逻辑过于复杂，实现难度较大【】），没有较好的方案啊!
#9
对这种操作除了备份之外，其他都比较耗资源，如果能用2008的cdc那就好解决多了，如果不能，那对核心表做触发器可能比较常用。但是更好的是考虑，如何避免“误操作”
#10
触发器不能记录用户信息 。。。。被否决了 。。。
#11
快照不也不行吗？快照只是一个库的某一个状态而已咯
#12
第二种方案:
添加前 创建一个数据库快照，添加完后，再调用一个方法（传入userId,公司ID，操作的表名，模块名，操作表的主键【如果有多张表，可能对应多个】。。。），方法对应的存储过程里，对变更前数据（存储在快照里）和变更后数据（通过传入的表主键查询获取）进行对比，把变更数据存入到opeLog表里，然后再删除 快照。。。。
#13
一般的使用是不需要整个库保留的，只要对“核心”、“关键”部分的数据做保留，比如在一个ERP系统里面，员工的入职离职这个没多大记录的必要性，而出入库单据的操作，业界也知道会很频繁，况且开错了就补录等等即可，没什么大不了，但是对财务数据，就要有足够高的重视，所以如果对一个erp系统，那么监控财务类型或者其他关键部分的数据做保留，这样就足够了，随着库越来越大，使用的人越来越多，一天一两次快照就够了。而你想把操作都加快照的话，那是不允许的。做好备份，且把业务流程控制好就够了。如果非要做，那建议升级到2008，然后使用cdc功能。
#14
谢谢斑竹。。。。
我先创建快照，用完了就立即删除，这样有问题么？
快照是数据库级别的，如果我想把快照里某张表的数据（操作前的【比如：删除部门操作】） 和 操作后的数据 进行一个比较，把前后相关数据 保存起来，该如何做？
#15
不是不可以，但是现在我们假设你的库已经到了10G，那创建和删除，估计最快也要好几秒。在这几秒内发生的事情可能又要创建快照等等，你应该想像得到。再者一个正式库，一般都有2位数甚至3、4位数的人在连接，那么万一极端情况下1000个人同时做一个需要创建快照来保存的操作，就是要同时创建1000个快照，这个后果你懂得。也是我一直不同意你用快照的最主要原因。
第二个问题，快照其实你就当一个库咯，可以用except来找出不同的数据。
第二个问题，快照其实你就当一个库咯，可以用except来找出不同的数据。
#16
老大坚持说要用这玩意，我提出的方案被否决了[通过程序控制，不用快照]
我的方案：
先说一下我的思路:在增删改对应的方法里，把变更的数据用对应的数据实体存起来，然后序列化存入到OpeLog表的recordData字段里(xml结构)，operLog表还有其他一些字段 如：
SQL code
?
1234567
logid 主键userId 操作人IDopeTableName 操作对应的表明recordData 变更数据 (xml)opeMsg 操作信息 nvarchar(max)opeType 操作类型（delete,update,add。。。）。。。。
但这样在方法里调用的话，需要组装数据，不够通用，工作量较大。。。
#17
的确这是工作中的不幸，上级往往以为自己比较牛逼，听不进。但是又给不出什么更好的办法或者回复。如果你的描述已经准确无误，那我想不到他有什么理由来推翻我的意见。
你的这个思路如果能支持大并发，倒没什么问题。
你的这个思路如果能支持大并发，倒没什么问题。
#18
如果要支持大并发，那就做成分布式的服务 （队列+WCF），个人想法呵。。。
#19
从应用程序上支持高并发会很痛苦...........
#20
呵呵。。。。 用户数多了，就需要考虑并发，神马缓存，分布式的就派上用场了，对程序的架构还有个人能力是个考验。。。。
#21
#1
你不应该用快照来存变更吧？不然快照一大堆。
#2
只要做好日志备份，你的想法就可以实现了，没必要搞快照，一个OLTP系统一天可能有过万操作，每个操作难道你也搞快照？要不是你的是2005，还有新方法给你，但是这只能在2008用：
http://blog.csdn.net/dba_huangzj/article/details/8130448
http://blog.csdn.net/dba_huangzj/article/details/8130448
#3
我先看看，谢啦。。。。
#4
#5
快照只用来记录变更前数据，然后和变更后数据 做一下对比，把变更的数据记录到新表里。。。
#6
难道你的变更不是连续的？而是一条就那么固定时间的几次？如果是这样，倒可以，否则，你的快照文件会非常多。
#7
不是固定时间，只要用户在系统里有增删改的操作 需要把用户的操作记录下来，同时还记录 变更数据，供日后恢复数据使用（误操作），而且还要求方法很通用的，要在不同 产品里调用
#8
不一定局限于数据库快照 ，我的几种方案都会有各自的短板（要么不够通用，调用起来较复杂【逻辑在呗调用方法里】；要么存储过程里逻辑过于复杂，实现难度较大【】），没有较好的方案啊!
#9
对这种操作除了备份之外，其他都比较耗资源，如果能用2008的cdc那就好解决多了，如果不能，那对核心表做触发器可能比较常用。但是更好的是考虑，如何避免“误操作”
#10
触发器不能记录用户信息 。。。。被否决了 。。。
#11
快照不也不行吗？快照只是一个库的某一个状态而已咯
#12
第二种方案:
添加前 创建一个数据库快照，添加完后，再调用一个方法（传入userId,公司ID，操作的表名，模块名，操作表的主键【如果有多张表，可能对应多个】。。。），方法对应的存储过程里，对变更前数据（存储在快照里）和变更后数据（通过传入的表主键查询获取）进行对比，把变更数据存入到opeLog表里，然后再删除 快照。。。。
#13
一般的使用是不需要整个库保留的，只要对“核心”、“关键”部分的数据做保留，比如在一个ERP系统里面，员工的入职离职这个没多大记录的必要性，而出入库单据的操作，业界也知道会很频繁，况且开错了就补录等等即可，没什么大不了，但是对财务数据，就要有足够高的重视，所以如果对一个erp系统，那么监控财务类型或者其他关键部分的数据做保留，这样就足够了，随着库越来越大，使用的人越来越多，一天一两次快照就够了。而你想把操作都加快照的话，那是不允许的。做好备份，且把业务流程控制好就够了。如果非要做，那建议升级到2008，然后使用cdc功能。
#14
谢谢斑竹。。。。
我先创建快照，用完了就立即删除，这样有问题么？
快照是数据库级别的，如果我想把快照里某张表的数据（操作前的【比如：删除部门操作】） 和 操作后的数据 进行一个比较，把前后相关数据 保存起来，该如何做？
#15
不是不可以，但是现在我们假设你的库已经到了10G，那创建和删除，估计最快也要好几秒。在这几秒内发生的事情可能又要创建快照等等，你应该想像得到。再者一个正式库，一般都有2位数甚至3、4位数的人在连接，那么万一极端情况下1000个人同时做一个需要创建快照来保存的操作，就是要同时创建1000个快照，这个后果你懂得。也是我一直不同意你用快照的最主要原因。
第二个问题，快照其实你就当一个库咯，可以用except来找出不同的数据。
第二个问题，快照其实你就当一个库咯，可以用except来找出不同的数据。
#16
老大坚持说要用这玩意，我提出的方案被否决了[通过程序控制，不用快照]
我的方案：
先说一下我的思路:在增删改对应的方法里，把变更的数据用对应的数据实体存起来，然后序列化存入到OpeLog表的recordData字段里(xml结构)，operLog表还有其他一些字段 如：
SQL code
?
1234567
logid 主键userId 操作人IDopeTableName 操作对应的表明recordData 变更数据 (xml)opeMsg 操作信息 nvarchar(max)opeType 操作类型（delete,update,add。。。）。。。。
但这样在方法里调用的话，需要组装数据，不够通用，工作量较大。。。
#17
的确这是工作中的不幸，上级往往以为自己比较牛逼，听不进。但是又给不出什么更好的办法或者回复。如果你的描述已经准确无误，那我想不到他有什么理由来推翻我的意见。
你的这个思路如果能支持大并发，倒没什么问题。
你的这个思路如果能支持大并发，倒没什么问题。
#18
如果要支持大并发，那就做成分布式的服务 （队列+WCF），个人想法呵。。。
#19
从应用程序上支持高并发会很痛苦...........
#20
呵呵。。。。 用户数多了，就需要考虑并发，神马缓存，分布式的就派上用场了，对程序的架构还有个人能力是个考验。。。。