今天比较特别面试的是数据库的设计。面试我的人和我年龄一样，说实话数据库设计方面我不在行，但是他发布的职位上面只写了网站维护，数据库维护等字样，比较模糊，所以我这边直接的投递，有了面试机会。
面试开始那位仁兄直接的说了他所面临的问题，公司数据库数据到达百万级别，以后可能会到达千万，需要一个好的设计人员对数据库进行优化设计，这里指的是不光设计符合功能需求，更加要符合性能需求，就是说数据库设计上面需要兼顾到效率。
他给我出了一道题目， 一个信息表，一个类别表。类别表中的类别成树形结构的，这个树可能会非常深，就是说类别会很多。信息表中有所有类别的信息。现在需要设计下类别表和信息表，使得信息表和类别表在查询的效率能够承受千万级别的数据。
我用比较正常的思维去设计，类别表中有id，name，parentid。这时候他说如果以这种方式设计那在查询的时候不断的用嵌套的方式查询效率不行，他让我想下，我说可以将类别表分为几个小表和信息表联结查询，他说这个方法不行，我想了会没有想到，他就直接给我讲了他的方法，但是他说这个方法百万级可以，但是千万级的不行，他的方法也简单，设第一个大类为1，第一个大类下面的一个类别为2，那么在类别表中存储
id name category_id
1 第一大类下的一个小类 '1,2'
那么在查询的时候 select * from category where category_id like '1%';
只要like后面不要写'%1%'。 1的前面不要写%，在效率上面还是能够承受的，这个和索引类似。
他也指出虽然这种方法提高了一定效率但是每次有一个新类别加入时候总要再次遍历整个树形类别，在适合的位置插入，这样子的方式给维护类别表格带来一定麻烦。
那位仁兄还问题程序上分页的问题，我说比较通常的方式是将在查询数据库的时候截取记录上的某一页记录显示。
但是他说这样子的方式对他的大量数据处理没有用处。
以上就是那位仁兄的思路。我这边没有这方面经验只能对这位仁兄说抱歉了，同时也非常感谢他提出的问题和答案。
回来的路上一直在想这个问题，虽然他这样子的方式可以回避掉嵌套查询，但是我想到这样子的存储方式给增大了类别表格的记录数量和更新删除的难度，同时如果类别和信息多的话仍然会有查询效率的问题产生。
在网上查询这种大量数据的数据库设计方法，大部分方法都是分区表或者索引。
1.按照月来分，每个月让系统自动建一张表，然后把这个月的数据放在这个表里面2.就是用一个备份的数据服务器，把每个月的数据都导出到那个备份服务器上去，在备份服务器上面数据的存储不按月来分，按照年来分，每年建一张新表，做报表的时候，就到备份服务器上面操作3.就是对这几张表用对象数据库，来存储一个月的数据，这数据是在内存的，操作起来，比操作关系数据库快，前段时间的数据还是放在关系数据库里面，这样就可以不用数据备份服务器了4 .定时清理数据,可以考虑用触发器或者带存储过程的作业来实现;5.是考虑数据的转换与提取,定期用程序或用事务复制导入原始/汇总数据,把数据复制到一台专门做统计的服务器上,专门做查询所用;查询的时候做相应的优化,例如索引,视图等这样查询的时候压力就会小很多;同时考虑负载平衡,在空隙时利用其cpu和内存6 . 各业务系统和外部数据源传送的数据为维系挽留系统输入，这些数据分别经过数据格式检查；源数据清洗抽取转换、装载数据到收集层；对收集层中数 据抽取、转换、装载到数据仓库；数据仓库中数据进行抽取、转换并结合模型算法库中的算法生成维系结果集以供输出；同时通过数据仓库接口，可将数据提供给应 用系统的本地化查询使用。
转自：http://www.cnblogs.com/luluping/archive/2009/12/12/1622566.html
大数据量的数据库设计准则： 1、分区 （list、range、hash）。 2、根据where条件来决定分区策略。
转自：www.itpub.net
个人认为： 1、既然数据量达到5000万，是否可以考虑根据种子进行分类，把不同类的种子对应的记录存放在不同的表中，或者每10个种子对应的数据一起放入一张表 中； 2、在种子信息表中，增加一个字段，该字段用于记录该种子的产生的记录是存放在哪张表里面。 不知道这样是否有用，楼下的继续。。
转自：http://www.soidc.net/discuss/30/040101/00/487088_1.html
我对这方面没有太多的涉及，所以对那位仁兄遇到的问题无法做出确切的回答。现在做下事后诸葛亮，我认为内存既然有限制，那么如果一个数据库(不分区)的数据量到达一定程度下，对数据库的数据查询的效率一定有影响，不管设计的如何巧妙。所以分区策略，以硬盘空间来换效率是比较可行方法。