PostgreSQL 簡繁用語 對照

英文的中譯，一向是個問題，簡繁體習慣用語的不一致，在問題上加上了更多的問題。

記得在PostgreSQL 7.X的版本，我做了一個繁體中文的手冊，這個版本，後來被改變為簡體版的初始版本，現在看起來，很多用語仍遵循我當初訂下的用詞，看起來實在很有成就感。

如view，一般譯為「檢視」，我則譯為「視圖」。Oracle的譯詞則為視觀表，現在看起來，視觀表似乎是比較好的譯法。

如regression test, 當初找不到譯詞，我就譯為「迴歸測試」，隱諭它像統計迴歸一樣，是一個測試統計的功能。轉簡體時，字元對映出了一些狀況，變成「回歸測試」了。

再如Write-Ahead Logging (WAL)，譯為「預寫式日誌」，為了怕譯得不好，特地將英文原詞附於譯詞之後，到目前看起來，是已經被普遍接受了。在這種狀況下，英文原詞可以移掉了，還留在內容表中，實在是不需要了。

為此，我手上保留了一份　PostgreSQL 簡繁用語 對照表，有需要的同好，再與我聯絡吧。

Client Encoding, PostgreSQL開放性的亮點

client encoding 這個東西，實在是PostgreSQL開放性的一個亮點。

簡單講，資料庫與客戶端的文字編碼，不見得需要一致。相信開發者都曾經碰過，需要同時服務中國與台灣使用者的狀況，中國使用者輸入的是GB編碼的簡體，台灣使用者輸入的是BIG5編碼的繁體中文，兩者的資料都存入UTF8編碼的資料庫中。

在這種狀況下，開發Web版的程式還算簡單，但如果是開發AP版的程式，那就真得有點欲哭無淚了。

在PostgreSQL的使用手冊，第二十二章中有提到Localization，它提出了資料庫伺服端和程式客戶端文字編碼的說明，並支援一些常見的搭配組合。

使用上
1 .使用psql
以下列形式的指令，進行客戶端編碼設定

\encoding BIG5

2. 在程式中，下SQL指令換編碼

SET CLIENT_ENCODING TO 'value';

顯示現在的客戶端文字編碼

SHOW client_encoding;

取得系統預設的文字編碼

RESET client_encoding;

以我個人的使用經驗來看，資料庫的編碼最好使用UTF8，之前使用的EUC_TW, BIG5, MULE_INTERNAL等，現在完全可以放棄了。

用PSQL匯入固定長度的資料 Fixed Width Data

Leo Hsu and Regina Obe在其網誌上寫到了這個方法，心喜之，分享於同好。

有人覺得PSQL這種終端機形式的客戶端程式過時了，但是事實告訴我，在某些狀況下，特別是追求效能的狀況下，PSQL反而會比PgAdmin 這種GUI的客戶端有用，而且是有用多了，特別是在自動化作業中，如每天自動將資料匯入匯出的應用上，不用PSQL，簡直是無法想像。用pgAdmin去點選啟動，別鬧了。因此，適度的掌握PSQL是必需的。

如果和一些老系統打過交道，通常都會發現，接收的資料，通常都會是用長度來識別。傳送一個文字檔案過來，告訴你第一到第二字元是什麼資料，第三到第五字元是什麼資料，資料長度不足會補空格，諸如此類。

問題是什麼？問題在於，我們要轉入我們的資料庫時，要依長度先進行切割，切割後要把空格都刪掉，這是一件麻煩事，常要動用試算表軟體來支援處理。

這個方法的精神很簡單，其步驟約略如下：

1. 在psql中，將文字檔資料利用\copy指令，存入暫存的資料表places_staging
要注意，執行前先設定好資料的編碼方式，台灣的繁體中文，可能要指定為BIG5或UTF-8

set client_encoding = 'latin1';
\copy places_staging FROM C:/censusdata/places2k.txt DELIMITER AS '|'

2. 建立真正存資料的資料表places

CREATE TABLE places(
    usps char(2) NOT NULL,
    fips char(2) NOT NULL, 
    fips_code char(5),
    loc_name varchar(64)
);

