关于分布式数据库设计，请大虾帮忙分析下，有详细描述

Question

先介绍一下需求： 
　 
客户是一个集团客户，下属几十家子公司，且子公司下面还有二级子公司，各自独立核算．业务大同小异． 客户的要求是：建一个供所有子公司通用的业务系统．　集团公司能够监管各子公司数据并且能对所有数据进行综合分析统计，且集团和子公司之间 ，子公司和子公司之间有业务联系．也就是能部分数据共享．但不能做成一个集中数据库，各子公司通过Ｂ／Ｓ系统访问的模式，必须要做成分布式 数据，也就是各分公司有自己独立的数据库。以保证网络不能通信的时候，子公司的业务不受影响。但是又必须要保证子公司之间部分数据共享，且 所有子公司数据必须要采集到集团总部。 我设计了三个方案： 方案１：采用分布式数据库设计，也就是由DBMS自动管理的数据订阅、分发技术实现数据库的数据同步，以达到数据共享的目的。但是这种设计要求 　　　　必须要有专网通信。但是我们客户的个子公司距离很远不可能实现专网通信。 方案２：使用中间件，也就是开发一个专门的数据交换工具。各分公司部署一套独立的相同的数据库，总部集团部署一个数据库，然后各分公司数据 　　　　实时上传到集团总部数据库（总部集团一个数据库存储所有子公司的数据），然后再把数据分发到各子公司（数据增量同步），这样就可以 　　　　实现数据共享。所有数据均集中到总部后统一分发。但是有一个问题是各分公司数据量很大，且分公司数量有几十个，这样总部数据库数据 　　　　量将异常庞大。且在总部服务器上频繁读写，估计总部服务器将难以承受，效率会很低。且数据分发还存在很大技术问题。 方案３：各分公司部署一套独立的相同的数据库，总部集团针对每一个分公司建一个相同得数据库帐套。各子公司实时的把自己的业务数据交换到集 　　　　团服务器上自己对应的帐套内，这样集团可以通过选择不同的帐套来进入各分公司数据库进行监管．然后再建一个数据仓库，从各分公司帐 　　　　套中采集数据，然后在数据仓库上开发一套Ｂ／Ｓ的BI系统，对数据进行综合分析统计．这样子公司也可以通过BI统计分析二级子公司的数 　　　　据．同时通过BI系统实现数据共享（也就是各子公司可以通过BI平台进行业务），这样解决了效率的问题，同时避开了数据下发的问题是还 　　　　是有点问题，就是在集团总部要建很做帐套，也就是很多个数据库（每个子公司一个数据库），如果增加一个子公司就要新建一个数据库． 　　　　这样集团服务器压力还是很大． 　　　　目前偏向于第三种方案，但是心里还是没底．毕竟这么复杂的架构还是第一次做．不知道会有什么问题没有，请各位大虾帮忙分析一下！　　　　　小弟在此谢过了，也希望为有同样困惑的同仁提供一点参考！　

Answer 1

不知道为什么要轻易否定方案一，SQL Server支持透过Internet的数据库复制，不需要拉专线。可以用VPN，另外还有一个透过https管道的选择。

Answer 2

我觉得采用分布式数据库方式，数据安全可以利用VPN设备实现数据加密传输，软件VPN也很多，投入也不是很大

Answer 3

能用数据库的就用数据库本身的吧。。放着那么好的一个功能不用，而花很大精力去做另外实现同样功能的东西，不合适吧。而且微软的复制，在分布式应用上还是挺有优势的，也比较成熟，特别是SQL Server 2008又加入了新的功能。

Answer 4

有个问题，这么庞大的系统要怎么维护呢？？每个分公司都有配备一个DBA吗？？

Answer 5

建议以定时数据增量同步方式处理需要共享的内容
这样构架是最灵活的，对网络的要求也不苛刻
对于网络，各子公司可走VPN通信，若不行，以FTP OR HTTP传输数据亦可

Answer 6

看了一遍又一遍客户的要求，子公司的数据与总公司的数据是否允许有时差？比如，1-2天，或者更多。
这样的话，似乎就可以使用job一类的东西，等一天的业务结束后，传到总公司，然后总公司下发到分公司。
这种方案会有一定的时差。
个人感觉另外一个办法是webservice，各个分公司的数据，以及公司的数据使用webservice封装起来，然后总公司需要的时候，调用这些取得各个分公司的数据，各个分公司也可以使用调用这些webservice取得其他公司的数据。
不过这样的话，代码工作量似乎变得多了。。
仅供参考，楼主自己取舍吧