我認爲你應該從一個簡單的,規範化的模式開始,特別是因爲你是PostgreSQL的新手。喜歡的東西:
CREATE TABLE product_data
(
product TEXT, -- I'm making an assumption about the types of your columns
time TIMESTAMP,
value DOUBLE PRECISION,
PRIMARY KEY (product, time);
);
我肯定會記住hstore
和類似的選項,如果當你的數據變得足夠大,使得效率更重要,更簡單。但請注意,所有選項都有效率折衷。
你知道你要支持多少數據嗎?產品數量,每種產品的不同時間戳數量?
你想運行哪些其他查詢?如果產品具有多個不同的時間戳,那麼查詢單個產品成本超過100美元的時間將從(product, value)
的索引中受益。如果你想存儲任意鍵 - 值對的表設置在一排
其他選項
hstore
是最有用的。你可以在這裏使用它,每個產品都有一行,每個產品的不同時間戳都是產品表中的關鍵。缺點是hstore
中的鍵和值是文本,而您的鍵是時間戳,而您的值是某種類型的數字。所以型式檢驗會有一定程度的減少,而且所需的型號鑄造成本會有一定的增加。另一個可能的缺點是對hstore
的某些查詢可能不會非常有效地使用索引。上表可以使用簡單的btree索引進行範圍查詢(例如,您想要爲產品的兩個日期之間提取值)。但是,hstore索引更加有限;您可以在hstore列上使用gist或gin索引來查找具有某個鍵的所有行。
另一種選擇(我已經玩過並用於我的一些數據庫的實驗)是數組。基本上,每個產品都有一個值數組,每個時間戳映射到數組中的一個索引。如果時間戳非常規則,這很容易。例如,如果你所有的產品有一個值,每隔一小時,每一天,你可以使用一個表是這樣的:
CREATE TABLE product_data
(
product TEXT,
day DATE,
values DOUBLE PRECISION[], -- An array from 0 to 23.
PRIMARY KEY (product, day);
);
您可以構建視圖和索引,使查詢該表溫和容易。 (我在http://ejrh.wordpress.com/2011/03/20/vector-denormalisation-in-postgresql/上寫了一篇關於這項技術的博客文章。)
但是我的建議仍然是:從一張簡單的表開始,然後探索提高效率的方法,當你知道你需要它們時。
我同意Edmnud。 「hstore」不是這份工作的好選擇。如果時間值位於hstore內,則無法有效地使用b-tree索引。更重要的是,更新hstore需要將整個hstore重新寫入新的行版本,與在子表中插入/更新/刪除單個值相比,這非常昂貴。如果值位於hstore中,則不能使用排除約束來防止時間重疊。我看不出有什麼理由在這裏使用hstore,並且沒有任何理由。 –