说说为什么？还有可以告诉我哪个语言下哪个库超好用吗？想多了解了解，尝试造个轮子，逃...
This topic created in 3329 days ago, the information mentioned may be changed or developed.
Supplement 1 · Sep 28, 2017
orm 最主要的功能是关系数据映射称为程序中的对象，那类似 hibernate 这种多表，各种关联关系都可以进行映射的功能会用的多吗？动态 sql 需求也是非常常见的，你们怎么处理的，哪个库有比较好的支持？
 |
lightzhSep 28, 2017
1
Golang gorm
iOS FMDB 有手写 SQL 也有 ORM，Realm 算 ORM 吧 |
 |
IllBeBackSep 28, 2017
2
手写？等注入吗？
|
 |
esliznSep 28, 2017
4
工作基本手写，有性能要求并且受限于基础环境。
自己的业余项目基本用 orm，eloquent 是个不错的 orm 库 |
 |
FarAheadSep 28, 2017
6
不会手写，只会 ORM
|
 |
undercloudSep 28, 2017
7
一般都用 ORM，构建灵活、底层无关，还有比较方便的防注入
只有在速度有要求，没法优化的情况下才会选择手动构建 sql |
 |
misaka19000Sep 28, 2017
8
很烦 orm，喜欢手写
|
 |
zonghuaSep 28, 2017
9
逐渐少用 MyBatis，微服务不需要复杂查询，使用 Criteria
|
 |
jtsaiSep 28, 2017 via Android
10
自己一般手写，工作看情况
|
 |
keysonaSep 28, 2017
11
开始都会用 orm，最后又会用到手写。
|
 |
lslqtzSep 28, 2017
12
手写
|
 |
Miy4moriSep 28, 2017 via iPhone
13
不喜欢手写 sql，很割裂，不够 oo
|
 |
zhustecSep 28, 2017 via Android
14
难道不是 Active record 吗
|
 |
a87150Sep 28, 2017
16
ORM 不如手写灵活，但是很方便。
|
 |
6ufq0VLZn0DDkL80Sep 28, 2017
17
为啥要手写？手写有啥好处吗
|
 |
sfree2005Sep 28, 2017 via Android
18
当然看需求。当下大部分的操作，ORM 已经做得很好，只有在一些很复杂的操作的时候会手写。
|
 |
ActraceSep 28, 2017
19
ORM 的本质就是常用操作的 SQL 封装。
我觉得常用 SQL 操作都应该封装好，这就牵扯到一种 Model 的概念，在我的项目中，Model 只负责处理数据库操作。 |
 |
ebony0319Sep 28, 2017 via Android
20
面向数据库编程。
|
 |
ericlsSep 28, 2017
21
DSL -> ORM -> 手写
|
 |
u5f20u98deSep 28, 2017
22
手写见过写出注入的，用 ORM 也见过用出注入的，总之变量不绑定好了都会处注入。
不过遇到的手写出注入的多一些。 |
 |
SappSep 28, 2017
24
beego 用的 orm 感觉还可以，但是偶尔还是手写。
|
 |
ErskineSep 28, 2017 via iPad
25
手写 感觉 sql 就是艺术
|
 |
gdtvSep 28, 2017
26
我喜欢手写
|
 |
gefangshuaiSep 28, 2017 via iPhone
27
我喜欢 no sql
|
 |
ZXCDFGTYUSep 28, 2017 via iPad
28
一般来说 ORM 大部分都是支持直接 query/execute sql 的，并且大部分也都支持 bind。我的 php 项目用的是 phalcon 框架，其中自带的 query/execute 方法可以直接 push sql 过去，其中 placeholder 就是用来绑定变量的。
|
 |
HstarSep 28, 2017
29
当然是用 ORM, 按我的理解, ORM 就是帮你生成 SQL 语句的转译器, 所以没有手写能实现但是 ORM 实现不了的情景. 如果遇上个冷门情景没有现成封装好的方法, 那么加一个好了. 手写 SQL 很溜的用 ORM 肯定更没问题.
|
 |
WispZhanSep 28, 2017
30
Code First，ORM 优先。目前是 JPA 用的多。 有必要的话会使用混合 MyBatis 和手写存储过程。
|
 |
zjsxwcSep 28, 2017 via Android
31
能 orm 就 orm，好处多多，代码复用方便，ide 自动推导不会犯错，有可以轻松实现大面积魔改， 实在不行才撸 sql
|
 |
fxxkgwSep 28, 2017 via iPhone
32
混着用，关联查询还是手写方便些个人觉得。。
|
 |
scnaceSep 28, 2017 via Android
33
不知道大家怎么看代码里的大段的 SQL 一段很长的 SQL 执行一次 跟 短 SQL 执行多次 到底哪个好 感觉长 SQL 就建表时候的功力了…
|
 |
simple_planSep 28, 2017
34
混用 单表 orm 多表关联 sql
|
 |
