两种数据库设计方案，是分还是合？请大家说说自己的看法！

webdiyer 2003-11-10 08:55:18

我们正在用Asp.net做一个中型规模的B/S项目，这个项目中有两个模块，每个模块对应一个SQL Server数据库，但两个模块中有些表是通用的，比如：单位名称表、单位类别表、用户名称表以及用户认证信息（密码、帐号、权限等）等表，以后还要加入更多模块，现在在对数据库是合还是分的问题上产生了不同意见，具体方案和理由如下：

>>>数据库拆分方案：

将所有模块中通用的表，如单位表、用户表等独立出来，另建一个新数据库，每个模块的数据库中只保存与该模块相关的数据。

理由：数据库功能定义清楚，维护方便，因为如果合并，一个数据库中将会有几百个表、视图以及上千的存储过程，其中既有通用数据又有其它数据，对象之间的关系错综复杂且数据混乱，难以维护。

>>>数据库合并方案：

将所有的数据库合并到一块，即整个项目只用一个数据库，在对象名前加上模块名前缀以区分不同功能模块的对象。

理由：整个项目只有一个数据库，有很好的便携性，尤其是在Asp.net应用程序中，只需要一个数据库连接，代码更少，性能更好，如果拆分为多个数据库，很多时候需要跨数据库获取数据，这个不但不易实现，而且同时打开多个数据库连接会严重影响系统的性能和运行速度。

以上两个方案究竟哪种更好，请大家说说自己的看法，另外说明一点，合并方案是我提出来的，因为我是做Asp.net程序的：）但同时也负责设计数据库！谢谢！

...全文

82 29 打赏收藏转发到动态举报

写回复

用AI写文章

29 条回复

切换为时间正序

请发表友善的回复…

发表回复

webdiyer 2003-11-12

打赏
举报

谢谢这么多热心的朋友提出建议和意见，因为现在的数据访问层本身就是独立的，所以无论是分是合对程序来说只影响数据访问层，最麻烦的是数据库中几百个存储过程和视图，要分开的话改动的代码量数倍于合并方案，而且很多的地方得跨数据库来访问数据，这样很不方便，而且灵活性和数据访问效率也远不如在一个数据库中，所以基本上已经准备合并了，不过因为这样的改动对整个项目有非常大的影响，所以在做出决定之前还需要再好好研究一下。非常感谢大家！！

lucidaxy 2003-11-11

打赏
举报

合并的方案我想大家都很熟悉，只要找一本数据库设计相关的书就可以操作了。
虽然不一定会采用分开的方法，但大家详细讨论一下，我想也是大有好处的。
就楼上所讲分开的问题，主要在两个技术问题和一个实用问题（不一定大家都会碰到），
一是关系数据库的内在属性无法利用数据库工具直接建立，主要表现为对数据库操作性和效率的担心
二是命名约定，其实归根结底就是标准问题，这个问题的解决方式就是制定一个统一的标准，设计规范，使将来的基于本系统的数据库设计严格按照标准设计。
我们再就这两个方面稍作展开
实用问题是迁移代价

第一，操作性和效率
先讨论内联外联，关系数据库建立内联外联机制的作用主要是为了方便查询，从关系属性上讲，我现在能看到的分开方案必然损失的特性是数据库强制的关系完整性验证，解决这个损失的方法是将有级联属性的表放到一个数据库里，因为这样的分割是不值得的。而简单的主外键约束，在分开的数据库中用代码维护也是可以的，当然，这个效率肯定会比数据库内主外键关系效率低，而且开销大，不过性能上的损失我想并没有你想象中的大（前提是规范的数据库设计）。正如楼上所说：在一个数据库中进行联合查询或更新等操作，性能和速度远远超过同时同时操作两个数据库。但对于联合查询而言，这个命题成立却是有条件的，表面上看，联合查询需求越旺盛，越多，在多个数据库中操作就越麻烦，其实恰恰相反，对于规模庞大的，关系复杂的，含有非常专业的查询逻辑的联合查询，我们唯一的解决方案就是数据仓库技术，而采用这一技术后，分开合并所产生的效率问题反而缩小了。对于更新问题，按照数据设计的一事一表的原则，在应用中，用一个sql语句更新两张表的情况是应当避免的，这也是第二三范式所专注改进的地方，如果数据库设计能够遵循到第三范式，那更新问题所引起的效率降低是可以减少或避免的。
因此，我觉得，最大的矛盾不在性能效率上，而在设计上，分开方案对设计的要求相当高。按照中国的现状，可操作性确实成问题。

