一般的做法是一个库多个表~~这样效率高些~~

当然是一个库，多个表了，否则的话，你的CConnectPtr需要多少个，这样操作起来的话会比较烦

一个库多个表，这样连接相对少一些，而且其他对象的操作也较为方便！

如果你的数据量不是很大，这里说的大是指ORACLE、SYSBASE等 >200000，SQL SERVER >50000
那么可以在一个数据库中建立多个表，如果数据量太大。比如销售定单的数量经过一两年后可能达到几十万到上百万的数量，那么建立相应数量的历史数据库是必要的。否则数据检索的速度会大大下降，即使你定义索引定义的很好。

当然是一个库，效率高，方便。再说两个库之间的互访是不是很麻烦啊！你觉得呢？在db2 中，写存储过程，一个事务中只支持一个库的访问，如果访问另外一个库，那怎么办？

一库多表，对于历史数据，可以将其归入一个历史表中，按一定的规则建立表分区，并为各个分区建立索引，数据量应该不是问题。

TO ：db2_seeker(小顺)　
数据量当然是应该在考虑的范围之内的.我说的历史表是指将不会再做修改、很少做统计的记录放在里面.因此对于他们是不需要做太多的管理工作的。仅仅在应用中查询历史数据的时候才用到。例如财务上对于几年前的某次帐目往来，也许一年里面也难得查询一次。这样的帐目在一个年度里是有可能发生十几万笔，这种情况下，我看还是专门建立一个历史数据库比较好（这种情况在大的企业里是很普遍的现象）。
TO：dragonerfish(jimmyyu)　
如果需要做历史备分的数据表比较多。而且系统设计使用的年限比较多。每年对需要备分的数据表都建立一个新的历史表。那么用不了几年，当前数据库中就会数据表成灾。简直是灾难呀。设计系统不能光看眼前，要有长久的眼光。

同意：　mat(苍天不老)　

如果是oracle一个库好，
sqlserver用两个也行
将系统表放在一个库（如帐套等）
其他数据表放在另一个库里
这样在新建帐套时系统表不用重建

听听高手上课

mat(苍天不老)　：如果是像你说的那样，另外一个库只是做一个备份历史库的话，应该没有问题，因为牵扯到的双库之间的互访会很少。但是如果是把整个系统的平均分开到各个库中的话，我想还是用一个库吧！还有，数据表备份不需要每年都建立一个新的历史表吧。如果是这样的话，再有个库岂不也会“数据表成灾”呀！

我同意mat的意见，建立数据库的时候，首先要考虑整个系统主要是基于事务还是基于查询的，数据量的多少，历史数据使用的情况，是否要使用到olap，moonlost问题是不是有点过于笼统了。如果是基于事务的，当然是在一个数据库中好。