概念

   其实数据库本没有这2个概念,这2个概念是从应用角度、逻辑角度出发诞生的。所谓常见的表都是横表,所以这里重点说下纵表,你就理解这2个概念了。

   关系型数据库或者说传统的数据库,建立模型时都需要建立明确模型的属性,而这些属性是作为字段(field)存在的,但是在应用中我们经常面临一个问题就是对象的属性是不确定的,比如我们对客户的属性,我们随着研究关注地深入,需要关注的属性越来越多;再比如淘宝在做商品筛选时,不同的商品种类其属性往往是不同的。传统的解决方案是不停地增加字段,如果一个表的字段太多,则新增表,抽象一下就是表1、表2。。。以此类推。问题光是这样也就算了,这么多表的字段其实很多字段都是null,导致我们修改是需要大量判断,同时浪费了大量的存储空间。

    基于这个需求,聪明的工程师抽象出来一个概念即纵表,典型的结构如下:

   客户id 属性类型 属性值1 属性值2 属性值3

  比如过去存储用户数据,我们可以这样定义字段:

  user_id 

name

sex

age

 1            

小明

 男

12

换成纵表后:

  user_id 

value_type

value

     1        

 姓名        

小明

     1         

性别        

     1         

年纪       

 12

    我这么解释,估计都懂了,当然它们也很容易转换,具体方法参考:IT虾米网

 

在此,我认为还可能存在一种表叫二维表,即同时结合了横表和纵表,纵表中除了关键属性为,同时还有字段代表了该属性的属性,举个例子:

User_id

Value_type

Value

真实性

权重

1

姓名

小明

1

2

1

性别

1

2

1

年纪

12

0.3

3

 

像这种二维码是无法转成一个横表的。

用途

   以上链接博文中的这种转换是通过数据库实现的,大家很容易理解,但是如果使用较多或者系统较大时,我不太推荐。首先来讲,数据库是比较宝贵的资源,拿来做这种运算有些可惜且效率不高。其次,按照这种写法,每次不同的内容都还得进行重新编写sql,甚至在增加属性时也得修改sql,或者在外层循环做判断。总结一下,感觉存储、开发、使用效率是一种天然的矛盾体,不能兼得。但是不管你怎么设计纵表,大致的过程又差不多,怎么办?

   所以我考虑单独抽象出来一个模块专门做这种转换,前端用户使用时看到的就是普通的横表,不再进行任何的循环,甚至有点像使用nosql一样的舒服,而这种转换由该模块完成,同时要求相关纵表设计只要遵守这种规范就可以去使用该模块。

 

设计引擎目标

 

 

 

实现过程


原文地址:https://blog.csdn.net/zhq651/article/details/52966951

发布评论
IT序号网

微信公众号号:IT虾米 (左侧二维码扫一扫)欢迎添加!

Neo4j属性图模型简单介绍知识解答
你是第一个吃螃蟹的人
发表评论

◎欢迎参与讨论,请在这里发表您的看法、交流您的观点。