最近一段時間做的專案DB用的都是postgresql， 相對於oracle來說已經夠悲催了，更悲催的是使用了postgresql的分割槽表，哎呀媽呀，所以說老話說的好：沒有最悲催只有更悲催！好了，廢話不說，言歸正傳。

       Postgresql的分割槽表使用確實很麻煩。它沒有像oracle一樣將大量的細節遮蔽，對使用者透明。Postgrsql的分割槽表暴露了大量的技術細節，這些細節都需要程式設計師進行維護，但正因為這一點，我們可以瞭解到分割槽表的實現細節，也算有點補償。

       Postgresql 分割槽表是通過一個概念： 繼承 來實現的。以一個employer的表為例吧，將它做成分割槽表（以入職時間分割槽）。 首先需要一個父表： employer ，若干字表： employer_2010, employer_2011. 這兩個字表是繼承自父表的使用INHERITS關鍵字。所有欄位都跟父表相同。 從這一點很棒但是悲催的是父表的約束是無法被繼承的，這是什麼意思呢？ 我很悲催的告訴你： 所有字表的PK和index都要自己建立，明白了嗎，自己建立！！，有多少分割槽就要建立多少次，悲催啊。好吧，這些我忍了，到了這一步細心的人可能要發問了，那記錄的插入呢，如何自動選擇正確的字表呢？比如說入職時間是2011年的記錄要進入employer _2011字表。 我再次悲催的告訴你們，這個也好自己handle的。這個在postgresql中叫做一條RULE，在這裡類似trigger，就是說一條記錄來了我先check下它的入職時間這個欄位，發現時2011年的那就插入字表employer _2011。這個是要程式設計師寫的大哥啊。一個RULE類似於下面的程式碼：

CREATE RULE ruleName AS
            ON INSERT TO employer WHERE
            ( date_trunc( ''year'', time_stamp) = "2011")
            DO INSTEAD
            INSERT INTO employer_2011 VALUES (columnValue1,columnValue2...)

可怕吧！

       另外要說明的是分割槽時不能自己建立的，如刀2012年了，應該有一個employer_2012的字表，否則資料是差不進去的。這個貌似oracle也不能cover，但是在postgresql中藥恐怖的多，想想吧，要自動增減分割槽你需要完成多少工作，看看這件提到的步驟吧，悲催的我居然還實現了這個功能！

       最後說說最近遇到的一個問題吧：我的程式alter了一個分割槽表，增加了一個欄位，但是新增加的那個column一直不能插進去值，也不報錯，但就是沒有值。很叫人惱火，最後終於發現是RULE沒有改，請注意上面標紅的程式碼，VALUES後面的括號中是要列出所有的欄位的，當我alert 表增加新的欄位後，這個rule並沒有自動的也新增新增的欄位，就導致新加欄位value進不去，牛逼吧，啥也不說了。 最後奉勸大家使用postgreql分割槽表須謹慎慎啊！！好了睡覺去啦！