V2EX = way to explore
V2EX 是一个关于分享和探索的地方
Sign Up Now
For Existing Member Sign In
This topic created in 3133 days ago, the information mentioned may be changed or developed.
说说为什么？还有可以告诉我哪个语言下哪个库超好用吗？想多了解了解，尝试造个轮子，逃...
Supplement 1 · Sep 28, 2017
orm 最主要的功能是关系数据映射称为程序中的对象，那类似 hibernate 这种多表，各种关联关系都可以进行映射的功能会用的多吗？动态 sql 需求也是非常常见的，你们怎么处理的，哪个库有比较好的支持？
 |
1
lightzh Sep 28, 2017
Golang gorm
iOS FMDB 有手写 SQL 也有 ORM，Realm 算 ORM 吧 |
 |
2
IllBeBack Sep 28, 2017
手写？等注入吗？
|
 |
4
eslizn Sep 28, 2017
工作基本手写，有性能要求并且受限于基础环境。
自己的业余项目基本用 orm，eloquent 是个不错的 orm 库 |
 |
6
FarAhead Sep 28, 2017
不会手写，只会 ORM
|
 |
7
undercloud Sep 28, 2017
一般都用 ORM，构建灵活、底层无关，还有比较方便的防注入
只有在速度有要求，没法优化的情况下才会选择手动构建 sql |
 |
8
misaka19000 Sep 28, 2017
很烦 orm，喜欢手写
|
 |
9
zonghua Sep 28, 2017
逐渐少用 MyBatis，微服务不需要复杂查询，使用 Criteria
|
 |
10
jtsai Sep 28, 2017 via Android
自己一般手写，工作看情况
|
 |
11
keysona Sep 28, 2017
开始都会用 orm，最后又会用到手写。
|
 |
12
lslqtz Sep 28, 2017
手写
|
 |
13
Miy4mori Sep 28, 2017 via iPhone
不喜欢手写 sql，很割裂，不够 oo
|
 |
14
zhustec Sep 28, 2017 via Android
难道不是 Active record 吗
|
 |
16
a87150 Sep 28, 2017
ORM 不如手写灵活，但是很方便。
|
 |
17
6ufq0VLZn0DDkL80 Sep 28, 2017
为啥要手写？手写有啥好处吗
|
 |
18
sfree2005 Sep 28, 2017 via Android
当然看需求。当下大部分的操作，ORM 已经做得很好，只有在一些很复杂的操作的时候会手写。
|
 |
19
Actrace Sep 28, 2017
ORM 的本质就是常用操作的 SQL 封装。
我觉得常用 SQL 操作都应该封装好，这就牵扯到一种 Model 的概念，在我的项目中，Model 只负责处理数据库操作。 |
 |
20
ebony0319 Sep 28, 2017 via Android
面向数据库编程。
|
 |
21
ericls Sep 28, 2017
DSL -> ORM -> 手写
|
 |
22
u5f20u98de Sep 28, 2017
手写见过写出注入的，用 ORM 也见过用出注入的，总之变量不绑定好了都会处注入。
不过遇到的手写出注入的多一些。 |
 |
24
Sapp Sep 28, 2017
beego 用的 orm 感觉还可以，但是偶尔还是手写。
|
 |
25
Erskine Sep 28, 2017 via iPad
手写 感觉 sql 就是艺术
|
 |
26
gdtv Sep 28, 2017
我喜欢手写
|
 |
27
gefangshuai Sep 28, 2017 via iPhone
我喜欢 no sql
|
 |
28
ZXCDFGTYU Sep 28, 2017 via iPad
一般来说 ORM 大部分都是支持直接 query/execute sql 的，并且大部分也都支持 bind。我的 php 项目用的是 phalcon 框架，其中自带的 query/execute 方法可以直接 push sql 过去，其中 placeholder 就是用来绑定变量的。
|
 |
29
Hstar Sep 28, 2017
当然是用 ORM, 按我的理解, ORM 就是帮你生成 SQL 语句的转译器, 所以没有手写能实现但是 ORM 实现不了的情景. 如果遇上个冷门情景没有现成封装好的方法, 那么加一个好了. 手写 SQL 很溜的用 ORM 肯定更没问题.
|
 |
30
WispZhan Sep 28, 2017
Code First，ORM 优先。目前是 JPA 用的多。 有必要的话会使用混合 MyBatis 和手写存储过程。
|
 |
31
zjsxwc Sep 28, 2017 via Android
能 orm 就 orm，好处多多，代码复用方便，ide 自动推导不会犯错，有可以轻松实现大面积魔改， 实在不行才撸 sql
|
 |
32
fxxkgw Sep 28, 2017 via iPhone
混着用，关联查询还是手写方便些个人觉得。。
|
 |