3. 利用substring 搭配trim函式，使用SQL將資料轉入places 

INSERT INTO places(usps, fips, fips_code, loc_name)
    SELECT substring(data,1,2) As usps, 
           substring(data,3,2) As fips, 
           substring(data,3,5) As fips_code,
      trim(substring(data, 10,64)) As loc_name
    FROM places_staging;


掌握住精神，在其它的資料庫這種作法都可以使用，是非常有用的技巧，值得學習。

Materialized views 具現視觀表

最近在PostgreSQL主站上，看到Robert Hass談到Robert Hass談到Materialized views，這實在是一個很有趣的題目。


首先，我先解釋一下，什麼是具現視觀表 Materialized views，由原文來看實在很難了解它是什麼東東，不過如果對開發過資料倉儲Data WareHouse的人來說，具現視觀表就十分熟悉了。


舉個例子來說，如果我們手上有某店舖每天的各種商品的銷售營業額資料，如果我們現在希望有該店舖每周、每月、每季、每年的銷售營業額資料，那該怎麼辦？


－－－＋－－－－－－－－＋－－－－－－－－＋－－－－－－－－
ＰＫ　　營業日　　　　　　商品種類　　　　　日銷售額
－－－＋－－－－－－－－＋－－－－－－－－＋－－－－－－－－
１　　　2010-01-01 Ａ　　　　　　　 100
２　　　2010-01-01 B　　　　　　　　200
３　　　2010-01-02 Ａ　　　　　　　 121
４　　　2010-01-02 B　　　　　　　　210　

最直接的想法就是，我就根據這張表，搭配另一張時間的資料表，

－－－＋－－－－－＋－－－－－－－－＋－－－－－－－－＋
ＰＫ　 營業日　　week of year        month of year

－－－＋－－－－－＋－－－－－－－－＋－－－－－－－－＋
　１　　2010-01-01 W1 1
為每周、每月、每季、每年，各做一個視觀表view出來就可以了嘛

在資料倉儲的應用中，這些視觀表會被非常頻繁地查詢，因此，最合理的做法是，把視觀表的結果，以資料表的形式，直接放在資料庫中，不要每次查詢時，就去執行一次視觀表的查詢指令，動態產生視觀表。查詢這種視觀表，就直接查詢已統計完成的資料表即可。


因此，這種被產生出來的視觀表，它就和傳統的視觀表有了差別，它不是動態產生的，它是基礎資料統計的結果，是被具體實現後的視觀表，因此，我稱它叫具現視觀表。


我們可以想見，具現視觀表的實作，會有許多的問題，比如說，如果基礎資料有變動，那依據它產生的一系列具現視觀表，就需要全部重新更新，效能的問題要如何克服？


我們可以說，沒有具現視觀表，PostgreSQL在資料倉儲的應用上，就會受到了阻礙，因此在Peter Eisentraut的調查中，具現視觀表，就變成PostgreSQL 9中，大家最想要的功能。

pgAdmin III , PostgreSQL的GUI客戶端程式

時間很快，進入了２０１０年，我們使用資料庫的時候，當然是希望能夠有一個便利的GUI界面，讓我們以終端機模式作業，當然不是不可以，但是，誰會自己去找虐呀，有方便的方式，當然是要加以使用的。

pgAdmin III 就是這樣的東西，當你安裝視窗版本的PostgreSQL時，它是預設安裝的軟體，我們只要使用它，就可以便利地進行資料庫的操作。

當然，這不是說文字界面的東西就不需要學了，畢竟SQL語言還是以指令的形式在操作的，可不能變成傻瓜，連SQL都不學了，那真真叫丟了根本。

pgAdmin 連接資料庫

當pgAdmin連上資料庫後，可以在左方看到資料庫中所有的表格。在PostgreSQL的觀念中，預設使用名為public的架構綱要schema，點開後，就可以看到所有的資料表格。

讓PostgreSQL變成網路資料庫

讓PostgreSQL變成網路資料庫

PostgreSQL安裝時，預設是做為單機資料庫存在的。也就是說，它只接來自本機的資料庫操作動作，如果你開發的是單機程式，那當然是運作良好。

