V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
magicdu
V2EX  ›  Java

各位的代码里还在用 SQL 语句吗?怎么管理的

  •  1
     
  •   magicdu ·
    magicdu · 2018-11-11 14:51:38 +08:00 · 14853 次点击
    这是一个创建于 2189 天前的主题,其中的信息可能已经有所发展或是发生改变。
    如题,大家或者大家的公司怎么处理业务逻辑复杂的 SQL 语句呢,用 mybatis 呢?还是干脆舍弃了 SQL 呢,采用其他的方式呢?
    104 条回复    2018-11-13 11:18:24 +08:00
    1  2  
    actar
        1
    actar  
       2018-11-11 14:58:37 +08:00 via Android   ❤️ 1
    JPA,QueryDSL?? 不清楚,我还没有工作。
    kawowa
        2
    kawowa  
       2018-11-11 14:58:54 +08:00 via Android   ❤️ 1
    ...不都是封装好或者存储过程然后你只能调用的吗,代码里面直接操作 SQL 比较危险呀
    ltoddy
        3
    ltoddy  
       2018-11-11 15:05:06 +08:00   ❤️ 2
    @kawowa 第一次见到用存储过程的!!!!!!
    ltoddy
        4
    ltoddy  
       2018-11-11 15:06:06 +08:00   ❤️ 1
    公司不是 java 开发, 所以都是用的 orm 框架. 例如: User.query.... 这样的.
    你只需要关注业务就可以了, 具体 sql 是由 orm 自己拼的.
    skypyb
        5
    skypyb  
       2018-11-11 15:11:53 +08:00 via Android   ❤️ 1
    spring boot jpa。
    然鹅还是遇到不少需要自己写 sql、hql 的情况
    skypyb
        6
    skypyb  
       2018-11-11 15:12:24 +08:00 via Android
    spring data jpa 说错了- -
    zgray
        7
    zgray  
       2018-11-11 15:14:46 +08:00 via iPhone   ❤️ 1
    团队自己做了个数据访问层,基本思路类似 mybatis。把 sql 写在 xml 中。
    magicdu
        8
    magicdu  
    OP
       2018-11-11 15:18:28 +08:00 via Android
    @kawowa 我这大部分都是复杂查询,其他的修改更新很少
    magicdu
        9
    magicdu  
    OP
       2018-11-11 15:20:49 +08:00 via Android
    @zgray 这样确实能比较直观的管理 sql,
    linbiaye
        10
    linbiaye  
       2018-11-11 15:23:44 +08:00   ❤️ 1
    mybatis 啊,复杂的语句直接扔 xml 里面。
    sutra
        11
    sutra  
       2018-11-11 15:35:41 +08:00   ❤️ 1
    简单的就 spring-data-jpa with Querydsl 了,复杂的还是写 xml 里好点,否则在 Java 文件里拼字符串太难编辑了。
    dszhblx
        12
    dszhblx  
       2018-11-11 15:48:48 +08:00 via iPhone
    用存储过程,代码拼 sql 是最原始的方式
    Raymon111111
        13
    Raymon111111  
       2018-11-11 16:00:29 +08:00
    mybatis 不够吗, 通通都放进了 xml 里
    qiyuey
        14
    qiyuey  
       2018-11-11 16:06:01 +08:00
    MyBatis + 注解,全部内聚到 DAO 里,也不用涉及 XML
    duan602728596
        15
    duan602728596  
       2018-11-11 16:13:45 +08:00 via iPhone
    websql 当然是自己写 sql 了
    gowk
        16
    gowk  
       2018-11-11 16:23:37 +08:00   ❤️ 14
    1. ORM 是反模式,是错误的东西,它企图弥合关系数据库和对象之间的鸿沟,但却带来了更复杂的抽象。2. 诸多 ORM 之间的 API 不一致,导致无法重用,既然有了 SQL 这么表达力强又优美的语言,为什么还要把它翻译成 ORM 的方式?仅仅因为你希望用「统一」的语言开发你的软件? 3. ORM 可能会产生性能问题。综上所述,Hibernate 是垃圾,JPA 是垃圾中的垃圾,我推荐 Mybatis,或者其他基于 JDBC 的轻量级封装库或 Query Builder。
    fuyufjh
        17
    fuyufjh  
       2018-11-11 17:31:45 +08:00
    作为数据库开发者我只想劝一句:不要用 ORM !不要用 ORM !不要用 ORM !
    tabris17
        18
    tabris17  
       2018-11-11 17:37:23 +08:00
    @gowk ORM 能解决 90%的场景,提升 90%的开发效率
    tabris17
        19
    tabris17  
       2018-11-11 17:38:14 +08:00
    @gowk 至于性能……性能一下子就优化好了我岂不是要失业了
    zjsxwc
        20
    zjsxwc  
       2018-11-11 17:47:38 +08:00 via Android   ❤️ 1
    答楼主:用 querybuilder 管理啊,最经典的设计模式之一!


    ps,楼上黑 orm 是什么意思,经典的数据持久化抽象没什么好黑的,这种黑不是坏就是蠢
    xhinliang
        21
    xhinliang  
       2018-11-11 19:24:39 +08:00
    我们手写 SQL,支撑了一亿多日活。
    SabaPing
        22
    SabaPing  
       2018-11-11 19:46:57 +08:00
    scala, 纯

    fp, 用 doobie 交互数据库, 直接在代码里撸 raw sql.
    linbiaye
        23
    linbiaye  
       2018-11-11 19:48:11 +08:00
    我们的方案是 mybatis, 简单的 CURD 交给插件,复杂的手写。表结构变了插件直接重新生成一下,插件和手撸的互不干扰。
    atcdef
        24
    atcdef  
       2018-11-11 19:49:01 +08:00
    坚持手写 SQL 一百年不动摇
    gowk
        25
    gowk  
       2018-11-11 19:58:39 +08:00 via Android
    @tabris17 嗯,大部分 trivial shit code 用用 ORM 也无可厚非
    alamaya
        26
    alamaya  
       2018-11-11 20:23:50 +08:00
    对性能没啥要求的系统,用啥都行,怎么方便怎么来
    对性能有要求的只能手写
    Aidenboss
        27
    Aidenboss  
       2018-11-11 20:37:03 +08:00
    简单的场景用 JPA 就够了,复杂的 JPA 也支持自定义 SQL 啊。
    用 JPA 有个好处不用写 mapper
    beginor
        28
    beginor  
       2018-11-11 20:43:48 +08:00 via Android
    ORM 性能确实不佳,但是能满足大量的简单的增删改查,开发效率比较高, 复杂查询可以用自定义 SQL 解决。 我司用 .net 平台, 采用的 NHibernate + dapper 的组合。
    dawncold
        29
    dawncold  
       2018-11-11 20:46:24 +08:00   ❤️ 1
    我司手写复杂 SQL,但也不至于连 insert into 也是手写,对数据库操作有简单封装,主要是对结果进行封装:获取一行、获取一列、获取某行的某列、执行任意 SQL,如果有特别需要 insert into 也是手写,不使用 ORM,这样很直观,心里有底吧。

    对结果简单封装后用起来和 ORM 差不多,比如获取一个订单:

    ```python
    purchase = db().get('SELECT * FROM purchase WHERE id=%(purchase_id)s', purchase_id=123)
    print(purchase.shopper_id)
    print(purchase.sales_channel_id)
    ```
    等等读取操作和用 object 的感觉一样,但如果要更新 purchase 则需要写 SQL:
    ```
    db().execute('UPDATE purchase SET processed_at=CURRENT_TIMESTAMP WHERE id=%(purchase_id)s', purchase_id=123)
    ```

    获取一些订单:
    purchases = db().list('SELECT * FROM purchase WHERE created_at>=CURRENT_DATE')
    for purchase in purchases:
    print(purchase.id)

    获取订单某个字段:
    shopper_id = db().get_scalar('SELECT shopper_id FROM purchase WHERE id=%(purchase_id)s', purchase_id=123)

    获取订单 ids:
    purchase_ids = db().list_scalar('SELECT id FROM purchase WHERE created_at>=CURRENT_DATE')


    对数据库的变动写 migration 脚本,按顺序部署时应用到数据库中。

    开发环境中模块对表的读写有管理,不是某个模块想写哪就写哪,想读谁就读谁,但这个在生产环境不检查。
    TommyLemon
        30
    TommyLemon  
       2018-11-11 23:32:47 +08:00
    大部分需求都用这个自动化 ORM 库,不需要写代码,逻辑太复杂或对性能要求高的地方就手写 SQL。
    它会自动将前端传的 JSON 参数转为 SQL 语句执行并返回结果,
    期间自动校验权限、结构、内容,自动防 SQL 注入。
    github。com/TommyLemon/APIJSON
    TommyLemon
        31
    TommyLemon  
       2018-11-11 23:38:03 +08:00   ❤️ 1
    @TommyLemon
    前端传一个 JSON:
    {
    "User": {
    "id": 82001
    },
    "[]": {
    "count": 10,
    "page": 1,
    "Comment": {
    "userId@": "User/id",
    "@order": "date-"
    }
    }
    }

    后端完全自动化解析,不用写代码。
    1.自动生成
    SELECT * FROM User WHERE id = 82001 LIMIT 1 OFFSET 0

    2.自动生成
    SELECT * FROM Comment WHERE userId = ${User.id} ORDER BY date DESC LIMIT 10 OFFSET 10
    TommyLemon
        32
    TommyLemon  
       2018-11-11 23:47:19 +08:00
    @actar
    @ltoddy
    @skypyb
    @gowk
    @fuyufjh
    @tabris17
    @beginor
    Hibernate, Spring Data JPA, QueryDSL 表达力都不够强,
    除了单表的增删改查,其它复杂一点的,例如 JOIN 写起来比原生的 SQL 还麻烦,
    首先是一堆括号,然后 <, >, !=, <=, >= 等符号还得用 lt, gt, ne, lte, gte 等别扭的写法。
    Star 都已经被自动化的 APIJSON 超过了。
    https://github.com/TommyLemon/APIJSON
    xy90321
        33
    xy90321  
       2018-11-11 23:59:24 +08:00
    我接触下来,真的称得上业务的一般都不存在简单的 CRUD
    最起码一定都是连表,左右结合是家常便饭的那种...
    这种时候 ORM 简直一无是处
    TommyLemon
        34
    TommyLemon  
       2018-11-12 00:01:54 +08:00
    @TommyLemon 括号倒是不用手写,但阅读起来麻烦。
    TommyLemon
        35
    TommyLemon  
       2018-11-12 00:05:31 +08:00   ❤️ 1
    @xy90321
    一般的互联网应用还是大量存在简单的 CRUD 和 不是比较复杂但不是很复杂的查询 需求的,用 APIJSON 很合适。
    对于一堆需要写 1 屏以上 SQL 才能实现需求的 ERP 项目,还是老老实实写原生 SQL 或 Mybatis 这种接近原生 SQL 的代码吧。
    TommyLemon
        36
    TommyLemon  
       2018-11-12 00:05:57 +08:00
    @TommyLemon CRUD 和 比较复杂但不是很复杂的查询
    timepast
        37
    timepast  
       2018-11-12 00:27:54 +08:00 via Android
    @linbiaye 什么插件?
    BBCCBB
        38
    BBCCBB  
       2018-11-12 08:37:25 +08:00
    mybatis+mapper, 爽
    liuxey
        39
    liuxey  
       2018-11-12 08:46:46 +08:00
    @TommyLemon #32 实在话,三表之上的内外连接家常便饭

    如果楼主公司的业务有大量定制 sql 语句,还是放 xml 最清晰吧,毕竟分离了。。
    tairan2006
        40
    tairan2006  
       2018-11-12 08:47:02 +08:00
    写 java 用过 mybatis-plus,还是挺爽的

    Python 和 Go 还是用 orm 居多,都还行
    lj3lj3
        41
    lj3lj3  
       2018-11-12 09:03:34 +08:00
    JOOQ+SimpleFlatMapper 感觉比 QueryDSL 稍微顺畅一点
    micean
        42
    micean  
       2018-11-12 09:06:50 +08:00
    就算是现有的 ORM 框架也总会有手写 SQL 的接口
    passerbytiny
        43
    passerbytiny  
       2018-11-12 09:11:05 +08:00   ❤️ 1
    @gowk #16 照你 1、2 的说法,你为什么不直接用 SQl 做开发,更简单?至于 3,设计良好的程序,Hibernate 性能比 Mybatis 以及手写 SQL 高,是不争的事实,说话前请做好调查。还有,Mybatis 也是 ORM。
    salamanderMH
        44
    salamanderMH  
       2018-11-12 09:11:53 +08:00
    手写 SQL
    passerbytiny
        45
    passerbytiny  
       2018-11-12 09:12:28 +08:00
    @xy90321 #33 你需要了解一下领域驱动设计。
    Chenamy2017
        46
    Chenamy2017  
       2018-11-12 09:15:30 +08:00
    @kawowa 存储过程,如果切库怎么办?
    zrrd
        47
    zrrd  
       2018-11-12 09:18:11 +08:00
    公司在用 mybaits plus + mybaits 增删改全部通过 mybaits plus 查找自己写 sql 放到 xml 里面
    binge
        48
    binge  
       2018-11-12 09:27:14 +08:00
    作为开发人员 SQL 还是有必要深入掌握,哪怕用的是 ORM,脑海里也要知道生成的 SQL 是怎样,在一些查询稍微复杂的场景,很多时候的性能问题往往都是慢查询所致。
    jswh
        49
    jswh  
       2018-11-12 09:27:21 +08:00
    PHP 数据取出来存数组,字段是哪些都不知,IDE 也就更智障了,所以 ORM 在 PHP 里面还是很好用,这时候就比较羡慕你们强类型的。不过,有些 ORM 把事情弄得很复杂,我也不太喜欢(对,我说的就是 Laravel ),只要简单的 Query Builder 和数据 mapping 就行了。

    互联网业务,特别的信息业务我接触的比较多,大多数时候直接到数据这一步大多都是简单的 CURD,可以不连表就不连表,能上缓存就上缓存的。重复零碎的 SQL 很多的,手写并不是很好管理,可读性也不好。真需要手写的,也多用 SQL shop 之类的统一管理调用,直接在业务里写 SQL,我不太喜欢。
    linbiaye
        50
    linbiaye  
       2018-11-12 09:29:12 +08:00
    chocotan
        51
    chocotan  
       2018-11-12 09:29:26 +08:00
    前几天看到一歪果仁的统计调查里用 mybatis 的少得可怜,基本是 hibernate、jpa
    kingwl
        52
    kingwl  
       2018-11-12 09:37:37 +08:00
    不要拼接 SQL
    现在的注入还少吗
    xschaoya
        53
    xschaoya  
       2018-11-12 09:41:02 +08:00 via Android
    复杂查询不用 SQL 用 ORM 大概会累死吧
    cstj0505
        54
    cstj0505  
       2018-11-12 09:41:34 +08:00
    @gowk 老哥有道理,我看很多人简直为了分层而分层
    xhinliang
        55
    xhinliang  
       2018-11-12 09:47:00 +08:00
    @kingwl 手写 SQL 不等于拼接 SQL。
    hzw94
        56
    hzw94  
       2018-11-12 09:50:49 +08:00
    mybaits
    xml
    Variazioni
        57
    Variazioni  
       2018-11-12 09:54:40 +08:00
    mybatis。。。我们团队的老产品技术栈还停留在原始 JDBC 的阶段。。
    nekoneko
        58
    nekoneko  
       2018-11-12 10:03:56 +08:00
    jdbcTemplate 手撸 sql
    balamiao
        59
    balamiao  
       2018-11-12 10:18:20 +08:00
    ORM
    visonme
        60
    visonme  
       2018-11-12 10:20:52 +08:00
    ORM + SQL
    对于负责情况下的数据库操作,没办法只能用 SQL 去处理,大部分实在 ORM 下工作
    关于 SQL 语句的管理,其实没有太规范的方式,我们都是直接用类似 ini 文件格式的方式去管理的~
    nutting
        61
    nutting  
       2018-11-12 10:22:46 +08:00
    感觉 orm 不适合对象套对象的复杂面向对象关系,搞了以后性能会下降很多。如果简单了呢又有点鸡肋,比较尴尬
    pb941129
        62
    pb941129  
       2018-11-12 10:34:45 +08:00
    django queryset...算 orm 吧
    szq8014
        63
    szq8014  
       2018-11-12 10:52:01 +08:00
    不知道为啥 Hibernate 这么招黑,很多用 Mybatis 开发发现 sql 生成太麻烦,然后加代码生成器插件,还有的用动态的 mapper,为了性能再配个缓存,这样搞和 Hibernate 有多大区别。。这不是屠龙少年的故事么? 0.0

    对于 [简单的 CRUD] 来说 Hibernate 开发效率很高啊,而且和缓存深度结合的,为啥不尝试一下 Hibernate,当你拒绝一个东西的时候你就少了一条路 0.0

    像那种银行啊、考勤啊那种随便一个查询就关联 N 个表的查询业务场景 mybatis 还是非常适合的。

    对于那种 cud 都喜欢写 sql 的推荐去写 php,一杆子捅到数据库?(逃

    这么想控制每一行代码每一个细节,肯定是处于自己对于技术的不自信~(我也是不自信,希望以后能做到大剑无锋
    TommyLemon
        64
    TommyLemon  
       2018-11-12 10:58:57 +08:00
    @binge 说的很对,SQL 肯定是要掌握的,不仅在于方便优化性能,还在于方便使用 Navicat 等数据库工具来调试。

    @liuxey @passerbytiny @micean @visonme @xschaoya
    一般 ORM 对不是很复杂的查询都能做到一定程度的优化的,能提高性能下限,但也会拉低上限。
    所以不是很复杂的 SQL 用 ORM 做很合适,太复杂的还是手写 SQL 针对性更好。

    APIJSON 的自动化 JOIN,自动解析生成的 SQL 和手写的 除了多了引号外几乎没有区别,
    至于连表的数量也没有限制,3 张表不算什么。
    {
    "[]": {
    "count": 5,
    "join": "&/User/id@,</Comment/momentId@",
    "Moment": {},
    "User": {
    "id@": "/Moment/userId",
    "@column": "id,name"
    },
    "Comment": {
    "momentId@": "/Moment/id"
    }
    }
    }

    会自动解析为
    SELECT `Moment`.*,`User`.`id`,`User`.`name`,`Comment`.* FROM `Moment`
    INNER JOIN `User` ON `User`.`id` = `Moment`.`userId`
    LEFT JOIN `Comment` ON `Comment`.`momentId` = `Moment`.`id`
    LIMIT 5 OFFSET 0


    创作不易,GitHub 右上角点 Star 支持下吧 ^_^
    github.com/TommyLemon/APIJSON
    no1xsyzy
        65
    no1xsyzy  
       2018-11-12 11:00:48 +08:00
    @zjsxwc #20 ORM 反数据库操作,把所有东西一股脑给你,然后让你自己丢弃,凭空浪费数据库计算资源和带宽资源。
    我不排除有一两个做得好的(对代码静态分析出后续需要什么,或者动态猜测这一处调用后续需要什么),但我为什么要花那么多时间在各种不同语言不同接口的 ORM 中找到一个可以用的?
    TommyLemon
        66
    TommyLemon  
       2018-11-12 11:01:24 +08:00
    @szq8014 对的,针对不同的场景选择合适的工具就好。可以看下我上面的回答
    zhaogaz
        67
    zhaogaz  
       2018-11-12 11:02:15 +08:00
    其实我不太懂,舍弃 sql 用啥?用 redis 之类的么?还是用别的?存储过程不算 sql ?

    还有就是有啥可管理的,要管理啥?
    TommyLemon
        68
    TommyLemon  
       2018-11-12 11:07:02 +08:00
    @no1xsyzy
    @nutting
    @visonme
    Hibernate 这种对于稍微复杂一点的关联查询写法都比较麻烦,代码不够直观,一般非单表的 CRUD 确实不如手写 SQL。
    APIJSON Star 已经超过它了,并且对于简单的 CRUD、比较复杂但不是非常复杂的查询 就支持得很好,非常直观:
    {
    "[]": {
    "count": 5,
    "join": "&/User/id@,</Comment/momentId@",
    "Moment": {},
    "User": {
    "id@": "/Moment/userId",
    "@column": "id,name"
    },
    "Comment": {
    "momentId@": "/Moment/id"
    }
    }
    }

    会自动解析为
    SELECT `Moment`.*,`User`.`id`,`User`.`name`,`Comment`.* FROM `Moment`
    INNER JOIN `User` ON `User`.`id` = `Moment`.`userId`
    LEFT JOIN `Comment` ON `Comment`.`momentId` = `Moment`.`id`
    LIMIT 5 OFFSET 0

    APIJSON 目前已实现:
    大体功能:增删改查、分页查询、统计与验证、注册登录、模糊搜索、结构校验、角色及操作权限校验、数据保护、远程函数调用等
    操作方式:增、删、改、查、调用远程函数
    操作对象:单个对象、可关联的多个对象、数组等
    请求方法:GET,HEAD,GETS,HEADS,POST,PUT,DELETE
    请求结构:{Table:{...}}、{Table0:{...},Table1{...},Table2:{...}...}、{"[]":{Table:{...}}}、{"[]":{Table0:{...},Table1{...},"Array0[]":{...},...}}等各种组合和嵌套
    返回结构:对应请求结构的各种 JSON 结构。
    功能符号:

    "key[]":{} // 查询数组

    "key{}":[] // 匹配选项范围

    "key{}":"<=10;length(key)>1..." // 匹配条件范围

    "key()":"function(arg0,arg1...)" // 远程调用函数

    "key@":"key0/key1.../targetKey" // 引用赋值

    "key$":"%abc%" // 模糊搜索

    "key~":"^[0-9]+$" // 正则匹配

    "key%":"2018-01-01,2018-10-01" // 连续范围

    "key+":[1] // 增加 /扩展

    "key-":888.88 // 减少 /去除

    "name:alias" // 新建别名

    "@column":"id,sex,name" // 返回字段

    "@group":"userId" // 分组方式

    "@having":"max(id)>=100" // 聚合函数

    "@order":"date-,name+" // 排序方式

    "@schema":"sys" // 集合空间

    "@database":"PostgreSQL" // 跨数据库

    "@role":"LOGIN" // 访问角色
    详细说明见通用文档中的 [功能符]( https://github.com/TommyLemon/APIJSON/blob/master/Document.md#3.2)
    创作不易,GitHub 右上角点 Star 支持下吧 ^_^
    TommyLemon
        69
    TommyLemon  
       2018-11-12 11:09:50 +08:00
    @no1xsyzy
    “把所有东西一股脑给你,然后让你自己丢弃,凭空浪费数据库计算资源和带宽资源。”
    这就是 ORM 库没有封装好的结果,用 APIJSON 就能很简单直接地指定每张表的字段,
    自动解析生成的 SQL 里 SELECT 的就不是 * , 而是 "@column": "id,name" 对应的 `id`,`name` 了。
    janus77
        70
    janus77  
       2018-11-12 11:13:50 +08:00
    最常用的就 mybatis jpa 啊,不过有自研的一套轻量级框架,用 freemarker 就行了
    gowk
        71
    gowk  
       2018-11-12 11:14:45 +08:00
    @passerbytiny MyBatis is SQL centric. It heps you calling SQL statements and mapping results (tables) to object trees. The main benefit is that it is *not* an ORM.
    passerbytiny
        72
    passerbytiny  
       2018-11-12 11:22:08 +08:00
    @gowk #71 ORM is:Object Relational Mapping. 一瓶不满扳平咣当。
    zjsxwc
        73
    zjsxwc  
       2018-11-12 11:22:21 +08:00
    @no1xsyzy

    你自己不会用,怪谁
    ghos
        74
    ghos  
       2018-11-12 11:24:34 +08:00
    @TommyLemon 那不是重新发明了一个 json 版的 sql。。。。
    xrlin
        75
    xrlin  
       2018-11-12 11:38:14 +08:00
    歪个楼,如果没有 orm,做 query caching 不是不方便了,直接使用 database 的 query caching ?。
    TommyLemon
        76
    TommyLemon  
       2018-11-12 11:46:46 +08:00
    @ghos 可以这么理解。
    有人问过 “前端为什么不直接发送 sql 到后端更简单直接”

    我的回答是:
    解析 SQL 语法,再校验权限、结构、内容,最后再转回 SQL,
    不说性能问题,真要这么好搞业内也应该有不错的开源方案了。

    而且 SQL 不能直观地反映返回 JSON 的数据结构,
    APIJSON 就能做到看请求知结果,所求即所得。

    APIJSON 的 提取字段、远程函数 功能也不是 SQL 方案能方便地实现的。
    还有 自动加注释、自动生成封装请求 JSON 的代码,用 SQL 方案实现也很困难,甚至根本不可能准确地实现。

    为什么要用 APIJSON ?或者 APIJSON 有什么用?
    https://github.com/TommyLemon/APIJSON/wiki
    TommyLemon
        77
    TommyLemon  
       2018-11-12 11:47:43 +08:00
    @TommyLemon APIJSON 是提供了 自动化的权限控制、数据和结构校验、自动防 SQL 注入 的。
    blless
        78
    blless  
       2018-11-12 12:02:13 +08:00 via Android
    反正代码里面查出来的数据也不能直接用,还不是得转换成对象,orm 不用白不用,还能防止低端开发人员的 sql 被注入。业务都是看场景的,查询多上个 redis 不比你各种优化省事
    timepast
        79
    timepast  
       2018-11-12 12:16:05 +08:00 via Android
    @linbiaye thx,我看下
    TommyLemon
        80
    TommyLemon  
       2018-11-12 12:17:50 +08:00
    @blless
    对的,缓存能解决大部分性能问题,复杂的 SQL 也很难维护,
    只有真的是那种非常复杂的查询,各种 JOIN、子查询、case 一起用,代码在 1 屏以上的才需要手写 SQL。
    可以看下我上面的回答,APIJSON 是一个自动化的 ORM 库,不用后端写代码,Star 已超 Hibernate, JPA 等。
    TommyLemon
        81
    TommyLemon  
       2018-11-12 12:20:56 +08:00
    @TommyLemon #68 楼 和 #32 楼
    buhi
        82
    buhi  
       2018-11-12 12:56:58 +08:00   ❤️ 1
    楼上疯狂打广告真的辛苦了
    kslr
        83
    kslr  
       2018-11-12 13:20:39 +08:00
    ORM 方便啊,API 都可以直接抽象出来,性能以后可以慢慢优化
    GiantHard
        84
    GiantHard  
       2018-11-12 13:44:53 +08:00 via Android
    简单的增删改查就直接 EF Core,方便快捷,复杂的,就直接 Dapper 手撸 SQL 或者存储过程
    ohoh
        85
    ohoh  
       2018-11-12 13:59:17 +08:00
    @TommyLemon 你的项目出发点很好,可是这个用 star 数来和其他项目做比较性是不恰当的吧! issues 数少的可怜说明用的人太少,做贡献的也太少了,现在哪个公司不是在追赶业务速度,你这个项目任重而道远
    Arcy
        86
    Arcy  
       2018-11-12 14:10:27 +08:00
    @linbiaye #50 2.1.2 从 git 上下载下来,无法加载配置,win 10 + idea 2018.2.5
    zhangalong69
        87
    zhangalong69  
       2018-11-12 14:12:44 +08:00
    手写 sql
    TommyLemon
        88
    TommyLemon  
       2018-11-12 14:46:19 +08:00
    @ohoh 使用率确实没有 Hibernate 高,毕竟它从 07 年开源到现在都快 12 年了,APIJSON 才 2 年多一点。
    哪个开源库的 star/issue 等不是从 0 开始的呢?
    如果都是你这种想法,Hibernate,Mybatis,OKHTTP,Vue.js 等非 大厂 /名人 出的开源库也不会流行起来了。

    Hibernate 都关掉 issue 了。
    你可以说 issue 数量多反映使用率高,
    我也可以认为 issue 数量相对少体现 bug 少及简单易用,
    才没有大量的 issue 来提交 bug、咨询使用方法 /文档 等。

    越是追赶业务,越要用简单易用、快速实现功能的工具啊,
    Hibernate 等一堆 ORM 库都是要针对每个接口写一堆 封装对象 或 注解传 SQL、写 XML 的代码,
    APIJSON 提供了自动化的 CRUD 接口个,就能做到不写代码,
    前端传一个 JSON,后端自动转 SQL 并连接数据库执行,然后返回结果,
    当需求更改时,也不用后端修改或新增代码,前端把 JSON 改一下数据或结构就行。
    linbiaye
        89
    linbiaye  
       2018-11-12 14:53:16 +08:00   ❤️ 1
    @Arcy 方便+我 qq 么 Mjg3MDgwOTQ1Cg==
    TommyLemon
        90
    TommyLemon  
       2018-11-12 15:05:16 +08:00
    @TommyLemon
    Star 虽然不代表使用率,但也能在比较大的程度上反映 Repo 在开源社区的受欢迎程度,可以看下这个趋势图
    https://www.timqian.com/star-history/#TommyLemon/APIJSON&hibernate/hibernate-orm
    ojoehao
        91
    ojoehao  
       2018-11-12 15:07:09 +08:00
    @gowk 说的这么绝对呀 各有千秋吧 虽然我也比较偏 mybatis
    gsralex
        92
    gsralex  
       2018-11-12 15:21:28 +08:00
    你可以用下,我写的
    https://github.com/gsralex/gdata
    决心要把 sql 从 java 代码中消除,个人觉得是错误的想法。用 mybatis 的 xml 来替代 java 控制 sql,就好比你把原来的鼠标去掉,换用 thinkpad 的指点杆,你要知道 xml 表达能力很弱,完全不适合在里面加入 ifelse 的语句。
    xiangyuecn
        93
    xiangyuecn  
       2018-11-12 15:47:15 +08:00
    手撸了几个类拼接 sql 语句发给数据库执行,这种不知道算不算手写 sql

    ```
    //读取数据
    FieldRead read=new FiledRead(Table.User);
    read.Long("id");
    read.String("name");
    read.Date("time")

    //生成:select top 100 id,name from userTable where 1=1 order by id desc
    read.List(100,new SQL().Cmd("1=1 order by id desc"));//[{id:123,name:"name",time:123456789},...100]
    //生成:select top 1 id,name from userTable where id=123
    read.One(new SQL().Cmd("id=").Long(RequestUserID));//{id:123,name:"name",time:123456789}

    //修改数据
    FieldSave save=new FieldSave(Table.User);
    save.Long("id",newUID());
    save.String("name","来搞我啊");
    save.Date("time", Now())
    //save.Update(new SQL().Cmd("id=").Long(123));
    //生成:insert into userTable(id,name,time) values(123,'transform 搞你妹','8102-11-12 15:45')
    save.Insert();
    ```
    xipushi
        94
    xipushi  
       2018-11-12 16:02:32 +08:00
    select,insert,update 单表 JPA 挺爽, 带条件的分页查询,只有 Example.of 用着爽
    select * from table where a in(1,2,3) and b in(2,3,4) limit 1,10, 条件是动态的,谁知道 JPA 怎么做得比较爽?这种还是拼 SQL 爽
    Hibernate 怎么用 MySql 批量插入语法? MySql 原生语法 1 秒 insert 几千条,Hibernate 1 秒几十条
    passerbytiny
        95
    passerbytiny  
       2018-11-12 17:07:26 +08:00
    @xipushi Hibernate 有 batchInsert 方法,另外如果你开启了事务,几千条之内的插入,它有可能会自动缓存然后批量插入。

    JPA 的动态查询(其实还是 Hibernate 的)要用到 Criteria API,或者 Spring 提供的 JpaSpecificationExecutor<T>,但是比较重量级,需要先理解对象型数据(而非关系型数据)的查询原理(跟 SQL 或 HQL 完全不一样)。

    有一点很关键,如果脑袋还有 SQL 的概念,那么用 JPA/Hibernate 回很吃力。Hibernate 的合理分工应该是,Java 人员只负责定义实体类,Hibernate 框架负责自动生成表,DBA 负责优化数据库和映射关系。当然,如果已经能达到上面的分工了,那么异步编程、事件编程、领域驱动设计这些概念估计也已经用上了。
    xipushi
        96
    xipushi  
       2018-11-12 18:48:59 +08:00
    @passerbytiny 刚看了下 QueryDSL,动态分页查询,感觉还是搞事。

    我说的 MySql 的批量 insert, 不是批量提交。是 insert table()values(),(),(), 一条 SQL 语句插入多条数据,batchInsert 是多条 insert 语句, 数据库的特性,批量提交比一条语句要慢点。

    Hibernate 的合理分工是理想状态,现实中我没看到只用 HQL, 不用 native SLQ。还是要有 SQL 概念,不然前人留下的代码你就看不懂了。
    feverzsj
        97
    feverzsj  
       2018-11-12 19:10:49 +08:00
    不用 sql 用什么?二进制格式协议速度是最快的
    V2XEX
        98
    V2XEX  
       2018-11-12 19:19:53 +08:00
    @TommyLemon
    看你推广 apijson 挺久了,不过你能说下你这玩意比 Spring Data Rest 有声明绝对优势?
    TommyLemon
        99
    TommyLemon  
       2018-11-12 19:24:47 +08:00
    @V2XEX 不用写代码
    TommyLemon
        100
    TommyLemon  
       2018-11-12 19:25:32 +08:00
    @TommyLemon
    为什么要用 APIJSON ?前后端 10 大痛点解析
    github.com/TommyLemon/APIJSON/wiki
    1  2  
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   1044 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 29ms · UTC 19:11 · PVG 03:11 · LAX 11:11 · JFK 14:11
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.