媛珊娃娃 发表于 2013-2-20 15:36 static/image/common/back.gif
共享某些数据，但不共享数据库。
没搞明白，你的一个方案是共享数据库，然后打算用timer. 现在又说共享某些数据，不共享数据库了。需求不清楚大家没法给你出主意了。
本帖最后由 媛珊娃娃 于 2013-2-21 00:26 编辑
雪候鸟 发表于 2013-2-20 20:04 static/image/common/back.gif
没搞明白，你的一个方案是共享数据库，然后打算用timer. 现在又说共享某些数据，不共享数据库了。需求不清 ...
2个程序都各自有自己的数据库，要实现2个程序的部分数据共享，而不改变原有数据库。
共享数据库是我设想共享一个各自数据库之外的数据库来解决共享数据问题。其实共享什么解决这个问题都应该是无所谓的。不过是数据载体而已，比如说XML。
这个问题那个高人也已经详细解答了。当然我不能决定公司战略，所以虽然有最优解决方案，也不能自己去实施。现在公司已经确定用WCF了，实现p2p实现共享。
谢谢大家了。
本帖最后由 雪候鸟 于 2013-2-21 00:49 编辑
媛珊娃娃 发表于 2013-2-21 00:23 static/image/common/back.gif
2个程序都各自有自己的数据库，要实现2个程序的部分数据共享，而不改变原有数据库。
共享数据库是我 ...
有2个数据库也麻烦不到哪里去。在A和B的数据库中分别建立A到B和B到A的数据库连接。建立数据库连接就一个命令的事情简单的很。然后再A的表上做个触发器，当往A的表内写东西的时候这个触发器经过数据库连接把这些数据写到B的表中。B也同理。互相保持对方数据同步。这个不论效率还是保证数据的一致性上都不错。
雪候鸟 发表于 2013-2-21 00:46 static/image/common/back.gif
有2个数据库也麻烦不到哪里去。在A和B的数据库中分别建立A到B和B到A的数据库连接。建立数据库连接就一个 ...
这两个数据库未必在同一个系统下，有可能是两个local的数据库运行在不同环境里，之间未必能互相通信。
还有即使在同一系统下，两个不同的Schema下的数据库直接通过触发器和存储过程来保证数据的同步，在我看来是件危险的事情，如果是我设计的架构，我不会采用， 数据库之间的直接通信方法，而是通过应用层，将其隔离，这样的结构更加清晰，也容易维护和拓展，当然我不是数据库方面的专家，数据库优化方面的知识比较浅薄，但是对于性能方面，对我的客户来说，一般只要够用就好，为了结构的简单化，哪怕加大一些系统开销，我也认为是值得的。
本帖最后由 雪候鸟 于 2013-2-21 14:57 编辑
并非如此 发表于 2013-2-21 09:31 static/image/common/back.gif
这两个数据库未必在同一个系统下，有可能是两个local的数据库运行在不同环境里，之间未必能互相通信。
...
用数据库连接不需要数据库不需要在同一个系统，可以一个在中国一个在德国，只要防火墙让通过就行:)。schema不是数据库，至少在oracle和db2中都不是. 数据量大点更新频繁点，应用层得累死。我们这里java的应用也要处理类似的情况。一开始也是应用层通信的，最后把应用层的queue都写爆了，都来不及处理。很多应用层看似不错很完美的架构，在海量数据或者频繁更新面前都是无解。
雪候鸟 发表于 2013-2-21 14:55 static/image/common/back.gif
用数据库连接不需要数据库不需要在同一个系统，可以一个在中国一个在德国，只要防火墙让通过就行:)。sc ...
你所说的依然是同一环境内，也就是同样的数据库系统，只是地点不同，分布式而已，但是不同数据库系统之间多数是不能直接通讯的。
第二点，我说过我不是数据库优化方面的专家，所以在性能问题上，我承认你是对的，但是多数应用和你说的海量数据没有关系，当然这个问题要具体情况具体分析，我相信楼主公司的数据量没有大到那个地步， 通过楼主的描述，我猜想，他们公司的软件产品，可能属于工控类的。为了控制他们公司的硬件产品而附赠的，所以楼主公司，应该不是软件为主的公司，应该是生产电子仪器，或是大型电子机械的公司。
并非如此 发表于 2013-2-21 17:33 static/image/common/back.gif
你所说的依然是同一环境内，也就是同样的数据库系统，只是地点不同，分布式而已，但是不同数据库系统之间 ...
oracle的数据库和db2通过数据库连接没有问题的，所以我想只要是比较知名的数据之间应该都可以，因为数据库连接只不过是个基本功能。如果数据量小，而且能够肯定将来也不会增长太大，走应用层从审美上当然更漂亮些。
本帖最后由 雪候鸟 于 2013-2-21 21:12 编辑
sbtree 发表于 2013-2-20 15:39 static/image/common/back.gif
同意，数据来源唯一本身就保证了不同应用之间的数据一致性和同步性，在这方面就可以省去不少维护的工作了
数据库不应该只是被动的承受来自应用层的修改，应该有自己主动地一面，来保证数据的一致性。该数据层解决的问题就不要推倒应用层。现在大多数都推到应用层做我觉得原因主要是应用层开发人员多，所以习惯性的思维让很多数据问题都是在应用层解决。并且最近多年流行的贫血pojo的开发思维让人觉得，数据模型就是被动的，只不过是容器，其实充血的数据模型更能保证数据的一致性。估计做开发的现在多半都要做support, 很多support中的问题查来查去是数据的datenschiefstand, 很多跟贫血pojo开发思想有关。
本帖最后由 媛珊娃娃 于 2013-2-22 01:44 编辑
并非如此 发表于 2013-2-21 17:33 static/image/common/back.gif
你所说的依然是同一环境内，也就是同样的数据库系统，只是地点不同，分布式而已，但是不同数据库系统之间 ...
没错，我们的确不会有海量数据，说白了，我们要实现的是应用之间的通信。
雪候鸟 发表于 2013-2-21 21:02 static/image/common/back.gif
数据库不应该只是被动的承受来自应用层的修改，应该有自己主动地一面，来保证数据的一致性。该数据层解 ...
的确每个层应该满足自身的需求，这也是我的编程理念，不过你说的trigger我的确不懂，能否指教下如果在2个sql server数据库下利用trigger达到数据共享。