EAV or JSON

MongoDB 之类的 NoSQL 之所以流行，很大程度上取决于相对自由的 schema 设计，不管数据量多大，可以随时在线上环境添加新字段来保存新数据，而这种能力恰恰是传统的关系数据库所欠缺的，不过别担心，传统关系数据库有自己的应对之道。我们今天就讨论一下其中最具代表性的两种方法，看看孰优孰劣。

在讨论前，我们不妨虚拟一个业务场景：假设我们要做一个类似汽车之家的产品库，首当其冲的是如何保存汽车的各种属性，比如说：长度、宽度、高度、GPS 导航系统、倒车影像、上坡辅助、陡坡缓降等等，最传统的方法是每一个属性都用一个独立的字段来保存，不过这样有问题：汽车属性有可能非常多，如此一来我们的表需要创建几十甚至上百个字段，而且以后还可能想要不断的添加新字段。最要命的是不同的汽车拥有的属性大不相同，比如有的汽车有 GPS 导航系统、倒车影像，但是却没有上坡辅助、陡坡缓降，如果把这些属性统统作为字段存在的话，那么表就是稀疏的，存在很多空值。

传统的 EAV 方法

所谓 EAV，实际上是 Entity–Attribute–Value 的缩写。它的核心思想是把原本按列保存的数据转换成按行保存。不同的项目设计在表结构上可能会有些许差异，不过核心通常就是 entity，attribute，value 三张表，下面看看采用 EAV 如何解决问题：

CREATE TABLE eav_entities (id INT UNSIGNED NOT NULL AUTO_INCREMENT,entity_name VARCHAR(100) NOT NULL,PRIMARY KEY(id)
);INSERT INTO `eav_entities`(`id`, `entity_name`)
VALUES(1,'普拉多 3.5L TX-L'),(2,'帕杰罗 3.0L 豪华版');CREATE TABLE eav_attributes (id INT UNSIGNED NOT NULL AUTO_INCREMENT,attribute_name VARCHAR(100) NOT NULL,PRIMARY KEY(id)
);INSERT INTO `eav_attributes`(`id`, `attribute_name`)
VALUES(1,'长度'),(2,'宽度'),(3,'高度'),(4,'GPS 导航系统'),(5,'倒车影像'),(6,'上坡辅助'),(7,'陡坡缓降');CREATE TABLE eav_values (id INT UNSIGNED NOT NULL AUTO_INCREMENT,entity_id INT UNSIGNED NOT NULL,attribute_id INT UNSIGNED NOT NULL,attribute_value VARCHAR(100) NOT NULL,PRIMARY KEY(id)
);INSERT INTO `eav_values`(`id`, `entity_id`, `attribute_id`, `attribute_value`)
VALUES(1,1,1,'4780'),(2,1,2,'1885'),(3,1,3,'1890'),(4,1,6,'有'),(5,1,7,'有'),(6,2,1,'4900'),(7,2,2,'1875'),(8,2,3,'1900'),(9,2,4,'有'),(10,2,5,'有');

在 EAV 模型中查询巨麻烦，主要特征就是不停的 JOIN 连表：

EAV

随便说一句，前些天途牛介绍的运维系统就是利用 EAV 设计的。

新锐的 JSON 方法

现在的关系数据库已不在是单纯的关系数据库了，很多时候视情况可以打破范式的束缚，主流的 MySQL 和 PostgreSQL 都已经支持 JSON 数据类型，以 MySQL 为例：

CREATE TABLE entities (id INT UNSIGNED NOT NULL AUTO_INCREMENT,name VARCHAR(100) NOT NULL,data JSON NOT NULL,PRIMARY KEY(id)
);INSERT INTO `entities`(`id`, `name`, `data`)
VALUES(1,'普拉多 3.5L TX-L','{"Length": 4780,"Width": 1885,"Height": 1890,"HAC": "有","HDC": "有"}'),(2,'帕杰罗 3.0L 豪华版','{"Length": 4900,"Width": 1875,"Height": 1900,"GPS": "有","ReverseImage": "有"}');

和 EAV 的相比，少了 JOIN 的累赘，简单的想哭：

JSON

如果你使用的关系数据库不支持 JSON 数据类型，那么你可能倾向于使用 EAV 来保存动态数据，但是只要条件允许，还是尽可能使用 JSON 为妙，不过 JSON 虽好，却万万不可滥用，如果我们不加区分的把大部分数据都放到一个 JSON 字段里去，那还不如直接用 MongoDB 算了，更详细的说明大家可以参考 2ndquadrant 中的介绍。当然对付动态数据，不止有 EAV 和 JSON，比如 FriendFeed 看似奇葩的做法，就不多说了。

本文转载自：火丁笔记

【技术晨读】EAV or JSON相关推荐

技术晨读_2014_9_1
#技术晨报# NoSQL反模式 – 文档数据库篇文章说的是关系型数据库怎么转换为文档型数据库,比如mongoDB... http://blog.nosqlfan.com/html/4156.html ...
技术晨读积累_20140526
技术晨读积累_20140526 2014-05-26 09:34 by 轩脉刃, ... 阅读, ... 评论, 收藏, 编辑 #技术晨读# 初探单点登录 SSO 在多个应用中,如果你登录了其中一个应 ...
晨读一年的复盘会议_一年后，在家中远程办公，网真和视频会议
晨读一年的复盘会议 Had my one year review at work last week. I met with my boss for an hour and we talked abo ...
【经济学_04】晨读：保险的实质特效药医疗膨胀保险的发明
文章目录晨读:保险的实质情景认知本质 Q1:那么保险是资产还是负债呢? Q2:富人也喜欢保险? 对于企业来说保险的好处无时无刻都在接触保险为什么说,越穷的人越需要配保险保险特点特点1: ...
java技术晨讲可以讲什么内容,晨讲和晨测都是提升郑州达内小伙们技能的好方法...
一年之计在于春,一天之计在于晨.报读郑州达内IT培训班的小伙伴们,你们准备好了吗,是否想要在这里找到人生的起点呢,还等什么呢,加油吧! 一年之计在于春,万物复苏,生机勃勃,在春天的见证下努力的成长,而 ...
外刊晨读 2018 年年 5 月月 15 日
外刊晨读 2018 年年 5 月月 15 日 Artificial Intelligence in Business 商业中的人工智能 GrAIt Expectations 远大前程 LIE DE ...
【晨读】热爱 ▪ 英语 @ 热爱 ▪ 晨读
未曾开言,我先扯皮,扯皮完了,听我讲一讲经历这是一次非常舒服的晨读. 用李光的话来说的话就是:贼得劲儿!!! 恩.是的,贼得劲儿. 不过,接下来,可能是很朴实的一些文字,可能你会觉得没意思透了.但是 ...
初中晨读必看古诗名句
初中晨读必看古诗名句[篇一] 1.笔落惊风雨,诗成泣鬼神.(唐•杜甫•寄本十二白二十) 2.墙头雨细垂纤草,水面风回聚落花. -- 张蠙<夏日题老将林亭> 3.流连戏蝶时时舞,自在娇莺恰恰 ...
晨读美文推荐【英文悦读】-《a day so happy》
晨读美文推荐[英文悦读]-<a day so happy> a day so happy. 愉快的一天. Fog lifted early. i worked in the garden. ...

【技术晨读】EAV or JSON

EAV or JSON

传统的 EAV 方法

新锐的 JSON 方法

【技术晨读】EAV or JSON相关推荐

最新文章

热门文章