我有一个运行我们的会计/库存应用程序的现有 SQL Server 2005 数据库。我们正在考虑使用一个新的在线订购框架——它有自己的数据库。
如果我们使用这个新框架,我们将需要几乎实时地在我们现有的库存数据库中传输在线订购数据(库存、价格、订单、客户)。数据传输不必是实时的,但必须是快速的。两个数据库都在 SQL Server 中。
所以我的问题是......在具有不同模式的两个数据库之间来回传输数据的最佳方式是什么?
复制?西斯?你会建议什么,为什么?
任何帮助,将不胜感激!
我有一个运行我们的会计/库存应用程序的现有 SQL Server 2005 数据库。我们正在考虑使用一个新的在线订购框架——它有自己的数据库。
如果我们使用这个新框架,我们将需要几乎实时地在我们现有的库存数据库中传输在线订购数据(库存、价格、订单、客户)。数据传输不必是实时的,但必须是快速的。两个数据库都在 SQL Server 中。
所以我的问题是......在具有不同模式的两个数据库之间来回传输数据的最佳方式是什么?
复制?西斯?你会建议什么,为什么?
任何帮助,将不胜感激!
业务规则是最难的部分
单向同步?双向同步?实时推送?每晚更新?转储并重新加载?比较和更新?解决冲突?哪一方获胜?以一种方式推送只读信息,以另一种方式订购信息?更改/取消/等呢?订单状态会被推迟吗?
你可以看到我要去哪里。技术是次要问题。
由于业务规则问题,并且由于两个系统具有不同的模式(和不同的目的),这不是标准的数据移动,并且大多数“标准”答案(复制、日志传送等)都不在表中.
有一些框架可以帮助解决这个问题,例如Microsoft BizTalk或Scribe Insight。但是,这些既麻烦又昂贵。
使用 C# 或您喜欢的语言创建基于 SQL 触发器或计划推送(取决于您的需要)的自定义队列系统并不难。这大概就是我要走的路线。它可能涉及第三个“传输”数据库来保存一方所做的更改队列,以及一个应用业务规则并将数据推送到另一方的模块。
就我个人而言,我会尽可能快地逃离这个噩梦。由于您尚未购买此在线订购,我建议保持数据与现有应用程序同步是不这样做的正当理由。如果您购买此产品,您将永远后悔您的数据将变得多么混乱,以及您花费了多少时间和金钱来试图让事情正常运行。这是一场等待发生的灾难。当仓库里没有货时,您最终会让人们订购本应在库存中的物品。不要这样做。这是愤怒的客户和愤怒的经理的保证。随着时间的推移,聘请一些开发人员将您自己的在线订单放在一起访问您的数据库的成本要低得多。如果他们继续反对你的反对,我会更新我的简历。
根据个人经验,如果没有其他选择,我只会使用复制。对于任何架构更改,您都必须将其拆除,并且它有爆炸的趋势。
为此,我很可能会使用 SSIS。构建转换包相当容易,维护也相当简单。
复制效果很好,如果它是两种方式,它可能是你唯一可行的选择,因为冲突解决是内置的。
如果您要单向,SSIS 或表上的触发器会很好,并且会实时推送数据(对于触发器)或以您想要的任何时间间隔(SSIS)推送数据。SSIS 的优势在于它是一个后台进程,而触发器在推送数据时可能会阻止供应方的交易。
如果您希望移动大量数据,还有其他产品可以为您完成,但如果数据量不大,使用 SQL Servers 工具的解决方案应该可以满足您的所有需求。