33
scnace Sep 28, 2017 via Android
不知道大家怎么看代码里的大段的 SQL 一段很长的 SQL 执行一次 跟 短 SQL 执行多次 到底哪个好 感觉长 SQL 就建表时候的功力了…
|
 |
34
simple_plan Sep 28, 2017
混用 单表 orm 多表关联 sql
|
 |
35
gclove Sep 28, 2017
表关联尽量不要用数据库去实现
尽量 ORM 吧, 我感觉就像用 C 和 用汇编的区别一样 |
 |
36
carlclone Sep 28, 2017 via Android
手写的不是大神就是菜鸟，大部分都是菜鸟，写出一堆没法维护的东西
|
 |
37
EchoUtopia Sep 28, 2017 via iPhone
orm 可以很方便的复用数据对象
|
 |
38
nekuata Sep 29, 2017
MyBatis 不算 ORM 吧？ Hibernate 也不推荐手写 SQL 而是 HQL
MyBatis & SQL 混用+1 |
 |
39
incompatible Sep 29, 2017
@IllBeBack 什么叫“防注入每次都要做“？ 写 sql 时用?而不是直接拼 where 条件这是基本功好伐？
|
 |
40
andrewpsy Sep 29, 2017
嫌弃手写的应该都是不怎么写测试的。
我喜欢手写的性能。如果怕哪块手写的 SQL 不好维护，就加上些自动测试代码，性能安全妥妥的。 |
 |
41
lightening Sep 29, 2017
绝大多数情况下用 ORM，需要手写的情况在我职业生涯中应该不超过五次。
手写的维护起来太困难，毕竟写代码的第一目的是可工作，其次是可维护。 ORM 的典范我认为是 Ruby 的 ActiveRecord。 |
|
42
scnace Sep 29, 2017 via Android
|
 |
43
EricCartman Sep 29, 2017 via Android
能 ORM 就 ORM，可维护性太重要
|
 |
44
hooopo Sep 29, 2017
OLTP 系统当然 ORM 啦，OLAP 和数据处理相关就手写咯
|
 |
45
msg7086 Sep 29, 2017  1
同推 Rails 的 Active Record。
随便贴一段 ORM 中保存前验证的代码感受下。 before_save :check_rules def check_rules conflicts = port_forward_rules.where(exposed_ip: exposed_ip, exposed_port: exposed_port).where.not(id: id) # "UDP" only conflicts with "UDP" and "Both" if udp? conflicts = conflicts.where(protocol: [:udp, :both]) # "TCP" family never conflicts with "UDP" elsif !both? conflicts = conflicts.where.not(protocol: :udp) end # No conflicts at all? Great! return if conflicts.empty? conflict = conflicts.first # If they are both HTTP or both HTTPS rule. return if ( http? || https?) && conflict.protocol == protocol throw(:abort) end |
 |
46
askfilm Sep 29, 2017
php + doctrine 带你飞
|
 |
47
jy02201949 Sep 29, 2017
手写
|
 |
48
wombat Sep 29, 2017
手写 sql
|
 |
49
taomk Sep 29, 2017 via iPhone
spring data jpa 基本上只需要继承一下框架提供的模版就可以解决所有的数据库基本操作
|
 |
50
nullcc Sep 29, 2017
简单查询 ORM，复杂查询手写
|
 |
51
TangMonk Sep 29, 2017
ActiveRecord +1
|
 |
52
jjianwen68 Sep 29, 2017
用 jpa/hibernate，但只做基本方式的映射，不习惯多表关联，复杂一点的查询就直接 hql 或者原生 sql
|
 |
53
CuminLo Sep 29, 2017
喜欢手写 SQL，但是必须绑定参数来查询。
至于为什么，可能是之前受过重构的伤，老项目迁移到新框架那些 ORM 迁移，现在想想都心累..... |
 |
54
lazypu Sep 29, 2017
laravel eloquent 蛮爽
|
 |
57
baoanlol Sep 29, 2017
用过 hibernate，不好用，后来用 slick，喜欢。。。
|
 |
58
ybh37 Sep 29, 2017
还是要看具体的业务场景，如果是实体关系简单的业务，ORM 就很好用。
相反，以下十分复杂的而且对性能有要求，一般会选择 SQL SP |
 |
59
timwei Sep 29, 2017
@msg7086
只是做字段筛选为什么用了 conflicts = conflicts.where(protocol: [:udp, :both]) 而不用 conflicts = conflicts.select{|t| [:udp, :both].include? t.protocol } where 方法会多刷了一次 query 呢 |
 |