第二，命名约定（标准制定）
对于标准有两个过程，一个是制定，一个是实施。
第一制定框架，然后根据实施者（程序员，模块）的要求制定统一的数据库构架方案。
理想情况是，软件系统一旦上线，可以直接通过增加标准客户数据库实现平台的扩展。同时制定标准数据接口，将其他系统的数据引入，按照这个规范制定的数据库，都可以直接应用系统的各个标准功能。你只要对对方系统做一个标准认证，给一个使用授权，就可以收钱了，这可以算是最高境界了，得标准者的天下，不过这点，在中国短期内看来是很难做到了。

应用问题，迁移代价
这个因人而异，改写上百个存储过程确实是一件很头疼的事，我也无话可说，不过代码迟早是要重写的。现在是不是最适合的时候，只能自己看着办了。

好了，本人只是就分开方案阐述了一下自己的看法。可以看到，分开需要面临的问题还是非常多的，呵呵，就我现在所在公司的资源能力来讲，我会选择合并。贵公司如果多几个思归那样的高手，分开才有胜算。

ruirui521 2003-11-11

打赏
举报

本人绝对同意 saucer(思归) 的，楼主这种系统如果做成n层的话，倒是可以忽略数据的分布问题。
而在.net中ado.net正好可以适应抽象数据层的做法。
如我现在负责的项目，就是把数据层抽象出来了，而同时做了支持Oracle9i和SQLServer2000两个版本。这样数据的访问都交给了DataAcess,数据库的设计者和业务层在逻辑上相对独立。如果你的项目够大的话，做数据库分布式也是非常容易的。

webdiyer 2003-11-11

打赏
举报

谢谢大家，特别是lucidaxy() 说的很有道理，现在分开的问题是：每个数据库都与单位用户表所在的数据库关联，如果要在其中获取单位用户，就得连到单位用户数据库，如果合并的话用内联(inner join)或外联(outer join)可以很方便地在存储过程中直接从单位用户表和具体的数据表中获取数据，如果放在多个数据库中就没有办法再联接起来，而且外键约束也没法用了，最主要的是，现在的好多存储过程都是同时从单位用户表和数据表中用上面说的内联和外联方法获取或更新数据的，一旦分拆数据库，不但二三百个存储过程得全部重写，而且程序中要改动的地方也非常多，再说一个项目用多个数据库会造成很多不便，合并起来只要严格遵守命名约定，那么表的功能定义还是分得很清楚，而且在一个数据库中进行联合查询或更新等操作，性能和速度远远超过同时同时操作两个数据库。

webdiyer 2003-11-10

打赏
举报

to snla(小鸟想飞高)：
建一个数据库带是几个数据库，或者建一个文件夹还是几个文件夹，绝不是那么简单的问题，就文件夹来说，不要说把一个文件夹分成几个，单是移到一个asp.net应用程序中文件夹的位置，如果不改很多代码，我也保证你的程序绝不能正常运行！！而对数据库来说，一个数据库和几个数据库就差得更远，比如在一个数据库中的话，我可以在一个存储过程中串联起多个表进行联合查询，如果这些表在两个数据库中，你就无法一次串联起这些表来进行查询！我现在的数据库中就有很多这种存储过程，所以如果拆分为多个数据库，这些存储过程就全得修改，而且在访问其它数据库中的数据时，每次都得连接到该数据库获取数据。

在asp.net中连接多个数据库，并不只是代码量多少的问题，因为连接数据库是比较耗费资源的操作，对asp.net应用程序运行速度等会有明显的影响。

谢谢提出宝贵意见！

realsnow 2003-11-10

打赏
举报

哇！你出的问题都这么强啊！
搬个板凳看高手怎么解决吧。
mark!

webdiyer 2003-11-10

打赏
举报

非常感谢大家提出宝贵意见！
思归提出的这种在数据访问层解决的思路非常独特，因为现在的系统是别人做的c/s系统上改为b/s的，数据库部分就是原来的c/s系统的，现在因为发现有不少问题，所以才决定重新设计一遍，也就遇到了现在这个是分还是合的问题。把静态的通用数据放在asp.net应用程序缓存中确实是很好的办法，但问题是：现在的单位用户等通用数据是和另一个模块的数据在一个库中，这个数据库中的有二三百个存储过程，好多存储过程都是用内联(inner join)或外联(outer join)语句来同时从单位用户表和其它表中进行查询或更新数据，如果把单位用户表建到另一个数据库中，就不能再用内联或外联语句将单位用户表关联起来，而得从单位用户表所在的数据库中获取单位用户信息然后再对当前数据库中进行操作，这样数据访问的速度不但没有在一个数据库中访问快，而且需要改动的地方很大，不但得改程序，上百个存储过程都得修改，尤其是其中有个汇总程序，调用了一个汇总的存储过程，这个过程根据单位用户表中的每个单位依次对几十个表的数据进行汇总，光这个过程两个人就写了好几天！现在如果把单位用户表建到另一个数据库中，修改这些存储过程的麻烦程序绝不亚于重新写一遍。现在真是左右为难！！不知道大家还有想法？？请不吝赐教，非常感谢！！