如果你開發的程式，需要執行在其它台機器時，這個預設的設定，就造成了問題。它不接受來自其它主機的資料庫操作。這時候，你就需要對它做進一步的修改。

PostgreSQL做為網路資料庫

PostgreSQL安裝的時候，會要求指定資料庫資料放置的目錄，如果你使用的是視窗版本的PostgreSQL，那它的目錄應該會是C:\Program Files\PostgreSQL\8.4\data


1. 設定接受外部主機的連線
在這個目錄中，有一個postgresql.conf的檔案，設定PostgreSQL是否接受外界的連線
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
# change listen_address to '*', ie., accept db operation request from all hosts
#listen_address=’localhost’
listen_address=’*’
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－

2.設定外部連線的認證方式
另外，還有一個pg_hba.conf的檔案，負責設定外界連線的認證方式

－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－

# add auth from intranet, accept connection with db username and password

host all all 192.168.1.0/24 password

－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－

這個設定的意思是，接受所有192.168.1.XXX形式位址主機發出的資料庫連線，24是網路遮罩255.255.255.0的意思，連線的主機，必需送正確的資料庫使用者名稱與密碼，才能使用資料庫主機的服務。

為什麼要用PostgreSQL ?

這是一個最直接的問題, 為什麼我(你) 要用PostgreSQL ?

當我自己問我自己這個問題的時候, 我的答案大概如下

1. 我不想重覆又重覆地浪費自己的生命.
身為一個資訊時代的技術人員，我需要一個穩定的平台。我不想跟隨IBM, Oracle, MS的步調每兩年就來次大昇級，原本花了不少時間掌握的技能，需要再次重新學習。有時候還會來個全面大昇級，學過的全都不能用了。

2. 我需要可以商業化的資料庫核心
當我要販售我開發的系統時，我希望我使用的資料庫可以一併出貨給我的客人，客人不需要再向IBM, Oracle, MS等資料庫廠商付一筆授權費。而這授權費通常不怎麼便宜。PostgreSQL採用BSD的版權，我和客人不需要付授權費。

3. 我需要一個強大的資料庫引擎
當我開發我的程式時，我需要交易Transaction, 觸發Trigger等強力的機制，支援我的程式。沒有這些功能，可以想見，我的開發工作會難上不少。

4.我需要一個取得容易，價格低廉的資料庫引擎
最好網路可以下載，價格又很低廉。這樣我可以很容易取得。PostgreSQL可以在網路上下載到，免費，這真是太好了。

為了以上的這些因素，我決定使用PostgreSQL做為我開發系統的核心，但是我也有如下的疑慮。

1. 萬一資料庫掛掉了，誰來救我？
天有不測風雲，誰也不能保證系統一定沒問題，就算我初一十五都有拜乖乖，如果硬體出問題，或是資料庫軟體出狀況，資料庫掛掉時，誰能幫我？

後來我轉念一想，之前服務的公司，花了那麼多授權費，結果出狀況時，沒有一家派技術人員出來，還叫我去看授權的條文，每一家都不負責幫我把資料救回來，還是要靠自己用備份的資料做回復，讓我大嘆，那麼多的錢都花到狗身上去了，這些錢留下來，我都可以再建一部備份主機了。

反正都是自己要解決，我還是備份自動化，平常做做災難回復演練還比較有用。

2. PostgreSQL那裡可以找到學習的資料？
雖然我的英文不怎樣？但是看看技術文件是夠用了，市面上也有幾本中文的書，有問題上郵件列表發問題，也是可以得到解答。

對於一些免費的資料庫核心，像是IBM, Oracle, MS釋出的免費版本資料庫，我其實也不會刻意不用，但是我還是以PostgreSQL做為開發的主要測試對象，如果客人有要求，我才會去做移植的測試，畢竟付錢的是老大，客人願意付錢，我怎麼都可以配合的。

如果你像我一樣，是IT的從業人員，或者你是在學的學生，教學的老師，或者你是要賺錢的老板，我都建議您考慮PostgreSQL。