60
resturlaub Sep 29, 2017
直接用 sql 或是用 ActiveRecord 应当是思维上的区别吧。
用 sql 的时候思考的是用一个语句得到数据，之后不管是把数据转成对象还是直接当数据来用，取数据的过程就是类似于面向过程的思维方式。 用 ActiveRecord 则全然不是这种思维方式，而是将一个数据表理解成一个类，从中抽出许多对象，得益于此一个对象的属性还可以是其他类型的，如数组，而用 sql 语句的话在存储前和读取后还需要转化，还有其他 enum 等等的特性。 还有就是代码容易读，比如用 sql status = 1 这是为什么就比较难理解。 用好 ActiveRecord 还是需要能够很好的理解 sql，这样才能理解迭代器啦，lazy load 在 ActiveRecord 是怎么实现的，才能在使用 ActiveRecord 是不会出现性能差的问题，而且用 ActiveRecord 可以更加良好的封装，同样的语句可以较好的使用数据库的缓存，也便于理解。 用 rails 之前特别喜欢写 sql，感觉写出一个高性能的 sql 内心十分之爽，后来用了 rails，使用 ActiveRecord 的同时内心还是同时想着形成的 sql 是怎么样的情况，同时也会学习到 ActiveRecord 处理后的生成的 sql 可能比我以前手写的 sql 更为好。 至于哪个好，我个人觉得这两都是基本功吧，没有场景讨论哪个好没有任何意义。有时 sql 好，够直接，爽。有时 ActiveRecord 好，易理解，爽。建议都要会。 |
 |
61
zgbgx1 Sep 29, 2017
性能要求高，还用的是 mysql 这种坑逼数据库的话，还是必须手写 sql
|
 |
62
imherer Sep 29, 2017
手写
|
 |
63
testcount Sep 29, 2017 2
我对外说的时候写 SQL，自己大部分是用 ORM。
|
 |
64
xiaowangge Sep 29, 2017
几乎不用 SQL。
 99%场景用腾讯云的 memcached、redis。游戏行业。 |
 |
65
leekafai Sep 29, 2017 via Android
我自己喜欢手写，因为自己写的自己以后看得懂。
同理，我因此不喜欢别人手写，因为别人的我怕看不懂 |
|
66
timwei Sep 29, 2017
我也是从 Rails 接触 ORM
ORM 的确可以让不熟 SQL 语句的我迅速开发数据库逻辑 可是也有些容易溷淆，大致整理几点: 1. ORM 方法对语言原生方法 order <-> sort where <-> select 2. ORM 封装的逻辑，以 ActiveRecord 的关联查询举例 preload、eager_load、includes 三个方法出来的语句差异很大 新手时期对使用场景还不熟悉，常常乱 3. ORM 没封装的 SQL 操作 像是 ActiveRecord 没封装 bulk insertion (只有一个 delete_all 方法) 又得依赖三方库 我认为 ORM 主要的价值在让有一定编程经历，却不熟 SQL 语句的程序员操作数据库 次价值在数据库换型时，几乎不用更动代码 SQLite -> MySQL -> PgSQL 只需要切换 ORM 的配置，业务代码不用更改 |
 |
67
justfly Sep 29, 2017 1
orm
在互联网行业 mysql 基本当作持久化的 kv 来用，没有复杂 sql 和关联查询。性能基本不用考虑，绝大多数访问都命中缓存，发生缓存穿透 用 SQL 还是 ORM 基本没啥区别。 |
 |
68
E2gCaBAT5I87sw1M Sep 29, 2017
SQL 不利用重构
|
|
69
timwei Sep 29, 2017
@msg7086
再提一点 conflicts = conflicts.where(protocol: [:udp, :both]) conflict = conflicts.first 逻辑上会与 conflict.where(protocol: [:udp, :both]).first 一样 可是产生的 SQL 语句会有差别，前者的语句会缺少 LIMIT |
 |
72
togodo Sep 29, 2017
小项目手写，大项目 orm
|
 |
73
coolcoffee Sep 29, 2017
感觉 orm 更接近自然语言
|
 |
74
qiu0130 Sep 29, 2017 via Android
我们公司的经历，开始 ORM，新项目 自己撸一层参数校验跑 SQL，目前打算改造一下 peewee 重构老项目。
|
 |
75
Technetiumer Sep 29, 2017 via Android
感觉 SQL 才更接近自然语言
一般用查询构造器，部分手写 SQL。 手写 SQL 比较符合我的直觉，查询构造器 /ORM 可以让你方便的跨数据库。 |
 |
76
zpf124 Sep 29, 2017
@twogoods 之前有个类似的讨论，不过像我们这样的闲人不是很多。
https://www.zhihu.com/question/39454008 虽然我也更习惯 mybatis 去手写多表联查，但个人觉得 它不算是一个标准的 ORM 框架，功能上它与 ORM 框架可以互相替换。 因为 我觉得 ORM 框架 顾名思义 对象关系映射框架， 他是用来解决映射的，我只需要操作对象，或者导入的数据，中间的映射应该是这种框架去处理的。 而 mybatis 中间的映射则是我们自己写。 |
 |
