我有一个使用自己的数据库生产的应用程序超过10年。
我目前正在开发一种新的应用程序（一种报告应用程序），只需要对数据库的读访问权。
为了不与数据库链接太多并且能够使用更新的DAL（Entity Framework 6 Code First），我决定从一个新的空数据库开始，我只添加了我需要的表和列（不同于生产的名称）。
现在我需要一些方法来定期使用生产数据库更新新数据库（如果它是 - 几乎是立即的话，那将是最好的。）
我在http://dba.stackexchange.com上提出这个问题犹豫不决，但我并不一定只限于使用SQL Server（如果需要，我可以开发并运行一些自定义应用程序）。
我已经进行了一些搜索并获得了（部分）解决方案：
使用事务复制创建一个较小的数据库（只包含我需要的表/列）。但据我所知，我有不同的表名/列名称将是有问题的。所以我可以用它来创建一个由SQL Server自动复制的小型数据库，但是我仍然需要将这个数据库复制到我的新数据库中（它可能会避免我的生产数据库过于紧张？）
< / LI>使用触发器插入/更新/删除行
创建一些自定义作业（SQL作业或一些每X分钟运行一次的Windows服务）更新必要的表（我有一个LastEditDate，由我的触发器更新）表，所以我可以知道自上次复制以来已经更新了一行
您有什么建议或者其他一些我没有预见到的解决方案吗？
由于
答案 0 :(得分：0)
我认为事务复制比使用触发器更好。 由于每个DML事务触发了触发器，源服务器/数据库中将使用太多资源。
可以将事务代表安排为SQL作业，并且每天/晚运行几次或作为夜间预定作业的一部分运行。这实际上取决于源数据库的繁忙程度......
还有一件事可以尝试 - 数据库镜像。这取决于你的SQL Server版本。
答案 1 :(得分：0)
如果是我，我会使用事务复制，但保持表/列名相同。如果你有一些真正的理由需要他们改变（我真的不能想到任何好的和很多坏的），请将每个表包装在一个视图中。至少在这种情况下，视图是数据来源的文档。
答案 2 :(得分：0)
我要把它扔出去并说我使用了事务日志传送。您甚至可以将辅助DB设置为只读。可以设置一些完全恢复模式和事务日志备份，但这样您就可以自动将事务日志恢复到辅助数据库并随之处理，辅助数据库将与上次事务日志备份一样最新
根据数据的当前状态，如果您每天只需要这样做，您可以设置一些可以进行日常备份的内容，然后将其恢复到次要内容。
答案 3 :(得分：0)
最后，我们选择了Trigger解决方案。我们每天都没有那么多变化（可能是500,1000最高），并没有对当前数据库施加太大压力。谢谢你的建议。