我應該在更新的數據模型中使用hstore嗎？

在我的遺留數據庫（Postgres 9.1）中，我有幾個包含各種文檔的表格（假設它們是'父'表）。此外，存在與這些文件的各種參數的表：我應該在更新的數據模型中使用hstore嗎？

create table params (
    kind integer, 
    docid integer, 
    parname text, 
    parvalue text, 
    constraint params_pk primary key (kind, docid, parname));

可以有許多（parname，parvalue）雙爲一個文檔。由於種類指向不同的表，它不能用作外鍵。

由於params只用於打印文件，它一直運行良好多年。現在這個表格包含5百萬行，並且數據也需要用於其他目的。所以現在是更新這個模型的時候了。

基本上params爲文檔插入一次並且很少更新。它們將作爲一個整體來閱讀（用於文檔）。沒有必要搜索特定的parname。

我有三個想法：

變A. 分解表根據父表和使用文檔ID爲外鍵PARAMS到幾個表。

變式B 拆分表PARAMS如在變體A和存儲（parname，parvalue）作爲hstore。

變體C. 在每個父表中添加一個hstore字段並忘記其他表。

我對hstore沒有經驗。每個變體的缺點和優點是什麼？你會選哪一個？難道hstore會讓我感到奇怪嗎？

來源

2014-05-12 Adam Piotrowski

我投第三個選項。表格越少，睡眠越好。

Hstore是爲一級參數列表而發明的。它穩定，快速和簡單，完全符合您的需求。前段時間我有類似的任務。我寫了一個聚合更容易轉換。

create or replace function hstore_add(hstore, text, text) 
returns hstore language plpgsql 
as $$ 
begin 
    return case 
     when $1 isnull then hstore($2, $3) 
     else $1 || hstore($2, $3) end; 
end $$; 

create aggregate hstore_agg (text, text) (
    sfunc = hstore_add, 
    stype = hstore 
);

我認爲這可能會節省您的時間。

select kind, docid, hstore_agg(parname, parvalue) 
from params 
group by 1, 2 
order by 1, 2;

來源

2014-05-13 10:16:20 klin

完成！現在在開發環境中。這比我想象的要容易得多。謝謝大家，特別是klin節省了代碼！ –

如果你說你需要用文檔獲取字段，那麼非規範化的hstore變體會更好，因爲服務器將能夠從磁盤上的單個位置獲取整個文檔，而不是使用多個位置來索引連接與領域的文件。我用hstore看到的唯一問題是一種非常規的語法。使用JSON可能會更容易。 PostgreSQL 9.4將對(indexed) binary JSON有極好的支持。使用二進制JSON是由hstore作者，BTW recommended。

因此，一個計劃可能是使用9.3中的json列，然後在9.4中將其轉換爲jsonb。

來源

2014-05-12 18:57:30 ArtemGr

對於簡單的鍵/值對我認爲hstore是比JSON更好的選擇。 –

@a_horse_with_no_name技術上hstore沒有比二進制JSON更好，使用JSON的客戶端可能會重新使用現有的JSON庫中受益。 – ArtemGr

我應該在更新的數據模型中使用hstore嗎？

回答

相關問題