ACCESS复合承载 性能超出MYSQL

核心提示：由于尽人皆知的缘由，ACCESS在大型站点利用中都靠不上边，主要题目就是数据量大了以后几近没法索引。当ACCESS里数据过万后，明显可以感觉到速度变慢，过2万条数据后，慢的可以跟蜗牛等量齐观了。但是由于某人灵光突现，想到了1个解决ACCESS数据库承载题目的方案，那个

由于尽人皆知的缘由，ACCESS在大型站点利用中都靠不上边，主要题目就是数据量大了以后几近没法索引。当ACCESS里数据过万后，明显可以感觉到速度变慢，过2万条数据后，慢的可以跟蜗牛等量齐观了。但是由于某人灵光突现，想到了1个解决ACCESS数据库承载题目的方案，那个某人就是偶啦……最喜欢弄旁门左道地偶（另有小偷程序天生器）。

这个解决方案就是“ACCESS复合承载”（本人原创的词，实在找不到合适的描写），简单说就是将原来1个数据库剥离为多个，成为1个主数据库带多个辅数据库。拿我已实现的开良小说系统来讲，小说信息都存储在主数据库内，用于列表检索，小说章节存在辅数据库内，每本小说独立占1个数据库。可能这样你看着有点模糊，我们来下数据对照，1个小说站，算5个分类，每个分类400部小说，每部小说300章节（实在很多小说都不止300章节），那末数据量为5×400×300=60万条数据，这还只是章节数据，其他的还有书目、用户、评论等等数据，这样大的数据量，即使是MYSQL或MSSQL也要好好计划。但是，采取ACCESS复合承载以后，就会变成1个书目数据库加2000个章节数据库，每个章节数据库里有300条数据，从只有300条记录的ACCESS库里读东西，速度我想大家都能理解，即使是动态读取也尽对不慢。那末，这里又触及到1个关键的题目，如何将主库与辅库连起来，这实在很简单，我在小说系统里用的是用书目的ID来命名数据库，将数据库打开与封闭做成1个函数，要甚么小说的章节就直接打开这个小说的数据库就OK了。

谈完方法，我们来谈谈优缺点。优点很明显，其1，可以做之前很多做不了的事情，ACCESS库原来根本做不了小说系统，现在可以做了，而且还可以做的很大。其2，ACCESS是以独立文件情势存在的，可以很方便的实现复合承载，其他数据库做不到这么方便。其3，1个数据库仅几百条数据，读取效率尽不在其他数据库之下（例如MYSQL 、MSSQL）。其4，ACCESS1般的空间都支持，通用性很高，而且大小不限哦。

接着来看缺点，第1，对程序员的要求也要高1些，数据库的计划必须要完善，数据库多了后要用履行SQL语句来修改格式，不懂编程语言的人是弄不了的。第2，数据检索始终还是有缺点（对1些文章系统来讲，小说系统压根没这缺点），没法进行全库检索，只能单库检索。

昨天晚上到今天早上1共花了8个小时，才把系统粗略做出来，睡眠不足，头脑都有点混，写的乱78糟（实在偶本来就不会写，找个理由挡下。。），希看各位大大不要笑偶。。假设你也有邪门歪道的想法，也能够与我联系哦。偶MAIL：klcode@qq.com，

http://www.fw8.net/
TAG:数据库,数据,题目,小说,章节

评论加载中... 内容： 评论者： 验证码：