本節書摘來自華章計算機《PostgreSQL服務器編程》一書中的第1章，第1.8節,作者：（美）Hannu Krosing, Jim Mlodgenski, Kirk Roybal　著，更多章節內容可以訪問云棲社區“華章計算機”公眾號查看。

1.8　程序設計最佳實踐

開發應用程序軟件是復雜的。一些有助于管理復雜性的方法非常流行，以至于它們被賦予容易記憶的首字母縮略詞。接下來，我們就會介紹一些這樣的規則，并介紹如何在服務器程序設計時更好地遵守這些規則。
1.8.1　KISS——盡量簡單（keep it simple stupid）
成功的程序設計的一個重要技術就是編寫簡單的代碼。也就是，你編寫的代碼3年以后仍然可以很容易理解，并且其他人也可以理解。這種方式并不一定總是行得通，但是盡可能用最簡單的方法編寫代碼總是有意義的。由于各種原因，比如速度、代碼壓縮或者炫耀你有多聰明等，你都有可能再次編寫這些代碼的某些部分。同時，總是以簡單的方式編寫代碼，能讓你絕對相信這些代碼就是你想要的。這樣做不僅讓你的編程工作更加快捷，同時當你想嘗試更多高級的方法去完成同樣的事情時，你也可以有對比的東西。
并且記住，調試比編寫代碼更加困難。所以如果你把代碼寫得非常復雜，在調試代碼時你會非常頭疼。
編寫一個返回函數的集合通常比一個復雜的查詢更容易。是的，這樣的函數可能比通過單個復雜查詢語句實現的方式運行更慢，原因是對于作為函數編寫的代碼，優化器的作用很有限，但是這樣的速度應該足以滿足你的需求。如果你需要更快的速度，你可以一點點重構這段代碼，將部分函數加入到更大的查詢中，這樣優化器就可以獲取更好的查詢計劃，直到運行效率再次變得可以接受。
記住，在大多數情況下，你并不需要最快的代碼。對于你的客戶或者老板，最好的代碼是及時有效地完成工作。
1.8.2　DRY——不要寫重復的代碼（don’t repeat yourself）
這點可以理解為努力保證每個業務邏輯的代碼段都編寫一次，并且把完成任務的代碼放到正確的位置。
這樣做可能會有些難度，例如，你想對瀏覽器的Web表單做一些檢查，但是在數據庫里還會做一次最后的檢查。但是作為一個通用準則，它仍然是非常有效的。
服務器程序設計這時候就派上用場了。如果你的數據操作代碼位于貼近數據的數據庫內，所有用戶便可容易地訪問數據，這樣你就不需要管理一份相似的代碼，這些代碼可能是用一個C++Windows程序、兩個PHP網站和一個Python腳本的分支開發的，并用來完成每天的管理任務。如果它們中的任何一種方式需要對一個客戶表做些什么事情，它們僅僅需要調用：

這樣就搞定了！
1.8.3　YAGNI——你并不需要它（you ain’t gonna need it）
換句話說，不要做得比你確實需要的多。
你是否有種可怕的感覺你的客戶并沒有很好地注意到最終的數據庫是什么樣或數據庫可以做什么，那么你必須堅持在數據庫中所設計的一切是有益的。一個更好的辦法是完成最小的開發，來滿足當前的要求，但是在思路上要具有擴展性。當使用巨大的設想去實現一個大的產品要求時，很容易讓自己陷入困境。
如果你通過函數來組織對數據庫的訪問，就很可能對業務邏輯做更大的修改，而不需要涉及前端應用程序代碼。即使你已經5次改寫這個函數并且兩次改變過整個表結構，你的應用程序仍然只須執行SELECT * FROM do_this_thing_to_customers (arg1, arg2, arg3)。
1.8.4　SOA——服務導向架構（service-oriented architecture）
最初聽說SOA通常來自于企業軟件人員向你銷售一組復雜的SOAP服務。但是SOA的本質是把你的軟件平臺組織為一套服務，這樣客戶端和其他服務就可以調用并執行某些定義好的原子任務，例如：
檢查用戶的密碼與證書
給用戶呈現他喜歡的網站列表
向用戶售賣新的紅色小狗項圈（附贈紅色項圈小狗俱樂部的候補會員資格）
以上這些服務可以通過SOAP調用來實現，SOAP調用同時帶有相應的WSDL定義、包含servlet容器的Java服務器和復雜的管理框架。它們也可以是一系列PostgreSQL函數，這些函數帶有一組參數并返回一組值。如果參數和返回值比較復雜，它們可以作為XML或JSON來進行傳遞。但是通常情況下，一組簡單的標準PostgreSQL數據類型已經足夠使用。在第9章中，我們將學習如何讓這種基于PostgreSQL的SOA服務變得可以無限
擴展。
1.8.5　類型的擴展
前面闡述的一些技術同樣可用在其他的數據庫系統上，但是PostgreSQL的擴展性絕不只限于這些內容。在PostgreSQL中，可以使用任何一種較為流行的腳本語言來編寫用戶定義函數（UDF）。也可以定義自己的類型，不僅僅局限于附有額外約束的標準類型，還包括其他成熟的新類型。
例如，荷蘭的一家公司MGRID已經開發出衡量單位大小的數據類型，這樣你就可以將10km除以0.2小時，得到50km/h的結果。當然，也可以將同樣的結果轉換為米每秒或者任何其他表示速率的單位。當然，也可以把它當做c（光速）的一小部分。
此類功能同時需要類型本身和重載后的操作數，這樣如果你用距離除以時間，就可以知道結果是速率。你也需要用戶定義的轉換操作，它們是類型間自動或者手動調用的轉換函數。
MGRID開發這個數據類型是為了在醫療應用中推廣使用，因為醫療應用中的誤差成本實在過于昂貴——10ml和10cc就會是致命的區別。但是通過使用一個相似的系統就可以避免許多災難，比如使用了錯誤的單位就會輸出糟糕的計算結果。如果這個單位總是和量同時出現，那么這種錯誤出現的可能性就幾乎為零。當現有的指標已經無法解決你的問題時，如果你自己具備程序設計的能力，那么你也可以采用添加自定義索引的方法。PostgreSQL內核已經包括了一套數量非常可觀的索引類型，同時在內核之外，也已開發出了很多其他索引。
PostgreSQL官方收錄的最新索引方法是KNN（K鄰近域）——一個智能的索引，它可以返回K行值，而這些值可以按照離搜索目標距離大小進行排序。KNN的一個應用是模糊文本搜索，這里KNN用來對全文檢索的結果進行排序，排序的依據是它們對檢索項的匹配程度。在KNN之前，這種事是通過查詢所有行記錄來完成的，這個過程首先判斷哪行數據匹配得更好，然后通過距離函數來排序并返回K個最佳值作為最終的結果。
如果使用KNN索引，這個索引的訪問可以從按照期望的順序返回行記錄開始；所以這時候一個簡單的LIMIT K函數將為你返回K個最佳匹配項。
也可以用KNN來計算真實的距離，比如，可以回答這樣的問題“告訴我離中央火車站最近的10家比薩店”。
正如你所見，索引類型與它們指示的數據類型本身是相互分離的。又如，與整型數組的指標元素一樣的GIN（通用倒排索引）可以用在全文檢索中（同詞干算法、詞庫和其他文本處理方法一起使用）。

總結

以上是生活随笔為你收集整理的《PostgreSQL服务器编程》一一1.8　程序设计最佳实践的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。