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的工作者， 你的职责是服务于你的公司，提供专业的，更高效的数据库去为企业服务，加速程序开发速度，降低开发中程序员遇到的困难，并解决他，哪种数据库不是重点，重点是解决问题。
