J**B
发帖数: 204 | |
g*****g
发帖数: 34805 | 2 ORM is translated to SQL, it's never gonna beat optimized SQL query. On the
other hand, ORM makes caching easy and in many cases may not hit DB at all.
So it's not necessarily slower overall. It all depends on the application.
【在 J**B 的大作中提到】
: 如题。面试碰到的题。
|
w****u
发帖数: 3147 | 3 可不可以这么说，一个是在数据库内部run，一个是在外面的application server上run
。。。。感觉可说的挺多的 |
B*****g
发帖数: 34098 | 4 前面有讨论，哈哈
run
【在 w****u 的大作中提到】
: 可不可以这么说，一个是在数据库内部run，一个是在外面的application server上run
: 。。。。感觉可说的挺多的
|
J**B
发帖数: 204 | |
g*****g
发帖数: 34805 | 6 ORM is translated to SQL, it's never gonna beat optimized SQL query. On the
other hand, ORM makes caching easy and in many cases may not hit DB at all.
So it's not necessarily slower overall. It all depends on the application.
【在 J**B 的大作中提到】
: 如题。面试碰到的题。
|
w****u
发帖数: 3147 | 7 可不可以这么说，一个是在数据库内部run，一个是在外面的application server上run
。。。。感觉可说的挺多的 |
B*****g
发帖数: 34098 | 8 前面有讨论，哈哈
run
【在 w****u 的大作中提到】
: 可不可以这么说，一个是在数据库内部run，一个是在外面的application server上run
: 。。。。感觉可说的挺多的
|
B*****g
发帖数: 34098 | 9 讨论去哪了？找不到了
【在 B*****g 的大作中提到】
: 前面有讨论，哈哈
:
: run
|
t*******e
发帖数: 684 | 10 出这个题目的十之八九是个biased DBA。如果这个命题成立，还要ORM干什么？ |
|
|
z*******3
发帖数: 13709 | 11 这个命题的确成立，问题在于值不值得为了这一点效率牺牲结构
我一般认为是不值得这么做的，这样做明显增强了对db的依赖
【在 t*******e 的大作中提到】
: 出这个题目的十之八九是个biased DBA。如果这个命题成立，还要ORM干什么？
|
t*******e
发帖数: 684 | 12 ORM自带一层object query to sql的cache，dynamic query在database里面的
execution plan也是cache的。结果就是一样的sql，用ORM和Stored Proc实现没有差别。
见下面的实例。
http://www.blackwasp.co.uk/SpeedTestSqlSproc.aspx
【在 z*******3 的大作中提到】
: 这个命题的确成立，问题在于值不值得为了这一点效率牺牲结构
: 我一般认为是不值得这么做的，这样做明显增强了对db的依赖
|
B*****g
发帖数: 34098 | 13 This test was designed to compare the execution time of dynamically
generated SQL select statements and the equivalent stored procedures from
within a .NET framework application. Single select statements are often used
in stored procedures to retrieve data. This article does not test the used
of complex stored procedures where multiple statements are executed on the
server.
别。
【在 t*******e 的大作中提到】
: ORM自带一层object query to sql的cache，dynamic query在database里面的
: execution plan也是cache的。结果就是一样的sql，用ORM和Stored Proc实现没有差别。
: 见下面的实例。
: http://www.blackwasp.co.uk/SpeedTestSqlSproc.aspx
|
t*******e
发帖数: 684 | 14 This topic could be an endless debate. We need to compare the two techniques
from a common basis. When you move complex computing logic into the stored
proc, you essentially trade OO programming benefits for IO efficiency.
used
used
【在 B*****g 的大作中提到】
: This test was designed to compare the execution time of dynamically
: generated SQL select statements and the equivalent stored procedures from
: within a .NET framework application. Single select statements are often used
: in stored procedures to retrieve data. This article does not test the used
: of complex stored procedures where multiple statements are executed on the
: server.
:
: 别。
|
B*****g
发帖数: 34098 | 15 求以前的讨论，搜不到了，5个包子
【在 B*****g 的大作中提到】
: 前面有讨论，哈哈
:
: run
|
g*****g
发帖数: 34805 | 16 这个我老N年前就总结过了。
ORM的好处，易维护，把计算量迁移应用服务器上，容易处理高并发，缓存简单，可在不
同数据库间移植。在高并发的应用里，关系型数据库本身不能scale out，早晚是个瓶
颈，所以ORM提高了系统能支持的并发数。最近几年NoSQL DB的发展，就是单机数据库
系统在ORM下仍然是瓶颈下的必然道路。
Stored procedure的好处，在低并发，大数据量的一些应用上，如每日产生的报表有离
数据近的优势。但不易维护。近年Oracle在数据库服务器上内建对Java的支持，就是为
了提高可维护性。
SP对单个请求比ORM快几乎是必然的。但100个并发的请求，就不见得一样了，10000个
并发的请求，整一个能撑住的数据库服务器，就要比一个小数据库+一个应用服务器ORM
集群，要贵无数倍。别忘了Oracle之类的数据库是按可比CPU算钱的。
techniques
stored
【在 t*******e 的大作中提到】
: This topic could be an endless debate. We need to compare the two techniques
: from a common basis. When you move complex computing logic into the stored
: proc, you essentially trade OO programming benefits for IO efficiency.
:
: used
: used
|
t*******e
发帖数: 684 | 17 ORM说到底还是dynamic SQL, 所以不可能超越dynamic SQL的performance和throughput
。Performance的好处是多层cache带来的。Portability实际上也不是非常重要。
ORM真正的优势还是在于降低开发成本。聪明的使用lazy loading合并caching的话，对
比sql或stored proc，实现一个网页节省个几千行code是非常常见的。易维护也是个副产
品了。
在不
ORM
【在 g*****g 的大作中提到】
: 这个我老N年前就总结过了。
: ORM的好处，易维护，把计算量迁移应用服务器上，容易处理高并发，缓存简单，可在不
: 同数据库间移植。在高并发的应用里，关系型数据库本身不能scale out，早晚是个瓶
: 颈，所以ORM提高了系统能支持的并发数。最近几年NoSQL DB的发展，就是单机数据库
: 系统在ORM下仍然是瓶颈下的必然道路。
: Stored procedure的好处，在低并发，大数据量的一些应用上，如每日产生的报表有离
: 数据近的优势。但不易维护。近年Oracle在数据库服务器上内建对Java的支持，就是为
: 了提高可维护性。
: SP对单个请求比ORM快几乎是必然的。但100个并发的请求，就不见得一样了，10000个
: 并发的请求，整一个能撑住的数据库服务器，就要比一个小数据库+一个应用服务器ORM
|
g*****g
发帖数: 34805 | 18 Portability对有些系统还是有用的，一些可定制系统可以让用户选择数据库，这个其
实在企业软件里挺常见。性能上我提到了，就是把逻辑从数据库拉出来，降低了数据库
服务器的负担，从而提高了系统可承受的负载。
throughput
副产
【在 t*******e 的大作中提到】
: ORM说到底还是dynamic SQL, 所以不可能超越dynamic SQL的performance和throughput
: 。Performance的好处是多层cache带来的。Portability实际上也不是非常重要。
: ORM真正的优势还是在于降低开发成本。聪明的使用lazy loading合并caching的话，对
: 比sql或stored proc，实现一个网页节省个几千行code是非常常见的。易维护也是个副产
: 品了。
:
: 在不
: ORM
|
z*******3
发帖数: 13709 | 19 有道理
很多时候这种快只是理论上的
理论上用汇编最快，c也肯定比java快
但是如果实现得不三不四的，尤其是并发处理做得不三不四的
那就不好说了，实际上oracle的东西
尤其是oracle的app server，以前一直实现得不三不四的
所以我很怀疑他们对于并发这种大系统的处理能力
不过后来收购了weblogic可能会好点
在不
ORM
【在 g*****g 的大作中提到】
: 这个我老N年前就总结过了。
: ORM的好处，易维护，把计算量迁移应用服务器上，容易处理高并发，缓存简单，可在不
: 同数据库间移植。在高并发的应用里，关系型数据库本身不能scale out，早晚是个瓶
: 颈，所以ORM提高了系统能支持的并发数。最近几年NoSQL DB的发展，就是单机数据库
: 系统在ORM下仍然是瓶颈下的必然道路。
: Stored procedure的好处，在低并发，大数据量的一些应用上，如每日产生的报表有离
: 数据近的优势。但不易维护。近年Oracle在数据库服务器上内建对Java的支持，就是为
: 了提高可维护性。
: SP对单个请求比ORM快几乎是必然的。但100个并发的请求，就不见得一样了，10000个
: 并发的请求，整一个能撑住的数据库服务器，就要比一个小数据库+一个应用服务器ORM
|
z*******3
发帖数: 13709 | 20 不过有时候我觉得这样也挺好
dba愿意主动承担责任，我觉得没啥坏处
我们公司的dba都很认真，所以一般我不去主动抢他们的活干
procedure已经写好的我就用，虽然加强了依赖，呼呼
throughput
副产
【在 t*******e 的大作中提到】
: ORM说到底还是dynamic SQL, 所以不可能超越dynamic SQL的performance和throughput
: 。Performance的好处是多层cache带来的。Portability实际上也不是非常重要。
: ORM真正的优势还是在于降低开发成本。聪明的使用lazy loading合并caching的话，对
: 比sql或stored proc，实现一个网页节省个几千行code是非常常见的。易维护也是个副产
: 品了。
:
: 在不
: ORM
|
|
|
z*******3
发帖数: 13709 | 21 嗯，古德霸的例子还有优化的空间
把web给干掉，不用java写，不要上spring mvc或者是jsf之类的
用php就行，apache http server
便宜得多，然后通过内部网call app server上的web service
便宜，而且如果用ejb的话，并发数量可以控制
写起来也不复杂，嗯，这应该是将来的趋势
然后外层对于非web的，可以用java写一些特殊的server
比如网游的服务器啊之类的，这样一个结构良好清晰的eai就出来了
在不
ORM
【在 g*****g 的大作中提到】
: 这个我老N年前就总结过了。
: ORM的好处，易维护，把计算量迁移应用服务器上，容易处理高并发，缓存简单，可在不
: 同数据库间移植。在高并发的应用里，关系型数据库本身不能scale out，早晚是个瓶
: 颈，所以ORM提高了系统能支持的并发数。最近几年NoSQL DB的发展，就是单机数据库
: 系统在ORM下仍然是瓶颈下的必然道路。
: Stored procedure的好处，在低并发，大数据量的一些应用上，如每日产生的报表有离
: 数据近的优势。但不易维护。近年Oracle在数据库服务器上内建对Java的支持，就是为
: 了提高可维护性。
: SP对单个请求比ORM快几乎是必然的。但100个并发的请求，就不见得一样了，10000个
: 并发的请求，整一个能撑住的数据库服务器，就要比一个小数据库+一个应用服务器ORM
|
t*******e
发帖数: 684 | 22 这样的方法很多年前我也用，有些情况适用，legacy database，很稳定不会变动。项
目就是web enablement之类的。如果schema还在evolve，table又多，dba很快就成了
bottleneck，这时候ORM比stored proc效率就高出数量级了。
【在 z*******3 的大作中提到】
: 不过有时候我觉得这样也挺好
: dba愿意主动承担责任，我觉得没啥坏处
: 我们公司的dba都很认真，所以一般我不去主动抢他们的活干
: procedure已经写好的我就用，虽然加强了依赖，呼呼
:
: throughput
: 副产
|
B*****g
发帖数: 34098 | 23 N年前帖子找不到了，版务不做精华区呀
在不
ORM
【在 g*****g 的大作中提到】
: 这个我老N年前就总结过了。
: ORM的好处，易维护，把计算量迁移应用服务器上，容易处理高并发，缓存简单，可在不
: 同数据库间移植。在高并发的应用里，关系型数据库本身不能scale out，早晚是个瓶
: 颈，所以ORM提高了系统能支持的并发数。最近几年NoSQL DB的发展，就是单机数据库
: 系统在ORM下仍然是瓶颈下的必然道路。
: Stored procedure的好处，在低并发，大数据量的一些应用上，如每日产生的报表有离
: 数据近的优势。但不易维护。近年Oracle在数据库服务器上内建对Java的支持，就是为
: 了提高可维护性。
: SP对单个请求比ORM快几乎是必然的。但100个并发的请求，就不见得一样了，10000个
: 并发的请求，整一个能撑住的数据库服务器，就要比一个小数据库+一个应用服务器ORM
|
B*****g
发帖数: 34098 | 24 ORM问个问题，ORM能控制 execution plan 吗？
在不
ORM
【在 g*****g 的大作中提到】
: 这个我老N年前就总结过了。
: ORM的好处，易维护，把计算量迁移应用服务器上，容易处理高并发，缓存简单，可在不
: 同数据库间移植。在高并发的应用里，关系型数据库本身不能scale out，早晚是个瓶
: 颈，所以ORM提高了系统能支持的并发数。最近几年NoSQL DB的发展，就是单机数据库
: 系统在ORM下仍然是瓶颈下的必然道路。
: Stored procedure的好处，在低并发，大数据量的一些应用上，如每日产生的报表有离
: 数据近的优势。但不易维护。近年Oracle在数据库服务器上内建对Java的支持，就是为
: 了提高可维护性。
: SP对单个请求比ORM快几乎是必然的。但100个并发的请求，就不见得一样了，10000个
: 并发的请求，整一个能撑住的数据库服务器，就要比一个小数据库+一个应用服务器ORM
|
g*****g
发帖数: 34805 | 25 I don't think so. ORM is basically auto-generated SQL queries.
【在 B*****g 的大作中提到】
: ORM问个问题，ORM能控制 execution plan 吗？
:
: 在不
: ORM
|
t*******e
发帖数: 684 | 26 翻老帖子不容易。零零碎碎的很多帖子里都讨论了这个问题的不同方面。
ORM学好用好不容易。几乎可以认为是server side最复杂的技术。没有个3-5年的学习
实践，不要说自己懂ORM。事情的另一方面就是一旦上手，就会爱不释手。绝对是steep
learning curve but with high payback.
【在 B*****g 的大作中提到】
: N年前帖子找不到了，版务不做精华区呀
:
: 在不
: ORM
|
z*******3
发帖数: 13709 | 27 那当然
毕竟db和web什么都不应该是复杂逻辑集中的地方
最终还是要把这部分给压给spring或者ejb去做
而且抽出来之后，可以优化的地方就多了
分层的好处就在于每一个component都只做一件事
然后集中管理，然后根据特点进行优化
但是这个都是大系统才适用，小系统，随便啦
用jsp去访问db也未尝不行嘛
【在 t*******e 的大作中提到】
: 这样的方法很多年前我也用，有些情况适用，legacy database，很稳定不会变动。项
: 目就是web enablement之类的。如果schema还在evolve，table又多，dba很快就成了
: bottleneck，这时候ORM比stored proc效率就高出数量级了。
|
z*******3
发帖数: 13709 | 28 jpa怎么会是最复杂的
我觉得jta，涉及到transaction的部分才是最恶心的
不过不管怎样，jee除了web的部分都挺恶心的
jms和validation算是比较简单的，jta和web service是最恶心的两个部分
不过都不如connector恶心
steep
【在 t*******e 的大作中提到】
: 翻老帖子不容易。零零碎碎的很多帖子里都讨论了这个问题的不同方面。
: ORM学好用好不容易。几乎可以认为是server side最复杂的技术。没有个3-5年的学习
: 实践，不要说自己懂ORM。事情的另一方面就是一旦上手，就会爱不释手。绝对是steep
: learning curve but with high payback.
|
