今天比較特別面試的是數(shù)據(jù)庫的設(shè)計。面試我的人和我年齡一樣，說實話數(shù)據(jù)庫設(shè)計方面我不在行，但是他發(fā)布的職位上面只寫了網(wǎng)站維護(hù)，數(shù)據(jù)庫維護(hù)等字樣，比較模糊，所以我這邊直接的投遞，有了面試機(jī)會。
面試開始那位仁兄直接的說了他所面臨的問題，公司數(shù)據(jù)庫數(shù)據(jù)到達(dá)百萬級別，以后可能會到達(dá)千萬，需要一個好的設(shè)計人員對數(shù)據(jù)庫進(jìn)行優(yōu)化設(shè)計，這里指的是不光設(shè)計符合功能需求，更加要符合性能需求，就是說數(shù)據(jù)庫設(shè)計上面需要兼顧到效率。
他給我出了一道題目， 一個信息表，一個類別表。類別表中的類別成樹形結(jié)構(gòu)的，這個樹可能會非常深，就是說類別會很多。信息表中有所有類別的信息。現(xiàn)在需要設(shè)計下類別表和信息表，使得信息表和類別表在查詢的效率能夠承受千萬級別的數(shù)據(jù)。
我用比較正常的思維去設(shè)計，類別表中有id，name，parentid。這時候他說如果以這種方式設(shè)計那在查詢的時候不斷的用嵌套的方式查詢效率不行，他讓我想下，我說可以將類別表分為幾個小表和信息表聯(lián)結(jié)查詢，他說這個方法不行，我想了會沒有想到，他就直接給我講了他的方法，但是他說這個方法百萬級可以，但是千萬級的不行，他的方法也簡單，設(shè)第一個大類為1，第一個大類下面的一個類別為2，那么在類別表中存儲
id name category_id
1 第一大類下的一個小類 '1,2'
那么在查詢的時候 select * from category where category_id like '1%';
只要like后面不要寫'%1%'。 1的前面不要寫%，在效率上面還是能夠承受的，這個和索引類似。
他也指出雖然這種方法提高了一定效率但是每次有一個新類別加入時候總要再次遍歷整個樹形類別，在適合的位置插入，這樣子的方式給維護(hù)類別表格帶來一定麻煩。
那位仁兄還問題程序上分頁的問題，我說比較通常的方式是將在查詢數(shù)據(jù)庫的時候截取記錄上的某一頁記錄顯示。
但是他說這樣子的方式對他的大量數(shù)據(jù)處理沒有用處。
以上就是那位仁兄的思路。我這邊沒有這方面經(jīng)驗只能對這位仁兄說抱歉了，同時也非常感謝他提出的問題和答案。
回來的路上一直在想這個問題，雖然他這樣子的方式可以回避掉嵌套查詢，但是我想到這樣子的存儲方式給增大了類別表格的記錄數(shù)量和更新刪除的難度，同時如果類別和信息多的話仍然會有查詢效率的問題產(chǎn)生。
在網(wǎng)上查詢這種大量數(shù)據(jù)的數(shù)據(jù)庫設(shè)計方法，大部分方法都是分區(qū)表或者索引。
1.按照月來分，每個月讓系統(tǒng)自動建一張表，然后把這個月的數(shù)據(jù)放在這個表里面2.就是用一個備份的數(shù)據(jù)服務(wù)器，把每個月的數(shù)據(jù)都導(dǎo)出到那個備份服務(wù)器上去，在備份服務(wù)器上面數(shù)據(jù)的存儲不按月來分，按照年來分，每年建一張新表，做報表的時候，就到備份服務(wù)器上面操作3.就是對這幾張表用對象數(shù)據(jù)庫，來存儲一個月的數(shù)據(jù)，這數(shù)據(jù)是在內(nèi)存的，操作起來，比操作關(guān)系數(shù)據(jù)庫快，前段時間的數(shù)據(jù)還是放在關(guān)系數(shù)據(jù)庫里面，這樣就可以不用數(shù)據(jù)備份服務(wù)器了4 .定時清理數(shù)據(jù),可以考慮用觸發(fā)器或者帶存儲過程的作業(yè)來實現(xiàn);5.是考慮數(shù)據(jù)的轉(zhuǎn)換與提取,定期用程序或用事務(wù)復(fù)制導(dǎo)入原始/匯總數(shù)據(jù),把數(shù)據(jù)復(fù)制到一臺專門做統(tǒng)計的服務(wù)器上,專門做查詢所用;查詢的時候做相應(yīng)的優(yōu)化,例如索引,視圖等這樣查詢的時候壓力就會小很多;同時考慮負(fù)載平衡,在空隙時利用其cpu和內(nèi)存6 . 各業(yè)務(wù)系統(tǒng)和外部數(shù)據(jù)源傳送的數(shù)據(jù)為維系挽留系統(tǒng)輸入，這些數(shù)據(jù)分別經(jīng)過數(shù)據(jù)格式檢查；源數(shù)據(jù)清洗抽取轉(zhuǎn)換、裝載數(shù)據(jù)到收集層；對收集層中數(shù) 據(jù)抽取、轉(zhuǎn)換、裝載到數(shù)據(jù)倉庫；數(shù)據(jù)倉庫中數(shù)據(jù)進(jìn)行抽取、轉(zhuǎn)換并結(jié)合模型算法庫中的算法生成維系結(jié)果集以供輸出；同時通過數(shù)據(jù)倉庫接口，可將數(shù)據(jù)提供給應(yīng) 用系統(tǒng)的本地化查詢使用。
轉(zhuǎn)自：http://www.cnblogs.com/luluping/archive/2009/12/12/1622566.html
大數(shù)據(jù)量的數(shù)據(jù)庫設(shè)計準(zhǔn)則： 1、分區(qū) （list、range、hash）。 2、根據(jù)where條件來決定分區(qū)策略。
轉(zhuǎn)自：www.itpub.net
個人認(rèn)為： 1、既然數(shù)據(jù)量達(dá)到5000萬，是否可以考慮根據(jù)種子進(jìn)行分類，把不同類的種子對應(yīng)的記錄存放在不同的表中，或者每10個種子對應(yīng)的數(shù)據(jù)一起放入一張表 中； 2、在種子信息表中，增加一個字段，該字段用于記錄該種子的產(chǎn)生的記錄是存放在哪張表里面。 不知道這樣是否有用，樓下的繼續(xù)。。
轉(zhuǎn)自：http://www.soidc.net/discuss/30/040101/00/487088_1.html
我對這方面沒有太多的涉及，所以對那位仁兄遇到的問題無法做出確切的回答。現(xiàn)在做下事后諸葛亮，我認(rèn)為內(nèi)存既然有限制，那么如果一個數(shù)據(jù)庫(不分區(qū))的數(shù)據(jù)量到達(dá)一定程度下，對數(shù)據(jù)庫的數(shù)據(jù)查詢的效率一定有影響，不管設(shè)計的如何巧妙。所以分區(qū)策略，以硬盤空間來換效率是比較可行方法。