77
CaoZ Sep 29, 2017 1
让我没想到的是竟然有这么多人喜欢手写... 别的不知道, 起码在 Python 中 SQLAlchemy 比手写好用太多了, 真心推荐大家来试下~
当然有时候免不了要手写, 比如现在 SQLAlchemy 还不支持一些 MySQL 中的 JSON 操作, 这时候就得用 SQLAlchey 的 text() 功能结合部分原生 SQL 语句了. |
 |
78
starvedcat Sep 29, 2017
二进制程序大家喜欢写高级语言再编译还是手写机器码？请踊跃讨论！
|
 |
79
Vans Sep 29, 2017
手活好当然要手写了！
|
|
80
4BVL25L90W260T9U Sep 29, 2017
django...
|
 |
81
bzzhou Sep 29, 2017
ORM，写出来的语法比 SQL 漂亮
|
|
82
msg7086 Sep 29, 2017 1
@timwei
我这么问你吧。 1. 你知道 conflicts = conflicts.where(protocol: [:udp, :both]) 这里返回的 conflicts 的类型是什么吗？ 2. 你知道上面代码最差的条件路径下会执行几次 SQL 语句吗？ |
|
83
msg7086 Sep 29, 2017 1
@timwei 上面代码里的确有个可以优化的点，那就是 return if empty?应该改成在 first 之后 return unless conflict。
|
 |
84
wekw Sep 29, 2017
ORM 可以大幅提升代码质量，甚至直接把 M 层归零。如果你能理解这句话，恭喜你拿到了高级 web 程序员的入场券。
|
 |
85
tabris17 Sep 29, 2017
GraphQL
|
|
86
tabris17 Sep 29, 2017
用 ORM/ActiceRecord 解决 99%的业务，剩下 1%可以使用原生 SQL
|
 |
87
codeyung Sep 29, 2017
手写
|
 |
88
honkew Sep 29, 2017
ORM 做不到的就手写
|
 |
89
evlos Sep 29, 2017
以前坚持手写了几年，后来只有在联合查询的时候部分手写，大部分用 ORM
|
 |
90
shakoon Sep 29, 2017
手写了十多年 SQL，表示很顺手，没有改变的动力
|
 |
91
greatghoul Sep 29, 2017 via Android
都喜欢
|
 |
92
thisisgpy Sep 29, 2017
Java。我一直用 mybatis 手写 SQL，我承认，我优化不好 ORM，所以选择手写。
|
|
93
timwei Sep 29, 2017 via Android
@msg7086
这检查方法内 conflicts 只用来产生 conflict 做检查 1. 所以用 where 回传 relation，或是用 select 回传 array 都能做到 用 where 还多一次查询。 2. 这个检查方法会增加两次查询，分别是 line3 where/where.not 跟 line5 的判断内 where 而后面说的 first 是指你其实只用了 conflicts 第一个元素，应将 line14 的 first 加在 line5 的 where 后 让你的查询多了 LIMIT 只返回第一个记录或 nil，而不是传回含 N 条记录的 relation 再取第一条记录 |
 |
94
jydeng Sep 29, 2017
一直手写，有时候觉得烦
|
 |
95
zhouyou457 Sep 29, 2017
最开始编程的时候都是手写,后面发现维护起来太痛苦,而且也无法做到数据库的无缝切换。后来，老大在 spring jdbc 上简单的封装了一层，然后使用代码生成器生成代码，感觉很爽，但是复杂逻辑还是要手写。。现在使用 mybatis，能用三方库实现的功能绝对不手写，复杂逻辑写到数据库视图中，mybatis 的 xml 现在看着非常简洁。。说实话，还是得看项目情况和人员配置，如果项目急，人员都是新手，那还是别手写了，影响项目进度。
|
 |
96
ljh0585 Sep 29, 2017
一般跟团队。。
团队走 ORM 那就用 ORM，团队都手写那就大家都手写呗。 |
 |
97
ss0xt Sep 29, 2017
嗯 键盘敲，不手写（滑稽
|
 |
98
monsterxx03 Sep 29, 2017
以前都是 orm, 后来全手写, orm 隐藏了太多细节， 调优的时候很痛苦, 怕手写出注入的，基本用 orm 也能用出注入来.
|
 |
99
aa23 Sep 29, 2017
我喜欢用存储过程
|
 |
100
dremy Sep 29, 2017 via Android
手写 SQL 一时爽，重构火葬场
|
Select Language