snla 2003-11-10

打赏
举报

我觉得一个数据库，或者设计几个数据库并不是什么问题，也没有太多的影响！数据库就像一个文件夹，你的意思就是把一些文件放到一个还是几个文件夹。放到一个文件夹当然相当的实惠，但合理吗？不相干的一些表放在一起，根本没有意义！

一个数据库连接代码少？只是少一个连接字符串吧，其它的都可以共用的！
性能好？一个数据库几百个表性能会好？？？
跨数据库去数不容易？可能你以前很少这么干吧？相同数据库类型统一数据库和跨数据库取数区别并不大！
同时打开多个数据库连接严重影响性能？耗资源，我承认！多7、8个联接也没那么严重吧！

loulanlouzhu 2003-11-10

打赏
举报

理由：数据库功能定义清楚，维护方便，因为如果合并，一个数据库中将会有几百个表、视图以及上千的存储过程，其中既有通用数据又有其它数据，对象之间的关系错综复杂且数据混乱，难以维护。

--->>我觉得这不能成为分开的理由!

表,视图,存储过程的多少不因为你分成两个数据库而发生改变!它们之间的关系也不会因为分成两个数据库而变得简单!!因为你的业务逻辑是一致的!!

goody9807 2003-11-10

打赏
举报

合并

wsqsoft 2003-11-10

打赏
举报

同意saucer(思归) ，把数据访问层分开

henryfan1 2003-11-10

打赏
举报

还是合好，没有必要维护两个一样的数据库，发布也不方便。
模块功能用名称空间来区分就可以了。
在业务层中使用COM+服务，提高程序效率。

8u9 2003-11-10

打赏
举报

如果从数据库访问简洁性的方面考虑的话，自然是一个库方便，即使做数据访问层也是非常容易控制。

audio77 2003-11-10

打赏
举报

赞成思归，高手就是不一样，利用分层的思想就可以使得数据库的设计与访问分离开来，一层是一层的事，对另一层的影响不大

buaawjh 2003-11-10

打赏
举报

"项目只有一个数据库，有很好的便携性，尤其是在Asp.net应用程序中，只需要一个数据库连接，代码更少，性能更好"

我读这句话表示怀疑，其实安全权限的设置不是说你对那个数据库，而是你能对那个表进行什么样的操作，我的一个数据库程序就设置了5种连接字

lcy5415 2003-11-10

打赏
举报

我觉得还是分开好,分开有灵活性

realsnow 2003-11-10

打赏
举报

个人看法是合并的好啊，确实是能省去了许多的麻烦，还能有效的提高效率。数据库太大，东西太多可以用完善的开发计划、开发机制和开发文档来弥补，而系统的性能和可扩展性才是关键啊！

flyinglz 2003-11-10

打赏
举报

如果各个模块可以独立运行且能自由组合我建议在开发时使用第一种方案,同时可以在部署时使用第二种方案.

第一种方案在开发时公用数据非常清晰,不需要重复建立测试数据等很多工作,而且使每个模块的开发人员只需要关注自已这一块的数据,方便了人员开发,但各模块自己的数据表还是应该有与其它模块数据表的明显标志.这样在部署时可以根据模块需要在公用数据库中加上各模块的数据表,这样大家就可以共享一个数据库连接了.解决一第二种方案的不便.

saucer 2003-11-10

打赏
举报

>>>>这个项目中有两个模块，每个模块对应一个SQL Server数据库

不同模块依赖不同数据库，听上去好像设计有点问题

也许比较好的方法是写个数据访问层把这部分的决定抽象出来，这样前面的几层不需要知道这些细节，即使你在数据层用10个数据库也不需要改变前面几层的逻辑

至於是分是合，多从功能考虑，仔细分析用户(将会)使用这些数据的模式，譬如，哪些是只读的数据，这部分的数据都可以考虑缓存在应用或缓存变量里，那么，他们在哪个数据库里也许都无关紧要，哪些是需要经常更新变动的数据，哪些数据也许会经常性JOIN在一起，等等。。你也许一下子并不知道这些细节，所以写一个数据访问层也许应该是更迫切的事情，有了这个数据访问层，即使哪天你改变主意了或发现系统的性能有问题，需要么从分到合或是从合到分，只要改写这层即可

wincarf 2003-11-10