在不同数据库模式之间同步数据的最佳技术？

我有一个运行我们的会计/库存应用程序的现有SQL Server 2005数据库.我们正在寻找使用新的在线订购框架 - 它拥有自己的数据库.

如果我们使用这个新框架,我们将需要将现有库存数据库中的在线订购数据(库存,价格,订单,客户) - 几乎是实时的 - 传输.数据传输不一定是实时的,但必须快速.两个数据库都将在SQL Server中.

所以我的问题是......在两个数据库之间来回传输数据的最佳方法是什么,具有不同的模式？

复制？SSIS？你会建议什么,为什么？

任何帮助,将不胜感激!

业务规则是困难的部分

单向同步？双向同步？实时推送？每晚更新？转储和重装？比较和更新？解决冲突？哪一方获胜？以单向推送只读信息,并以其他方式订购信息？如何更改/取消/等？订单状态会被推迟吗？

你可以看到我要去的地方.技术是次要问题.

由于业务规则问题,并且因为这两个系统具有不同的模式(和不同的目的),这不是标准的数据移动,并且大多数"标准"答案(复制,日志传送等)都不在考虑范围内.

有一些框架旨在帮助解决这个问题,比如Microsoft BizTalk或Scribe Insight.但是,这些都很麻烦且昂贵.

根据SQL触发器或C#中的预定推送(根据您的需要)或您喜欢的语言创建自定义队列系统并不困难.这可能就是我要去的路线.它可能涉及第三个 "传输"数据库来保存一方所做的更改队列,以及一个模块来应用业务规则并将数据推送到另一方.

就个人而言,我会尽可能快地逃离这场噩梦.由于您还没有购买此在线订购,我建议保持数据与现有应用程序保持同步是不做这种事情的正当理由.如果您购买此产品,您将永远感到遗憾的是,您的数据将变得多么糟糕,以及您花费多少时间和金钱来让事情正常运转.这是一场等待发生的灾难.当仓库中没有人时,你最终会让人们在库存中订购物品.不要这样做.这是愤怒的客户和愤怒的经理的保证.随着时间的推移,聘请一些开发人员将您自己的在线订单组合在一起可以访问您的数据库.如果他们继续反对你的反对意见,我会更新我的简历.