[TOC=3]


四赤阳阵是一种结界忍术,比“四紫炎阵”强上数十倍,必须要四位影级人物同时发动。

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

5.13.1.1.1. 数据库View的概念

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

5.13.1.1.2. 需求的合理性

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

即使隔着屏幕,我仿佛也能感受到你们有些茫然的样子

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

5.13.1.1.3. 什么是1V1关联表?

SELECT
    `users`.`id` AS `id`,
    `users`.`status` AS `status`,
    `users`.`login_id` AS `login_id`,
    `users`.`login_pwd` AS `login_pwd`,
    `users`.`nickname` AS `nickname`,
    `users`.`reg_time` AS `reg_time`,
    `users`.`info` AS `info`,
    `users_exp`.`users_id` AS `users_id`,
    `users_exp`.`exp` AS `exp`,
    `users_exp`.`avg` AS `avg`,
    `users_exp`.`qq` AS `qq`
FROM
    (`users` JOIN `users_exp`)
WHERE
    (
        `users`.`id` = `users_exp`.`users_id`
    )

上面的视图就是 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.13.1.1.4. EOVA视图处理的设计 V1.6

  • 目的:让操作多表,像操作单表一样简单

5.13.1.1.5. 使用思路

  • 自建View 提供 元数据导入,支撑复杂的列表查询展现
  • 复杂表单后端逻辑通过Aop增强(配合DIY_JS 操控前端)
  • 超复杂的自定义按钮,自定义前端Form和后端逻辑

导入视图和导入普通数据表一样,没有什么特殊的地方! 列表查询和展现也没有什么特殊的地方 一个是form table 一个是form view

需求背景描述: 代码: com.oss.order.OrderIntercept By V1.6 OSS Demo 订单关联用户和收获地址: orders 订单表 users 用户表 address 收获地址表

下面主要描述核心的也是最复杂多变的地方.

新增AOP:

    /**
     * 推荐使用Model来实现业务逻辑,万物皆对象,不要问我为什么!
     */
    @Override
    public String addBefore(AopContext ac) throws Exception {
        Record data = ac.record;

        // 获取用户信息 保存
        Users user = RecordUtil.peelModel(Users.class, data, "login_id", "nickname", "info");
        user.save();

        int uid = user.getInt("id");
        LogKit.info("新增用户成功:" + user.getInt("id"));

        // 获取收获信息 保存
        Address address = RecordUtil.peelModel(Address.class, data, "name", "full", "mobilephone");
        address.save();

        int aid = address.getInt("id");
        LogKit.info("新增收获信息成功:" + aid);

        Orders order = RecordUtil.peelModel(Orders.class, data);
        order.set("address_id", aid);
        order.set("create_user_id", uid);
        order.set("update_user_id", uid);
        order.set("create_time", new Date());
        order.set("update_time", new Date());
        order.save();
        LogKit.info("新增订单信息成功:");

        return super.addBefore(ac);
    }

修改AOP:

    /**
     * 懒人做法Record,一条龙全部搞定,简单粗暴!
     */
    @Override
    public String updateBefore(AopContext ac) throws Exception {
        Record r = ac.record;

        // 获取用户信息 更新
        Record user = RecordUtil.peel(r, "create_user_id -> id", "login_id", "nickname", "info");
        Db.update("users", user);

        int uid = user.getInt("id");
        LogKit.info("更新用户成功:" + uid);

        // 获取收获信息 更新(下面的特殊语法可自行研究源码)
        Record address = RecordUtil.peel(r, "address_id -> id", "name", "full", "mobilephone");
        Db.update("address", address);

        int aid = address.getInt("id");
        LogKit.info("更新收获信息成功:" + aid);

        Db.update("orders", r);
        LogKit.info("更新订单信息成功:");

        return super.updateBefore(ac);
    }

如上是不是分分钟搞定,复杂的多表业务逻辑!

© 2019 EOVA.CN all right reserved,powered by Gitbook本文档更新于: 2019-07-22 16:24

results matching ""

    No results matching ""