一个系统设计包含100多个数据库，有问题吗？

[davidweimin]

我现在的项目是集团级WEB应用，B/S模式，考虑到子公司业务相对独立性，为每个子公司建一个数据库，这样，如果有100个分公司，就会有100个数据库，考虑每个公司再生成历史数据库，数量就更大了。我不知道这样设计会不会有问题，后台数据库是考虑与SQL 200,ORACLE 8I，都兼容的。请赐教。

[biti_rainy]

对于mssql可能是数据库的概念
但对于oracle来说，你只需要建立多个user和tablespace就可以了


当然，如果有多台数据库服务器是另外一回事情

[ozzzzzz]

哦 又是一个这样的朋友 我都不知道说什么好了
davidweimin (小虫) 你要做什么 你知道你在做什么
好好看看数据库原理 你的问题实在是让我伤心

[ozzzzzz]

biti_rainy(biti_rainy)
多台服务器怎么了 难道你就不知道分布式数据库
还有为了你的程序的安全性 你一定要用vpn 切切

[bluepower2008]

如果每个分公司也有自己的开发和数据库维护人员，用100多个数据库也不是不可以，更好控制权限。但如果只是总部设计数据库和项目，子公司只管应用，那么就不用那么多数据库了，所有数据放在同一个库中，更好处理数据。总部进行数据统计时，不用建分布视图，也不用跨数据库查找。

[biti_rainy]

楼上的
你还没有明白人家需求是什么
人家到底要什么
难道就确信是分布式数据库?

如果不同分公司数据之间没有什么约束
完全可以分布在不同的独立的服务器上

不过我承认可能我说的简单了点,让大家误会了

也许,既然有这么大的应用
设计的时候就应该有比较熟悉数据库的人才好

[KingSunSha]

国内的大多数项目连个设计小组都很少有，这个小组应该由业务分析员（business analyst）、程序分析员（software analyst）、系统管理员（operating system administrator）、数据库管理员（database administrator）组成。其中任何一个角色没有多年的实践经验都是无法胜任的。

哎，所谓的集团级，也罢，也罢。。。

[davidweimin]

三千老兄，你的话我太有同感了。
我们公司作为软件公司，有100号人，算也过得去了。 但摊到我这个项目，想配个专职数据库管理员，没有！ 连专职的系统分析员还是努力争取才得来的，作项目经理，难啊！
回到我的问题。我这个项目要求前端代码要能同时支持SQL2000和ORACLE，可项目组成员对ORACLE都不熟，所以我只能考虑尽量采用标准SQL，先在SQL2000下实现。
程序开发用.NET,这个公用数据库接口也令我很头疼，因为ORACLE的存储过程返回结果集同SQL2000差别很大（拜读过三千老兄以前的帖子）。我目前的系统系统分析员之所以设计成这样，一方面是各个分公司之间业务相对独立，要求互相保密；另一方面可，考虑今后推行ASP模式。但是我一想到今后进入数据库系统，首先看到的是100多个数据库列表,MY GOD,用户，特别是DBA,会不会犯晕？单单一个系统，是不是太那个了？而且，集团总部要从各分公司的数据库里提取数据进行报表汇总、合并，这样做会不会有问题?
但如果不这样做，各分公司相互之间的访问权限又怎样控制呢？而且各分公司的业务系统结帐是不可能统一的。
恳求各位高手赐教，此方案我是PASS,还是发回？

[KingSunSha]

几点建议：

1、和用户开会、开会再开会，弄清楚每家分公司的业务流程，包括所有细节。分析、分析再分析，找出共性和差别，如果差别影响比较大的话，还要和用户商量能不能对业务流程进行修改。总而言之，开发、维护一个统一的版本比维护多个不同版本的成本低得多，要让客户深刻地理解这一点。
2、从你的问题来看，要集中在一个数据服务器上比较困难，除非用户愿意铺专线架设自己的intranet，那个成本非常高。所以很可能是多个数据库服务器相互交换数据。在这种模式下，必须有人负责数据交换借口的设计和维护，这一点，在我们公司是非常重要的。
3、同时支持sql server和oracle，在我看来既无必要又成本太高。除非你是想把这个系统产品化。如果真的必须这么做，我建议采用三层架构，把对数据库的操作写到中间层（其实还是必须写两套代码，要完全兼容是不可能的）。那样客户端就不用关心后台数据库是什么了。这么考虑也是基于成本原则，要让每个开发人员既懂sql server又懂oracle，那成本肯定非常之高。

要注意的东西实在很多，一时也说不清楚。你最好采用一些软件工程的方法（比如UML）之类的分析一下先。

[mmzxg]

哎，三千兄一针见血，中国软件和外国的软件的差异就在于此了！

[zhenhao]

我感觉你还是找些专门的公司去咨询一下。没有经验设计可能会产生不良后果的。

[davidweimin]

多谢三千兄，其实我现在这个项目就是产品化的。是基于三层结构的，不过你说要写两套代码对应两种数据库，那不是代价很大，难道不能把问题隔离在数据库接口层吗

[icevi]

其实这样设计也没什么不可以，但是对服务器及网络的要求比较高。以前有客户是这样的，不过不是WEB版的，是三层C/S的，数据库及中间层服务器都在总部，分公司只有客户端。也是一个分公司一个数据库的，绝对超过100个，他们还是有专线的，速度也不怎么理想。

我觉得你们现在没必要一定要做到能兼容MSSQL和ORACLE，这样开发难度也是相当大的，而且真的是不好做通用的。不如先做好一种，做时尽量考虑以后移植的方便性，以后再加进去好点。

另外我觉得可以考虑不将全部数据都放在总部，可以分区域设几个服务器，或是各分公司用本地的数据库（一般分公司自己的数据不会太多的），再用某种方式汇集到总部去。要做到完全实时不一定是最好的方式。

其实我觉得这样去想一个方案合不合理不是很地道的方式。其实哪种技术应该都是可以去实现的，但需要的投入、产生的效果、实施的难易程度会不一样。所以应该在考虑客户的需要的前提下，设计几个不同的方案，再对各个方案进行一下整体的评估，最后确定最优方案。评估时考虑各方面的情况，最好是有量化的指标，这样才能做出接近最优的决策。这样前期的项目评估做到位了，项目失败的风险就会小些，否则可能会造成一些噩梦式的项目开发。项目失败我想是哪个公司都不愿意面对的。

[dgz01]

UP

[shengzi_78]

up

[davidweimin]

多谢各位的高见，先办分结了。

[KingSunSha]

我对sql server的了解有限，但就我知道的来看，写成通用模式相当困难。或者你必须放弃数据库系统中非常有特色的一些功能，比如oracle中的sequence在sql server中就有不同的方式实现，再有oracle中rowid、rownum之类的伪列在某种场合是非常有用的。

我说的写两套代码是指在中间层，应该和你说的数据库接口层是一个概念。