gcloveSep 28, 2017
35
表关联尽量不要用数据库去实现
尽量 ORM 吧, 我感觉就像用 C 和 用汇编的区别一样 |
 |
carlcloneSep 28, 2017 via Android
36
手写的不是大神就是菜鸟，大部分都是菜鸟，写出一堆没法维护的东西
|
 |
EchoUtopiaSep 28, 2017 via iPhone
37
orm 可以很方便的复用数据对象
|
 |
nekuataSep 29, 2017
38
MyBatis 不算 ORM 吧？ Hibernate 也不推荐手写 SQL 而是 HQL
MyBatis & SQL 混用+1 |
 |
incompatibleSep 29, 2017
39
@IllBeBack 什么叫“防注入每次都要做“？ 写 sql 时用?而不是直接拼 where 条件这是基本功好伐？
|
 |
andrewpsySep 29, 2017
40
嫌弃手写的应该都是不怎么写测试的。
我喜欢手写的性能。如果怕哪块手写的 SQL 不好维护，就加上些自动测试代码，性能安全妥妥的。 |
 |
lighteningSep 29, 2017
41
绝大多数情况下用 ORM，需要手写的情况在我职业生涯中应该不超过五次。
手写的维护起来太困难，毕竟写代码的第一目的是可工作，其次是可维护。 ORM 的典范我认为是 Ruby 的 ActiveRecord。 |
|
scnaceSep 29, 2017 via Android
42
|
 |
EricCartmanSep 29, 2017 via Android
43
能 ORM 就 ORM，可维护性太重要
|
 |
hooopoSep 29, 2017
44
OLTP 系统当然 ORM 啦，OLAP 和数据处理相关就手写咯
|
 |
45
同推 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 |
1 |
askfilmSep 29, 2017
46
php + doctrine 带你飞
|
 |
jy02201949Sep 29, 2017
47
手写
|
 |
wombatSep 29, 2017
48
手写 sql
|
 |
taomkSep 29, 2017 via iPhone
49
spring data jpa 基本上只需要继承一下框架提供的模版就可以解决所有的数据库基本操作
|
 |
nullccSep 29, 2017
50
简单查询 ORM，复杂查询手写
|
 |
TangMonkSep 29, 2017
51
ActiveRecord +1
|
 |
jjianwen68Sep 29, 2017
52
用 jpa/hibernate，但只做基本方式的映射，不习惯多表关联，复杂一点的查询就直接 hql 或者原生 sql
|
 |
CuminLoSep 29, 2017
53
喜欢手写 SQL，但是必须绑定参数来查询。
至于为什么，可能是之前受过重构的伤，老项目迁移到新框架那些 ORM 迁移，现在想想都心累..... |
 |
lazypuSep 29, 2017
54
laravel eloquent 蛮爽
|
 |
baoanlolSep 29, 2017
57
用过 hibernate，不好用，后来用 slick，喜欢。。。
|
 |
ybh37Sep 29, 2017
58
还是要看具体的业务场景，如果是实体关系简单的业务，ORM 就很好用。
相反，以下十分复杂的而且对性能有要求，一般会选择 SQL SP |
 |
timweiSep 29, 2017
59
@msg7086
只是做字段筛选为什么用了 conflicts = conflicts.where(protocol: [:udp, :both]) 而不用 conflicts = conflicts.select{|t| [:udp, :both].include? t.protocol } where 方法会多刷了一次 query 呢 |
 |
resturlaubSep 29, 2017
60
直接用 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 好，易理解，爽。建议都要会。 |
 |
zgbgx1Sep 29, 2017
61
性能要求高，还用的是 mysql 这种坑逼数据库的话，还是必须手写 sql
|
 |
imhererSep 29, 2017
62
手写
|
 |
63
我对外说的时候写 SQL，自己大部分是用 ORM。
|
 |
xiaowanggeSep 29, 2017
64
几乎不用 SQL。
 99%场景用腾讯云的 memcached、redis。游戏行业。 |
 |
leekafaiSep 29, 2017 via Android
65
我自己喜欢手写，因为自己写的自己以后看得懂。
同理，我因此不喜欢别人手写，因为别人的我怕看不懂 |
|
timweiSep 29, 2017
66
我也是从 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
orm
在互联网行业 mysql 基本当作持久化的 kv 来用，没有复杂 sql 和关联查询。性能基本不用考虑，绝大多数访问都命中缓存，发生缓存穿透 用 SQL 还是 ORM 基本没啥区别。 |
 |
E2gCaBAT5I87sw1MSep 29, 2017
68
SQL 不利用重构
|
|
timweiSep 29, 2017
69
@msg7086
再提一点 conflicts = conflicts.where(protocol: [:udp, :both]) conflict = conflicts.first 逻辑上会与 conflict.where(protocol: [:udp, :both]).first 一样 可是产生的 SQL 语句会有差别，前者的语句会缺少 LIMIT |
 |
