由于众所周知的原因，ACCESS在大型站点应用中都靠不上边，主要问题就是数据量大了以后几乎无法索引。当ACCESS里数据过万后，明显可以感觉到速度变慢，过2万条数据后，慢的可以跟蜗牛相提并论了。但是由于某人灵光突现，想到了一个解决ACCESS数据库承载问题的方案，那个某人就是偶啦……最喜欢搞歪门邪道地偶（另有小偷程序生成器）。
这个解决方案就是“ACCESS复合承载”（本人原创的词，实在找不到合适的描述），简单说就是将原来一个数据库剥离为多个，成为一个主数据库带多个辅数据库。拿我已经实现的开良小说系统来说，小说信息都存储在主数据库内，用于列表检索，小说章节存在辅数据库内，每本小说独立占一个数据库。可能这样你看着有点模糊，我们来下数据对比，一个小说站，算5个分类，每个分类400部小说，每部小说300章节（其实很多小说都不止300章节），那么数据量为5×400×300=60万条数据，这还只是章节数据，其他的还有书目、用户、评论等等数据，这样大的数据量，即使是MYSQL或者MSSQL也要好好规划。但是，采用ACCESS复合承载以后，就会变成1个书目数据库加2000个章节数据库，每个章节数据库里有300条数据，从只有300条记录的ACCESS库里读东西，速度我想大家都能理解，即使是动态读取也绝对不慢。那么，这里又涉及到一个关键的问题，如何将主库与辅库连起来，这其实很简单，我在小说系统里用的是用书目的ID来命名数据库，将数据库打开与关闭做成一个函数，要什么小说的章节就直接打开这个小说的数据库就OK了。
谈完方法，我们来谈谈优缺点。优点很显著，其一，可以做以前很多做不了的事情，ACCESS库原来根本做不了小说系统，现在可以做了，而且还可以做的很大。其二，ACCESS是以独立文件形式存在的，可以很方便的实现复合承载，其他数据库做不到这么方便。其三，一个数据库仅几百条数据，读取效率绝不在其他数据库之下（例如MYSQL 、MSSQL）。其四，ACCESS一般的空间都支持，通用性很高，而且大小不限哦。
接着来看缺点，第一，对程序员的要求也要高一些，数据库的规划必须要完善，数据库多了后要用执行SQL语句来修改格式，不懂编程语言的人是搞不了的。第二，数据检索始终还是有缺陷（对于一些文章系统来说，小说系统压根没这缺陷），无法进行全库检索，只能单库检索。
昨天晚上到今天早上一共花了8个小时，才把系统粗略做出来，睡眠不足，脑子都有点混，写的乱七八糟（其实偶本来就不会写，找个理由挡下。。），希望各位大大不要笑偶。。如果你也有邪门歪道的想法，也可以与我联系哦。