我认为你应该从一个简单的,规范化的模式开始,特别是因为你是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,并且没有任何理由。 –