togodoSep 29, 2017
72
小项目手写，大项目 orm
|
 |
coolcoffeeSep 29, 2017
73
感觉 orm 更接近自然语言
|
 |
qiu0130Sep 29, 2017 via Android
74
我们公司的经历，开始 ORM，新项目 自己撸一层参数校验跑 SQL，目前打算改造一下 peewee 重构老项目。
|
 |
TechnetiumerSep 29, 2017 via Android
75
感觉 SQL 才更接近自然语言
一般用查询构造器，部分手写 SQL。 手写 SQL 比较符合我的直觉，查询构造器 /ORM 可以让你方便的跨数据库。 |
 |
zpf124Sep 29, 2017
76
@twogoods 之前有个类似的讨论，不过像我们这样的闲人不是很多。
https://www.zhihu.com/question/39454008 虽然我也更习惯 mybatis 去手写多表联查，但个人觉得 它不算是一个标准的 ORM 框架，功能上它与 ORM 框架可以互相替换。 因为 我觉得 ORM 框架 顾名思义 对象关系映射框架， 他是用来解决映射的，我只需要操作对象，或者导入的数据，中间的映射应该是这种框架去处理的。 而 mybatis 中间的映射则是我们自己写。 |
 |
77
让我没想到的是竟然有这么多人喜欢手写... 别的不知道, 起码在 Python 中 SQLAlchemy 比手写好用太多了, 真心推荐大家来试下~
当然有时候免不了要手写, 比如现在 SQLAlchemy 还不支持一些 MySQL 中的 JSON 操作, 这时候就得用 SQLAlchey 的 text() 功能结合部分原生 SQL 语句了. |
 |
starvedcatSep 29, 2017
78
二进制程序大家喜欢写高级语言再编译还是手写机器码？请踊跃讨论！
|
 |
VansSep 29, 2017
79
手活好当然要手写了！
|
|
4BVL25L90W260T9USep 29, 2017
80
django...
|
 |
bzzhouSep 29, 2017
81
ORM，写出来的语法比 SQL 漂亮
|
|
82
@timwei
我这么问你吧。 1. 你知道 conflicts = conflicts.where(protocol: [:udp, :both]) 这里返回的 conflicts 的类型是什么吗？ 2. 你知道上面代码最差的条件路径下会执行几次 SQL 语句吗？ |
|
83
@timwei 上面代码里的确有个可以优化的点，那就是 return if empty?应该改成在 first 之后 return unless conflict。
|
 |
wekwSep 29, 2017
84
ORM 可以大幅提升代码质量，甚至直接把 M 层归零。如果你能理解这句话，恭喜你拿到了高级 web 程序员的入场券。
|
 |
tabris17Sep 29, 2017
85
GraphQL
|
|
tabris17Sep 29, 2017
86
用 ORM/ActiceRecord 解决 99%的业务，剩下 1%可以使用原生 SQL
|
 |
codeyungSep 29, 2017
87
手写
|
 |
honkewSep 29, 2017
88
ORM 做不到的就手写
|
 |
evlosSep 29, 2017
89
以前坚持手写了几年，后来只有在联合查询的时候部分手写，大部分用 ORM
|
 |
shakoonSep 29, 2017
90
手写了十多年 SQL，表示很顺手，没有改变的动力
|
 |
greatghoulSep 29, 2017 via Android
91
都喜欢
|
 |
thisisgpySep 29, 2017
92
Java。我一直用 mybatis 手写 SQL，我承认，我优化不好 ORM，所以选择手写。
|
|
timweiSep 29, 2017 via Android
93
@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 再取第一条记录 |
 |
jydengSep 29, 2017
94
一直手写，有时候觉得烦
|
 |
zhouyou457Sep 29, 2017
95
最开始编程的时候都是手写,后面发现维护起来太痛苦,而且也无法做到数据库的无缝切换。后来，老大在 spring jdbc 上简单的封装了一层，然后使用代码生成器生成代码，感觉很爽，但是复杂逻辑还是要手写。。现在使用 mybatis，能用三方库实现的功能绝对不手写，复杂逻辑写到数据库视图中，mybatis 的 xml 现在看着非常简洁。。说实话，还是得看项目情况和人员配置，如果项目急，人员都是新手，那还是别手写了，影响项目进度。
|
 |
ljh0585Sep 29, 2017
96
一般跟团队。。
团队走 ORM 那就用 ORM，团队都手写那就大家都手写呗。 |
 |
ss0xtSep 29, 2017
97
嗯 键盘敲，不手写（滑稽
|
 |
monsterxx03Sep 29, 2017
98
以前都是 orm, 后来全手写, orm 隐藏了太多细节， 调优的时候很痛苦, 怕手写出注入的，基本用 orm 也能用出注入来.
|
 |
aa23Sep 29, 2017
99
我喜欢用存储过程
|
 |
dremySep 29, 2017 via Android
100
手写 SQL 一时爽，重构火葬场
|
Select Language