数据库——三维表设计

  1. 博主生活
  2. 前言
  3. 二维结构,伪三维
  4. 三维结构
    1. 案例
      1. 函数表(function)
      2. 数据表
    2. 分析

博主生活

来日本的一个半月时间,虽然代码没有打太多,但是从代码的编写和测试部分学到一些道理。

前言

在以前的文章中<配置文件-ini-yaml-toml-json-xml等比较>,博主稍微讲述了一些数据是可以分为一维(单纯的key-value)、二维(key-value,value可为对象)和三维(key属性-key-value,key可为数组),xml的强大正因为它拥有了三维。而今天,博主想展开类似的话题——数据库的数据多维性。

二维结构,伪三维

非关系型数据库(NoSQL)的表是由行、列(数组)组成。每一行的每个单元由属性和数据组成。某种程度上,非关系数据库也是三维的,但是由于z是固定值,不可以扩展。因此博主将此定义为二维的。

1556650128149

三维结构

关系数据库(Relational database)的表由行、列和默认模板组成,对应上文的二维。人们可以随机添加行和列,但是很难操作默认模板。默认模板并非不可操作,只是这种操作是窄小的。在关系数据库中,这种模板体现为:类型(string、integer/float)、键(主键外键、组合键)、触发器等。相对NoSQL而言,关系数据库具有较强的扩展性,但是z轴并非是完全自由的。

1556650282280

  1. 上层应用与DB应用的类型并非一一对应。上层应用为了满足自己需求,必须开辟一个地方存储这些数据,以便检查等。
  2. 上层应用难以对DB功能进行操作。
    • 没必要修改DB功能。上层应用的功能与DB功能并非一一对应(第一条提及),而上层应用修改DB功能往往是为了上层应用自身,也就是不一定真需要对DB的功能进行修改,只要上层能体现出来被修改的效果即可。(下文将提及,DB功能被当作数据存储起来)

1556678900476

综上所述,关系数据库自身是三维的,但是DB功能过于僵化无法扩展,以至于难以与上层应用连接。(暂且称这种三维叫伪三维吧)

而为了服务上层应用,我们需要真三维。两张表,(1)张是记载具体的数据,(2)张是记载描述(1)表的信息。

案例

关系数据库因为函数(function)和触发器(trigger)等功能的能力过弱,所以难以完全负责上层应用的功能,因此,我们需要提出函数的这一个概念。另外,在以往的经验我们可以得出:

程序=数据+函数

函数表(function)

函数表的内容仅仅起到分类的作用,而上层应根据函数表内的数据,从而执行相关的操作。

表内数据通常通过以下方式变更

  • 手动操作
  • 自动化操作

自动化操作:如过期时间,因为每天每时每刻时间都自动在流逝,当时间大于等于过期时间,自动化操作就会出发。

手动操作:则是相对自动化操作。

函数表是一个记载函数相关的内容一切的表。于是乎,我们不得不思考函数的实质是什么?在博主现今的项目,函数表则是一个SQL语句。为什么是SQL呢?

1562773835557

如图所示,函数这个模块对数据表是起到修改的作用,而函数表是间接对数据表进行操作。再具体分析点,数据表被操作的无非是DML三种操作

  1. 插入
  2. 更新
  3. 删除

这三种操作其实可以合并

  1. 值从不存在到存在→插入 (空格/null→值)
  2. 值更新→更新(值A→值B)
  3. 值从有→无删除(值→空格/null)

于是乎,我们只需要update语法进行讨论。update语法如下

  1. update 选择表
  2. set 选择更新的key和value
  3. where语句。

就此,我们可以将函数表设计如下:

  • 函数meta表,记载函数一些基本信息以及扩展信息
  • set表,需要更新的value以及对应的key,而这key是什么?这个到数据表时候再进行讨论。
  • where表,对更新内容进行范围限制。
  • update对象(暂时不进行讨论)

数据表

分析数据表时,我们应该分析一下表是什么的一个东西。首先,它必须有属性,随着数据的增加,纵列慢慢变长,此时就不再是一维而是二维。若是横列也能增长,那么我们设计时候应该写成两个表

  • key表
  • value表

而key不需要进行扩展的情况下,写成一张表即可。而这里的key表的ID为key_id(主键),与函数的set表的key_id(外键)是对应的。

分析

数据库常常起到一种解耦的作用,表越多往往越是能解耦,但是代价也是存在的。Spring通过IOC的方式进行解耦,代价是从代码上无法直接查看上下文,该问题的解决往往需要借助工具之手以及过去的经验、甚至文档。