今天比較特別面試的是數據庫的設計。面試我的人和我年齡一樣，說實話數據庫設計方面我不在行，但是他發布的職位上面只寫了網站維護，數據庫維護等字樣，比較模糊，所以我這邊直接的投遞，有了面試機會。
面試開始那位仁兄直接的說了他所面臨的問題，公司數據庫數據到達百萬級別，以后可能會到達千萬，需要一個好的設計人員對數據庫進行優化設計，這里指的是不光設計符合功能需求，更加要符合性能需求，就是說數據庫設計上面需要兼顧到效率。
他給我出了一道題目， 一個信息表，一個類別表。類別表中的類別成樹形結構的，這個樹可能會非常深，就是說類別會很多。信息表中有所有類別的信息。現在需要設計下類別表和信息表，使得信息表和類別表在查詢的效率能夠承受千萬級別的數據。
我用比較正常的思維去設計，類別表中有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
我對這方面沒有太多的涉及，所以對那位仁兄遇到的問題無法做出確切的回答。現在做下事后諸葛亮，我認為內存既然有限制，那么如果一個數據庫(不分區)的數據量到達一定程度下，對數據庫的數據查詢的效率一定有影響，不管設計的如何巧妙。所以分區策略，以硬盤空間來換效率是比較可行方法。