问题描述
我们公司现在有多个独立的系统在运行中，这些独立的系统又会有很多共同的基础数据，如：人员，组织，角色，还有一些共同的业务数据，现状是A系统的数据通过跑批或存储过程同步到B系统，B系统经过一些业务加工又会把数据同步给C系统，这样在系统间同步数据总会出现各种各样的问题。现在公司想把这些系统重新开发，我的想法是把所有系统的数据集中到一起，做一个统一的数据库平台，然后其他系统都是基于这个数据库平台进行开发，这样就可以避免系统间同步数据的苦恼，不知道这样的方案可行性怎么样
解决方案
鸡蛋都放一个篮子里面，篮子坏了就都打了。要看你们这些系统是否能接受同时不能使用的情况。分开也有分开的好处，至少可以独立作业，一个数据库坏了或者数据出问题了不会影响别的系统。个人认识：与其把数据库作为统一平台，不如做一个数据的接口服务平台。所有数据交互都要走这个接口（怎么实现随便了，可以是WEB-API，可以是Web-Service）这样的话，至少你可以选择隐藏在这层接口后的数据库是现在一样的大家被动同步的方式，还是你想做的统一数据库平台。在短期内，做出这个服务层之后，别的模块只需要少量修改，就可以按照目前的业务流程持续作业，然后慢慢修改这个服务层后面的数据组织方式。这样至少可以平滑过渡，不至于大家突然变换业务流程不习惯，也可以在缓慢过渡过程中及时发现新问题，及时解决。
解决方案二：
思路错误！应该是系统间的耦合要低，内聚要高，如果是系统需要数据共享，可以用ESB企业服务总线。
解决方案三：
人员，组织，角色，之类的放在一个数据库里，实现服务接口，由各个子系统调用。a，b，c各个子系统的特性功能还是保持原来的库不变。子系统间必须有交互关系的数据用接口的实现，比如webservice之类的。
解决方案四：
我们公司就在做这样一个数据库平台，其它系统通过webservice访问数据库。个人认为，这个数据库平台管理杂乱，很多数据库的特性不能够使用。目前尚在开发阶段，可能以后会有更多功能。
解决方案五：
当然可以，但是人家每个系统都是独立完成的，又不是一起完成的，只要你肯出钱重新来一遍，那都不是事儿。
解决方案六：
第一，如果数据量很大，放在一个系统里，不知道是否可以承载的了第二，分散开来的好处就是其中一个库挂了，不影响其他库的使用如果想要方便管理，可以选择使用集群，这样同步数据方便也可以，也不用担心其中一个库挂了导致系统不能用当前，如果系统不是特别大，库数据也不是特别大，可以选择并到一个库中，方便管理，维护