[TOC=3]

5.12. 四赤阳阵の多表视图 - 图1

四人联合施展,分别在东南西北四端张开结界,发动此术时会形成一个结界阵,结界阵的四周都有火炎形成的墙壁阻挡着,无法让外界人员进入结界内部,一旦碰触结界的四壁就会被火炎烧伤。

视图和四紫炎阵非常像,一般视图由多个表组成一个整体进行展示。

5.12.1.1.1. 数据库View的概念

  • 传统DB视图,主要用于多表内容聚合展示,不支持直接基于视图进行新增和修改。
  • 视图的主要作用是聚合查询,并不是为了自动关联修改。

5.12.1.1.2. 需求的合理性

  • 1V1关联表,可以直接操作
  • 1VN or NVN 关联,仅提供查询,不应该提供编辑功能

即使隔着屏幕,我仿佛也能感受到你们有些茫然的样子5.12. 四赤阳阵の多表视图 - 图2

但是,相信看完这以下介绍您就会理解。

5.12.1.1.3. 什么是1V1关联表?

  1. SELECT
  2. `users`.`id` AS `id`,
  3. `users`.`status` AS `status`,
  4. `users`.`login_id` AS `login_id`,
  5. `users`.`login_pwd` AS `login_pwd`,
  6. `users`.`nickname` AS `nickname`,
  7. `users`.`reg_time` AS `reg_time`,
  8. `users`.`info` AS `info`,
  9. `users_exp`.`users_id` AS `users_id`,
  10. `users_exp`.`exp` AS `exp`,
  11. `users_exp`.`avg` AS `avg`,
  12. `users_exp`.`qq` AS `qq`
  13. FROM
  14. (`users` JOIN `users_exp`)
  15. WHERE
  16. (
  17. `users`.`id` = `users_exp`.`users_id`
  18. )

上面的视图就是 users 1V1 users_exp ,关联条件是 users.id=users_exp.users_id所以称之为1V1关联,因为用户和用户扩展信息表是通过user id 进行关联的,一个对一个。

反之除了1V1,其它的都是1VN or NVN

在进行非1V1业务时,比如:老师和学生老师有N个学生学生有N个老师

学生列表| ID | 姓名 | 我最喜欢的老师 || —- | —- | —- || 1 | 张三 | 熊雯 |

ID和姓名来自学生表,我的老师的名字来自老师表,通过中间关系表,多表联查形成上面的列表。但是修改这个列表的时候,显然不能直接将老师的名字给改了并且更新到老师表中。合理的需求是,可以修改学生的姓名,学生和老师的关系。但你不能直接改老师名字,你能喜欢英语老师,别人也可以喜欢,你改了名,别人还咋喜欢,都不认识了。

好吧,扯这么多,就是希望大家不要在使用视图的时候陷入误区。


再看一个段子:

问程序员,你会啥?我会增删改查。

问程序员,软件是啥?软件除了增删改查,还是增删改查。

貌似听起来没啥毛病吧?


在实际企业级项目中,很少有功能模块是纯单表操作的,多多少少关联其它表的某些字段。这时候除了增删改查,就是复杂的增删改查了,不是单表的增删改查。一个业务,需要操作3张以内的表,我们可以简单的说这是一个简单的功能。一个业务,需要操作5张以内的表,我们还可以说这是一个简单的功能吗。5张表意味着什么?5表联查,5表更新,5表。。。。尼玛想想都疼蛋。。。

PS:所以在设计表结构的时候不要将关系复杂化,应该遵循大事化小小事化了的原则,该冗余的地方就冗余,不要盲目套三大范式,你设计的表是给人用的,不是给老师打分的。

但是往往,肯定会遇到一小波业务就是有那么复杂,需要三表,甚至更多的表,联合作业。甚至在复杂业务的系统里,这是家常便饭?

怎么破?

5.12.1.1.4. EOVA视图处理的设计 V1.6

  • 利用View构建标准化联查SQL(如果你写的SQL和DB IDE生成的一样标准,甚至可以不用创建View)
  • 支持JOIN和LEFT JOIN (right join 可以改写成 left join)
  • 目的:让操作多表,像操作单表一样简单

5.12.1.1.5. 应用原则

  • 简单的业务场景用View搞定Grid+Form
  • 复杂的业务场景用View搞定Grid,自定义Form(为什么要自定义,因为我都不知道你未来要干什么)

V1.6暂行方案:

暂时半手工操作,如果可行,将配置项操作UI化!

  • 导入视图类型的元数据
  • 编辑对象配置 eova_object.config"表名": {"key": "主键字段名", "value": "对应视图中的显示字段名"}
  1. {
  2. "viewMap": {
  3. "users": {
  4. "key": "id",
  5. "value": "id"
  6. },
  7. "users_exp": {
  8. "key": "users_id",
  9. "value": "id"
  10. }
  11. }
  12. }
  • 设置元字段所属表名 eova_field.table_name
  • 显示配置Grid:不需要显示的字段配置为禁止显示Form:不能操作的字段配置为禁用/只读效果:5.12. 四赤阳阵の多表视图 - 图3

5.12. 四赤阳阵の多表视图 - 图4

SQL:

  1. --查询时
  2. select count(*) from v_users
  3. --修改时
  4. update `users_exp` set `avg` = ? , `exp` = ? , `qq` = ? where `users_id` = ?
  5. update `users` set `info` = ? , `login_id` = ? , `login_pwd` = ? , `nickname` = ? , `reg_time` = ? , `status` = ? where `id` = ?