PostgreSQL 變化多端的使者 你猜不透的 hstore
- 2020 年 3 月 10 日
- 筆記
PostgreSQL 讓人著迷的地方，不在於他比某些資料庫的流行，也不在於比某些資料庫的高「貴」， 更不如某些資料庫的「簡單」。Postgresql 讓人無法自拔的是他的」多端變化」， 用開發的角度來說，叫多態性。
PG本身支援著太多的數據的類型充分體現了他的多態性，其中hstore數據類型，這是一種以鍵值為目的的數據存儲和提取的方式。在非結構化，半結構化數據橫行的今天，除了MONGODB 讓人「羨慕嫉妒恨」，以外能想到的好像也只有PG了，在支援json, josnb下的PG另類hstore數據類型是否多餘，還是對多種應用提供了更良好的支援，的需要去check一下。
先建立一個POSTGRESQL 的hstore類型，是騾子，還是千里馬，的出來溜溜。
我們插入一條數據
insert into hstore_test (id,name,history) values (1,'postgresql','from => "IBM_Research",origination => "inges",time => "1970"')
可以看到與JSON 格式對比，hstore 在處理比較隨意的數據上，也是有點意思。
SELECT name, history->'from' as history FROM hstore_test WHERE history->'origination' = 'inges';
想必做到這裡，如果是開發人員，會覺得有點意思，並且是騾子，是千里馬，反正不是「驢」。從開發人員的角度，這樣處理數據的方式，鍵值不要太隨便。
說道這時候，估計馬上會有人跳出來，這不科學呀，這怎麼加索引，這怎麼在大數據量下查詢，這就是「兒戲」。
普及一下POSTGERSQL 的「科學」， 因為POSTGRESQL 的索引類型從來不貧瘠， GIN GIST 索引類型，妥妥的支援這樣變態的類型，一個能讓%like% ,都能走索引，百萬數據毫秒出結果的資料庫，怕過誰。
那具體在資料庫的維度上，問題的關注點可能會轉移到，是否有什麼案例可以說明這個資料庫的欄位類型（或許叫欄位類型表達不了，這個類型的內涵），在實際當中的意義。
首先有需要聲明
這個類型不是要代替或者與JSON 類型進行競爭，換句話hstore 類型是JSON,JSONB 的一種有益的補充，當你在產生某些數據的情況下，無法對其進行合理的二維表格以及關係的描述，或者你的數據不存在嵌套的關係，或需要處理複雜的嵌套關係。在這樣的情況下還有一些，非傳統的二維表格的需求。hstore 其實是一個很好的補充和支援。
那下面就舉一個例子：
例如我們有一個在線介紹家用汽車的網站，我們其中的每種汽車，其實都可能有很多熟悉
我們一邊建表，一邊來舉這個例子
create table car_info(
id serial primary key,
productor varchar(20),
car_name varchar(50),
product_time timestamp,
car_type smallint,
tag hstore
);
這裡hstore存儲的數據其實是可以通過json + mongodb的方式來進行數據存儲，毋庸置疑的是MONGODB 在JSON處理上的能力，以及便捷性，尤其對待要求數據量巨大，並且對處理的速度要求很高的情況下，MONGODB可以說是JSON裡面的唯一選項。
那這裡POSTGRESQL的 hstore 扮演了一個什麼樣的角色
1 在傳統資料庫表裡面會涉及到一些，非結構化的數據
2 在某些需求不明確，但需要為了爭取市場，快速上線（比如這個tag ，其實可能需求方面會一直變化，某一種車的標籤會隨著市場，銷售情況，以及車商，等等諸多原因進行變化，而使用其他資料庫的任何欄位類型來處理這樣的情況要不就是不合適，要不就是太麻煩）
3 所以postgresql 的 hstore 是在數據量較少，介於想使用MONGODB，但又沒有特別大的需求和數據量的情況下，需要靈活應對項目中的需求變動頻繁時的一個好的技術方法，來規避後期的頻繁改動表結構，欄位長度，以及一些，讓需求，開發，運維都頭痛的後續工作。
所以POSTGRESQL 的 hstore 是一個在傳統資料庫中，非結構化，半結構化的良好的解決方案。
我們還可以在這個欄位上加索引，並且方便的更新，或刪除數據，這些功能在其他的資料庫上是很難相信能夠做到的。
當然這個類型還有很多的功能，感興趣的可以去check 一下，也許會在某些項目上幫到你，快速的滿足需求，並且省時省力, 借用我的前半生，賀函風格的一句話， 作為一個DB的工作者， 你的職責是服務於你的公司，提供專業的，更高效的資料庫去為企業服務，加速程式開發速度，降低開發中程式設計師遇到的困難，並解決他，哪種資料庫不是重點，重點是解決問題。
