狀態值在資料庫中的檢索

對於關係型資料庫而言，針對錶的檢索，一般來說，建立合適的索引就可以達到很好的檢索效果。（這裡不包含表設計的合理與否）
比如像狀態列這樣可選擇性非常低的值，該如何檢索？  其實這個已經不是關係型資料庫擅長的方面了。 但是如果出於曆史或者許多不可抗拒的原因，
我們還得在關係表中進行最佳化，該咋辦？   一般來說，就是建立靜態表。 但是靜態表也是多重多樣，該如何選擇？ 我下面列舉幾個簡單的例子，當然了，
由於個人的腦子尺度不夠大，有可能有些遺漏。


原始表。
20 完條記錄， 大概36MB大小。

t_girl>create table rank_status (id integer not null, i_status varchar(3) not null);

第一種呢，就是建立LIST 表，這種表，可以當做靜態表，也可以當做原始表來做相關的更新。
只有2條記錄，大概720KB大小。

t_girl>create table rank_status_extend (i_status varchar(3) not null, ids text);

我們可以對兩張表都做對應的更新操作。


插入一條記錄。

t_girl> insert into rank_status values (222222,'yes');Time: 4.397 mst_girl>update rank_status_extend set ids = ids ||','||'222222' where i_status = 'yes';Time: 43.725 ms

刪除一條記錄。

t_girl>delete from rank_status where i_status = 'yes' and id = 1;Time: 47.339 mst_girl>update rank_status_extend set ids = replace(ids,',1,',',') where i_status = 'yes';Time: 45.046 ms

更新一條記錄。

t_girl>update rank_status set id = 1000 where i_status = 'yes' and id = 20;Time: 65.834 mst_girl>update rank_status_extend set ids = replace(ids,',20,',',1000,') where i_status = 'yes';Time: 85.974 ms

我們看到，在對錶的寫操作中，第二張表會比第一張慢一點。


其實我們最主要的是關心讀操作。其實在讀上面還是很有優勢的。

t_girl>select count(*) as total from rank_status where i_status = 'yes';                               total ------- 99600(1 row)Time: 86.563 mst_girl>select length(ids) - length(replace(ids,',','')) + 1 as total from rank_status_extend where i_status = 'yes'; total ------- 99600(1 row)Time: 35.762 mst_girl>select string_agg(id::text,','),i_status from rank_status group by i_status;Time: 113.393 mst_girl>select ids from rank_status_extend where i_status = 'yes';Time: 2.447 ms

接下來第二種呢，就是分別建立兩張表, 但是這兩張表呢，少了存放狀態值的欄位，所以在尺寸上小了很多。

t_girl>create table rank_status_yes (id int not null); 3552 kBt_girl>create table rank_status_no(id int not null); 3584 kB

當然這張表的檢索肯定比原始表來的快，這裡，我就不示範了。


第三種呢，就是建立一張物化視圖，

t_girl>create materialized view mv_rank_status_yes as select * from rank_status where i_status = 'yes';

這種其實和第二種表很類似。只不過不同的是第二種表的維護需要人工來做，而這個視圖系統可以維護。