S*h
2 楼
本人理论物理 Ph.D毕业,拿到一个做 Logistics forecasting 的软件公司offer,
research (optimization, statistics) 兼一些developer (Oracle pl). 我另有一
个一般金融模型+developer (mostly in Java)的 offer, 在一个大公司(非Wall
street), 两个薪水差不多 (10万+一点奖金<20%)。个人原来选过一些金融的课,
所以金融方面比较了解,前途很清楚,算是按部就班. Supply chain forecasting不了
解。听他们的介绍,似乎发展潜力很大,公司不大(~200),现在做 comsumer goods
produce的Supply chain forecasting,雄心勃勃的准备进入其他商品门类,公司十年
了,发展挺快。感觉如果从了他们,象赌start-up。请教一下懂行的同学,本人java很
熟, 单纯从编程角度,oracle PL 前景如何?
先谢谢了。
research (optimization, statistics) 兼一些developer (Oracle pl). 我另有一
个一般金融模型+developer (mostly in Java)的 offer, 在一个大公司(非Wall
street), 两个薪水差不多 (10万+一点奖金<20%)。个人原来选过一些金融的课,
所以金融方面比较了解,前途很清楚,算是按部就班. Supply chain forecasting不了
解。听他们的介绍,似乎发展潜力很大,公司不大(~200),现在做 comsumer goods
produce的Supply chain forecasting,雄心勃勃的准备进入其他商品门类,公司十年
了,发展挺快。感觉如果从了他们,象赌start-up。请教一下懂行的同学,本人java很
熟, 单纯从编程角度,oracle PL 前景如何?
先谢谢了。
s*l
3 楼
谢谢
书或者ppt都行
书或者ppt都行
B*g
5 楼
what is oracle PL?
goods
【在 S****h 的大作中提到】
: 本人理论物理 Ph.D毕业,拿到一个做 Logistics forecasting 的软件公司offer,
: research (optimization, statistics) 兼一些developer (Oracle pl). 我另有一
: 个一般金融模型+developer (mostly in Java)的 offer, 在一个大公司(非Wall
: street), 两个薪水差不多 (10万+一点奖金<20%)。个人原来选过一些金融的课,
: 所以金融方面比较了解,前途很清楚,算是按部就班. Supply chain forecasting不了
: 解。听他们的介绍,似乎发展潜力很大,公司不大(~200),现在做 comsumer goods
: produce的Supply chain forecasting,雄心勃勃的准备进入其他商品门类,公司十年
: 了,发展挺快。感觉如果从了他们,象赌start-up。请教一下懂行的同学,本人java很
: 熟, 单纯从编程角度,oracle PL 前景如何?
: 先谢谢了。
goods
【在 S****h 的大作中提到】
: 本人理论物理 Ph.D毕业,拿到一个做 Logistics forecasting 的软件公司offer,
: research (optimization, statistics) 兼一些developer (Oracle pl). 我另有一
: 个一般金融模型+developer (mostly in Java)的 offer, 在一个大公司(非Wall
: street), 两个薪水差不多 (10万+一点奖金<20%)。个人原来选过一些金融的课,
: 所以金融方面比较了解,前途很清楚,算是按部就班. Supply chain forecasting不了
: 解。听他们的介绍,似乎发展潜力很大,公司不大(~200),现在做 comsumer goods
: produce的Supply chain forecasting,雄心勃勃的准备进入其他商品门类,公司十年
: 了,发展挺快。感觉如果从了他们,象赌start-up。请教一下懂行的同学,本人java很
: 熟, 单纯从编程角度,oracle PL 前景如何?
: 先谢谢了。
g*g
7 楼
Do you mean PL/SQL?
goods
【在 S****h 的大作中提到】
: 本人理论物理 Ph.D毕业,拿到一个做 Logistics forecasting 的软件公司offer,
: research (optimization, statistics) 兼一些developer (Oracle pl). 我另有一
: 个一般金融模型+developer (mostly in Java)的 offer, 在一个大公司(非Wall
: street), 两个薪水差不多 (10万+一点奖金<20%)。个人原来选过一些金融的课,
: 所以金融方面比较了解,前途很清楚,算是按部就班. Supply chain forecasting不了
: 解。听他们的介绍,似乎发展潜力很大,公司不大(~200),现在做 comsumer goods
: produce的Supply chain forecasting,雄心勃勃的准备进入其他商品门类,公司十年
: 了,发展挺快。感觉如果从了他们,象赌start-up。请教一下懂行的同学,本人java很
: 熟, 单纯从编程角度,oracle PL 前景如何?
: 先谢谢了。
goods
【在 S****h 的大作中提到】
: 本人理论物理 Ph.D毕业,拿到一个做 Logistics forecasting 的软件公司offer,
: research (optimization, statistics) 兼一些developer (Oracle pl). 我另有一
: 个一般金融模型+developer (mostly in Java)的 offer, 在一个大公司(非Wall
: street), 两个薪水差不多 (10万+一点奖金<20%)。个人原来选过一些金融的课,
: 所以金融方面比较了解,前途很清楚,算是按部就班. Supply chain forecasting不了
: 解。听他们的介绍,似乎发展潜力很大,公司不大(~200),现在做 comsumer goods
: produce的Supply chain forecasting,雄心勃勃的准备进入其他商品门类,公司十年
: 了,发展挺快。感觉如果从了他们,象赌start-up。请教一下懂行的同学,本人java很
: 熟, 单纯从编程角度,oracle PL 前景如何?
: 先谢谢了。
t*t
8 楼
挺好, 就是字和框不太相配, 换个框也许更好.
S*h
9 楼
yeah
S*t
14 楼
赞阿.虽然不懂,还是觉得好.
另外,这是普通毛笔写的吗?为什么也有一种篆刻一样硬朗的感觉呢?
另外,这是普通毛笔写的吗?为什么也有一种篆刻一样硬朗的感觉呢?
S*h
27 楼
En. The company told me that they were using PL/SQL at the moment mostly
for performance. They are trying to move some codes to JAVA w/ Oracle JVM,
which is still tightly bound with database and therefore faster than
standard jvm w/jdbc. But they said that it is still slower than PL/SQL. So
majority will probably stay in PL/SQL.
Anyway, I chose the other firm, mostly because I have quite some experience
with finance. Well, I got to keep working on Java mostly. :) Thanks for
all the advises and opinions. They are really useful.
for performance. They are trying to move some codes to JAVA w/ Oracle JVM,
which is still tightly bound with database and therefore faster than
standard jvm w/jdbc. But they said that it is still slower than PL/SQL. So
majority will probably stay in PL/SQL.
Anyway, I chose the other firm, mostly because I have quite some experience
with finance. Well, I got to keep working on Java mostly. :) Thanks for
all the advises and opinions. They are really useful.
s*e
28 楼
我原来在软件公司做产品的时候,的确不太关心数据库的性能,data layer给了API,
照着写就行了(那个时候hibernate还不流行,ORM都是自家写的)。但是后来转到非软
件公司做architect,就没这么超脱了,性能就是自己的责任了,推也推不掉呀。我们
的data每天都有大量新的进来,最多一天400million rows,而且很多处理都是time
sensitive的,除了DBA做的优化之外,很多预处理都要靠stored procedure。不过这个
好像是不太值得专门做,自己看看书,再偶尔问问DBA,貌似也够用了。
【在 B*****g 的大作中提到】
: 性能对公司有用,对我来说我只关心我的paycheck。凭嘛俺们oracle developer没有人
: 家java developer挣得多?至于你说的技术问题java如何解决,等java大牛来回答。
: 对于能力比较强新人来说,如果没有特殊偏好,当然是哪个工作多工资高就学哪个。对
: 于能力不是很强的新人来说,只能是能学哪个学哪个。
照着写就行了(那个时候hibernate还不流行,ORM都是自家写的)。但是后来转到非软
件公司做architect,就没这么超脱了,性能就是自己的责任了,推也推不掉呀。我们
的data每天都有大量新的进来,最多一天400million rows,而且很多处理都是time
sensitive的,除了DBA做的优化之外,很多预处理都要靠stored procedure。不过这个
好像是不太值得专门做,自己看看书,再偶尔问问DBA,貌似也够用了。
【在 B*****g 的大作中提到】
: 性能对公司有用,对我来说我只关心我的paycheck。凭嘛俺们oracle developer没有人
: 家java developer挣得多?至于你说的技术问题java如何解决,等java大牛来回答。
: 对于能力比较强新人来说,如果没有特殊偏好,当然是哪个工作多工资高就学哪个。对
: 于能力不是很强的新人来说,只能是能学哪个学哪个。
B*g
31 楼
俺们公司也一样,只要是java team搞出来的东西,第一开发时间长,第二performance
差,不过公司舍不得花钱请真牛好虫一类的,不知道请java大牛能不能改善。至于俺们
工资就更低了。
另外你为啥会来java版?如果没加入cinaoug,加一个吧。
【在 s*******e 的大作中提到】
: 我原来在软件公司做产品的时候,的确不太关心数据库的性能,data layer给了API,
: 照着写就行了(那个时候hibernate还不流行,ORM都是自家写的)。但是后来转到非软
: 件公司做architect,就没这么超脱了,性能就是自己的责任了,推也推不掉呀。我们
: 的data每天都有大量新的进来,最多一天400million rows,而且很多处理都是time
: sensitive的,除了DBA做的优化之外,很多预处理都要靠stored procedure。不过这个
: 好像是不太值得专门做,自己看看书,再偶尔问问DBA,貌似也够用了。
差,不过公司舍不得花钱请真牛好虫一类的,不知道请java大牛能不能改善。至于俺们
工资就更低了。
另外你为啥会来java版?如果没加入cinaoug,加一个吧。
【在 s*******e 的大作中提到】
: 我原来在软件公司做产品的时候,的确不太关心数据库的性能,data layer给了API,
: 照着写就行了(那个时候hibernate还不流行,ORM都是自家写的)。但是后来转到非软
: 件公司做architect,就没这么超脱了,性能就是自己的责任了,推也推不掉呀。我们
: 的data每天都有大量新的进来,最多一天400million rows,而且很多处理都是time
: sensitive的,除了DBA做的优化之外,很多预处理都要靠stored procedure。不过这个
: 好像是不太值得专门做,自己看看书,再偶尔问问DBA,貌似也够用了。
g*g
35 楼
This is true and false, while stored procedure doesn't need to move
data around, the computation power on the DB server is relatively
weak, hard to scale, and expensive for every CPU added. Not to mention,
PL/SQL SP is hard to maintain.
So while there's certain area stored procedure can be useful (like report)
but the trend is moving out of it. People are using ORM to replace SP,
Hadoop to speed up processing in a cluster, NoSQL DB to replace relational
DB for lower cost and higher throughput. Even Oralce now has API to
write stored procedure in Java rather thant PL/SQL.
At the end of the data, PL/SQL is bad in 3 areas.
1. Oracle is expensive and cluster Oracle is even more expensive
2. PL/SQL is meant to run on single machine, scalability is a suspect.
3. PL/SQL is hard to maintain.
【在 s*******e 的大作中提到】
: 用java做,虽然功能上可以一样,但是性能上没法比吧,尤其是我们有些app动辄上千
: 万行data的,用PL处理一下一点压力都没有,用java搬进搬出就杯具了
data around, the computation power on the DB server is relatively
weak, hard to scale, and expensive for every CPU added. Not to mention,
PL/SQL SP is hard to maintain.
So while there's certain area stored procedure can be useful (like report)
but the trend is moving out of it. People are using ORM to replace SP,
Hadoop to speed up processing in a cluster, NoSQL DB to replace relational
DB for lower cost and higher throughput. Even Oralce now has API to
write stored procedure in Java rather thant PL/SQL.
At the end of the data, PL/SQL is bad in 3 areas.
1. Oracle is expensive and cluster Oracle is even more expensive
2. PL/SQL is meant to run on single machine, scalability is a suspect.
3. PL/SQL is hard to maintain.
【在 s*******e 的大作中提到】
: 用java做,虽然功能上可以一样,但是性能上没法比吧,尤其是我们有些app动辄上千
: 万行data的,用PL处理一下一点压力都没有,用java搬进搬出就杯具了
B*g
36 楼
你写篇文章详细比较一下吧。另外,plsql也可以在其他server上run。
【在 g*****g 的大作中提到】
: This is true and false, while stored procedure doesn't need to move
: data around, the computation power on the DB server is relatively
: weak, hard to scale, and expensive for every CPU added. Not to mention,
: PL/SQL SP is hard to maintain.
: So while there's certain area stored procedure can be useful (like report)
: but the trend is moving out of it. People are using ORM to replace SP,
: Hadoop to speed up processing in a cluster, NoSQL DB to replace relational
: DB for lower cost and higher throughput. Even Oralce now has API to
: write stored procedure in Java rather thant PL/SQL.
: At the end of the data, PL/SQL is bad in 3 areas.
【在 g*****g 的大作中提到】
: This is true and false, while stored procedure doesn't need to move
: data around, the computation power on the DB server is relatively
: weak, hard to scale, and expensive for every CPU added. Not to mention,
: PL/SQL SP is hard to maintain.
: So while there's certain area stored procedure can be useful (like report)
: but the trend is moving out of it. People are using ORM to replace SP,
: Hadoop to speed up processing in a cluster, NoSQL DB to replace relational
: DB for lower cost and higher throughput. Even Oralce now has API to
: write stored procedure in Java rather thant PL/SQL.
: At the end of the data, PL/SQL is bad in 3 areas.
B*g
38 楼
oracle application server应该可以run plsql,是免费的,不过一般通过form/apex
等实现,要是直接call store procedure恐怕够呛,没试过,而且performance和在db
server上没法比。timesten也应该可以run plsql,in-mem DB和真的DB差不多,不知道
performance如何,不过这个不免费。大部分人还是在DB server上run store
procedure。
【在 g*****g 的大作中提到】
: 我对PL/SQL的了解不够,不过Oracle RAC又贵又复杂是肯定的。
: 相比而言,在应用层做clustering现成的架构很多,机器又便宜。
: 我见过的应用,优化到最后大部分瓶颈都在DB上,所以这是个问题。
等实现,要是直接call store procedure恐怕够呛,没试过,而且performance和在db
server上没法比。timesten也应该可以run plsql,in-mem DB和真的DB差不多,不知道
performance如何,不过这个不免费。大部分人还是在DB server上run store
procedure。
【在 g*****g 的大作中提到】
: 我对PL/SQL的了解不够,不过Oracle RAC又贵又复杂是肯定的。
: 相比而言,在应用层做clustering现成的架构很多,机器又便宜。
: 我见过的应用,优化到最后大部分瓶颈都在DB上,所以这是个问题。
s*e
39 楼
very good insights. thanks for sharing.
【在 g*****g 的大作中提到】
: This is true and false, while stored procedure doesn't need to move
: data around, the computation power on the DB server is relatively
: weak, hard to scale, and expensive for every CPU added. Not to mention,
: PL/SQL SP is hard to maintain.
: So while there's certain area stored procedure can be useful (like report)
: but the trend is moving out of it. People are using ORM to replace SP,
: Hadoop to speed up processing in a cluster, NoSQL DB to replace relational
: DB for lower cost and higher throughput. Even Oralce now has API to
: write stored procedure in Java rather thant PL/SQL.
: At the end of the data, PL/SQL is bad in 3 areas.
【在 g*****g 的大作中提到】
: This is true and false, while stored procedure doesn't need to move
: data around, the computation power on the DB server is relatively
: weak, hard to scale, and expensive for every CPU added. Not to mention,
: PL/SQL SP is hard to maintain.
: So while there's certain area stored procedure can be useful (like report)
: but the trend is moving out of it. People are using ORM to replace SP,
: Hadoop to speed up processing in a cluster, NoSQL DB to replace relational
: DB for lower cost and higher throughput. Even Oralce now has API to
: write stored procedure in Java rather thant PL/SQL.
: At the end of the data, PL/SQL is bad in 3 areas.
B*g
40 楼
3能解释一下吗?
3. PL/SQL is hard to maintain.
【在 g*****g 的大作中提到】
: This is true and false, while stored procedure doesn't need to move
: data around, the computation power on the DB server is relatively
: weak, hard to scale, and expensive for every CPU added. Not to mention,
: PL/SQL SP is hard to maintain.
: So while there's certain area stored procedure can be useful (like report)
: but the trend is moving out of it. People are using ORM to replace SP,
: Hadoop to speed up processing in a cluster, NoSQL DB to replace relational
: DB for lower cost and higher throughput. Even Oralce now has API to
: write stored procedure in Java rather thant PL/SQL.
: At the end of the data, PL/SQL is bad in 3 areas.
3. PL/SQL is hard to maintain.
【在 g*****g 的大作中提到】
: This is true and false, while stored procedure doesn't need to move
: data around, the computation power on the DB server is relatively
: weak, hard to scale, and expensive for every CPU added. Not to mention,
: PL/SQL SP is hard to maintain.
: So while there's certain area stored procedure can be useful (like report)
: but the trend is moving out of it. People are using ORM to replace SP,
: Hadoop to speed up processing in a cluster, NoSQL DB to replace relational
: DB for lower cost and higher throughput. Even Oralce now has API to
: write stored procedure in Java rather thant PL/SQL.
: At the end of the data, PL/SQL is bad in 3 areas.
g*g
41 楼
When you compare PL/SQL to java, it's certainly harder to maintain.
Worse debugging tools, worse file organization, worse 3rd party
libraries and tools. Now I am not talking about a java stored procedure,
but an ORM vs. PL/SQL stored procedure approach.
【在 B*****g 的大作中提到】
: 3能解释一下吗?
: 3. PL/SQL is hard to maintain.
Worse debugging tools, worse file organization, worse 3rd party
libraries and tools. Now I am not talking about a java stored procedure,
but an ORM vs. PL/SQL stored procedure approach.
【在 B*****g 的大作中提到】
: 3能解释一下吗?
: 3. PL/SQL is hard to maintain.
B*g
42 楼
debugging tools--toad/SQL developer(确实99%PL/SQL developer不会debug。呵呵),
but they are for develop, not for maintain.
file organization--No file, so no maintain required
worse 3rd party libraries--No has, so no maintain required
worse 3rd party tools--toad/SQL developer, can not compete which Eclipse,
but they are for develop, not for maintain.
在我看来问题主要就是2,而且无法解决。
至于3,我认为问题在于以下
1 dependency,特别是oracle11g之前,一塌糊涂,oracle11gR2基本没问题。
2 DBA不给developer权限,developer自己写的程序除了开发环境自己看不到,而DBA又
不知道有啥SP。
关于1,俺不关心,能用oracle的公司有的是钱,把项目搞大大家才能涨工资。
【在 g*****g 的大作中提到】
: When you compare PL/SQL to java, it's certainly harder to maintain.
: Worse debugging tools, worse file organization, worse 3rd party
: libraries and tools. Now I am not talking about a java stored procedure,
: but an ORM vs. PL/SQL stored procedure approach.
but they are for develop, not for maintain.
file organization--No file, so no maintain required
worse 3rd party libraries--No has, so no maintain required
worse 3rd party tools--toad/SQL developer, can not compete which Eclipse,
but they are for develop, not for maintain.
在我看来问题主要就是2,而且无法解决。
至于3,我认为问题在于以下
1 dependency,特别是oracle11g之前,一塌糊涂,oracle11gR2基本没问题。
2 DBA不给developer权限,developer自己写的程序除了开发环境自己看不到,而DBA又
不知道有啥SP。
关于1,俺不关心,能用oracle的公司有的是钱,把项目搞大大家才能涨工资。
【在 g*****g 的大作中提到】
: When you compare PL/SQL to java, it's certainly harder to maintain.
: Worse debugging tools, worse file organization, worse 3rd party
: libraries and tools. Now I am not talking about a java stored procedure,
: but an ORM vs. PL/SQL stored procedure approach.
g*g
43 楼
别忘了很重要的一条,性能。Data intensive的应用用Stored Procedure说得
过去。诸如eCommerce的常见应用,数据关联上并不见得很复杂。比如下个单子,
不需要查几个表。如果全部用Java/PHP etc. 去调SP。caching
没法做,开发也慢。用ORM就可以尽量把计算放着application server上,clustering
容易,caching容易,大部分应用都用的tomcat之类,也没有licensing cost。我看到
的很多是用ORM做business logic,用SP去做overnight report.
),
【在 B*****g 的大作中提到】
: debugging tools--toad/SQL developer(确实99%PL/SQL developer不会debug。呵呵),
: but they are for develop, not for maintain.
: file organization--No file, so no maintain required
: worse 3rd party libraries--No has, so no maintain required
: worse 3rd party tools--toad/SQL developer, can not compete which Eclipse,
: but they are for develop, not for maintain.
: 在我看来问题主要就是2,而且无法解决。
: 至于3,我认为问题在于以下
: 1 dependency,特别是oracle11g之前,一塌糊涂,oracle11gR2基本没问题。
: 2 DBA不给developer权限,developer自己写的程序除了开发环境自己看不到,而DBA又
过去。诸如eCommerce的常见应用,数据关联上并不见得很复杂。比如下个单子,
不需要查几个表。如果全部用Java/PHP etc. 去调SP。caching
没法做,开发也慢。用ORM就可以尽量把计算放着application server上,clustering
容易,caching容易,大部分应用都用的tomcat之类,也没有licensing cost。我看到
的很多是用ORM做business logic,用SP去做overnight report.
),
【在 B*****g 的大作中提到】
: debugging tools--toad/SQL developer(确实99%PL/SQL developer不会debug。呵呵),
: but they are for develop, not for maintain.
: file organization--No file, so no maintain required
: worse 3rd party libraries--No has, so no maintain required
: worse 3rd party tools--toad/SQL developer, can not compete which Eclipse,
: but they are for develop, not for maintain.
: 在我看来问题主要就是2,而且无法解决。
: 至于3,我认为问题在于以下
: 1 dependency,特别是oracle11g之前,一塌糊涂,oracle11gR2基本没问题。
: 2 DBA不给developer权限,developer自己写的程序除了开发环境自己看不到,而DBA又
B*g
44 楼
eCommerce在我看来就不该用oracle,mysql足够了(mysql也有SP,哈哈)。这个贴子
在这讨论反响不大,移到CINAOUG吧,上百砖头会扔过来。
【在 g*****g 的大作中提到】
: 别忘了很重要的一条,性能。Data intensive的应用用Stored Procedure说得
: 过去。诸如eCommerce的常见应用,数据关联上并不见得很复杂。比如下个单子,
: 不需要查几个表。如果全部用Java/PHP etc. 去调SP。caching
: 没法做,开发也慢。用ORM就可以尽量把计算放着application server上,clustering
: 容易,caching容易,大部分应用都用的tomcat之类,也没有licensing cost。我看到
: 的很多是用ORM做business logic,用SP去做overnight report.
:
: ),
在这讨论反响不大,移到CINAOUG吧,上百砖头会扔过来。
【在 g*****g 的大作中提到】
: 别忘了很重要的一条,性能。Data intensive的应用用Stored Procedure说得
: 过去。诸如eCommerce的常见应用,数据关联上并不见得很复杂。比如下个单子,
: 不需要查几个表。如果全部用Java/PHP etc. 去调SP。caching
: 没法做,开发也慢。用ORM就可以尽量把计算放着application server上,clustering
: 容易,caching容易,大部分应用都用的tomcat之类,也没有licensing cost。我看到
: 的很多是用ORM做business logic,用SP去做overnight report.
:
: ),
B*g
48 楼
http://www.mitbbs.com/article_t2/Database/31148641.html
SP!=PL/SQL,前一阵溜了一眼oracle cloud,似乎可以用Java,也可以用Apex。
另外对于cloud来讲,vendor肯定不喜欢sp,用死resource又不给钱,哈哈。
【在 r*****s 的大作中提到】
: i fully second goodbug's points.
: 我咋觉得这SP vs Java的讨论不是月经也是鸡精贴了?
: 从市场角度:
: SP是不太符合现在cloud computing的政策精神的,
: 钱也都让Oracle赚去了,
: 大家活不活啦?
: 还有,
: 您这个cinaoug在哪?
SP!=PL/SQL,前一阵溜了一眼oracle cloud,似乎可以用Java,也可以用Apex。
另外对于cloud来讲,vendor肯定不喜欢sp,用死resource又不给钱,哈哈。
【在 r*****s 的大作中提到】
: i fully second goodbug's points.
: 我咋觉得这SP vs Java的讨论不是月经也是鸡精贴了?
: 从市场角度:
: SP是不太符合现在cloud computing的政策精神的,
: 钱也都让Oracle赚去了,
: 大家活不活啦?
: 还有,
: 您这个cinaoug在哪?
r*s
49 楼
SP includes PL/SQL, but specific to ORacle,
cloud computing doesn't like sp due to the scalability reason
as stated by goodbug:
if it is not easy to scale/duplicate,
what's the point using cloud?
cloud infrastracture provider doesn't care,
you may pay for your CPU usage.
【在 B*****g 的大作中提到】
: http://www.mitbbs.com/article_t2/Database/31148641.html
: SP!=PL/SQL,前一阵溜了一眼oracle cloud,似乎可以用Java,也可以用Apex。
: 另外对于cloud来讲,vendor肯定不喜欢sp,用死resource又不给钱,哈哈。
cloud computing doesn't like sp due to the scalability reason
as stated by goodbug:
if it is not easy to scale/duplicate,
what's the point using cloud?
cloud infrastracture provider doesn't care,
you may pay for your CPU usage.
【在 B*****g 的大作中提到】
: http://www.mitbbs.com/article_t2/Database/31148641.html
: SP!=PL/SQL,前一阵溜了一眼oracle cloud,似乎可以用Java,也可以用Apex。
: 另外对于cloud来讲,vendor肯定不喜欢sp,用死resource又不给钱,哈哈。
B*g
50 楼
不能scale/duplicate的原因是db license太贵,用cloud需要时加一个在RAC上应该不
是很难,几十秒可能就搞定了,而且费用降得很多,你运行java也得付CPU的钱。SP的
问题主要是大量使用DB的cpu/memory,对于用户来说cloud提供的最够了,对于vendor
来说所有resource都被你用了其他人就没得用了。
至于oracle的SP,不可能包括PLSQL。PLSQL可以用的的地方很多。Oracle SP只不过主
要是通过PLSQL实现的,其实Oracle的SP还可能是用java写的。俺自己都写过java的SP
处理server上数据文件,为啥非要用SP,坑爹政府DBA不允许其他server连数据库。
【在 r*****s 的大作中提到】
: SP includes PL/SQL, but specific to ORacle,
: cloud computing doesn't like sp due to the scalability reason
: as stated by goodbug:
: if it is not easy to scale/duplicate,
: what's the point using cloud?
: cloud infrastracture provider doesn't care,
: you may pay for your CPU usage.
是很难,几十秒可能就搞定了,而且费用降得很多,你运行java也得付CPU的钱。SP的
问题主要是大量使用DB的cpu/memory,对于用户来说cloud提供的最够了,对于vendor
来说所有resource都被你用了其他人就没得用了。
至于oracle的SP,不可能包括PLSQL。PLSQL可以用的的地方很多。Oracle SP只不过主
要是通过PLSQL实现的,其实Oracle的SP还可能是用java写的。俺自己都写过java的SP
处理server上数据文件,为啥非要用SP,坑爹政府DBA不允许其他server连数据库。
【在 r*****s 的大作中提到】
: SP includes PL/SQL, but specific to ORacle,
: cloud computing doesn't like sp due to the scalability reason
: as stated by goodbug:
: if it is not easy to scale/duplicate,
: what's the point using cloud?
: cloud infrastracture provider doesn't care,
: you may pay for your CPU usage.
g*g
53 楼
It's a bit of everything.
1. Relational DB doesn't scale that well compared to NoSQL due to
transaction
support requirement. More DB nodes will certainly degrade performance. How
bad
is probably dependent on how data can be partitioned. On the other hand,
transaction support is a requirement for most non-trivial websites
nontheless.
2. Oracle license is very expensive, you pay for every CPU added to that.
Once I notice DB a performance issue and I asked DBA to segment the data,
and
I was told we'd need to pay extra $$$ if we did that too. On the other hand,
typical stack on a cluster has little to no license fee. Linux+Tomcat+Spring
+Hibernate stack, for example, is popular and free.
3. Caching, caching is probably single most effective mechanism to improve
throughput. And caching is expensive on DB server due to its centric
approach.
SSD array is very expensive. On the other hand, when caching is done on
application server. You can have distributed approach and it's typically
much cheaper.
vendor
SP
【在 B*****g 的大作中提到】
: 不能scale/duplicate的原因是db license太贵,用cloud需要时加一个在RAC上应该不
: 是很难,几十秒可能就搞定了,而且费用降得很多,你运行java也得付CPU的钱。SP的
: 问题主要是大量使用DB的cpu/memory,对于用户来说cloud提供的最够了,对于vendor
: 来说所有resource都被你用了其他人就没得用了。
: 至于oracle的SP,不可能包括PLSQL。PLSQL可以用的的地方很多。Oracle SP只不过主
: 要是通过PLSQL实现的,其实Oracle的SP还可能是用java写的。俺自己都写过java的SP
: 处理server上数据文件,为啥非要用SP,坑爹政府DBA不允许其他server连数据库。
1. Relational DB doesn't scale that well compared to NoSQL due to
transaction
support requirement. More DB nodes will certainly degrade performance. How
bad
is probably dependent on how data can be partitioned. On the other hand,
transaction support is a requirement for most non-trivial websites
nontheless.
2. Oracle license is very expensive, you pay for every CPU added to that.
Once I notice DB a performance issue and I asked DBA to segment the data,
and
I was told we'd need to pay extra $$$ if we did that too. On the other hand,
typical stack on a cluster has little to no license fee. Linux+Tomcat+Spring
+Hibernate stack, for example, is popular and free.
3. Caching, caching is probably single most effective mechanism to improve
throughput. And caching is expensive on DB server due to its centric
approach.
SSD array is very expensive. On the other hand, when caching is done on
application server. You can have distributed approach and it's typically
much cheaper.
vendor
SP
【在 B*****g 的大作中提到】
: 不能scale/duplicate的原因是db license太贵,用cloud需要时加一个在RAC上应该不
: 是很难,几十秒可能就搞定了,而且费用降得很多,你运行java也得付CPU的钱。SP的
: 问题主要是大量使用DB的cpu/memory,对于用户来说cloud提供的最够了,对于vendor
: 来说所有resource都被你用了其他人就没得用了。
: 至于oracle的SP,不可能包括PLSQL。PLSQL可以用的的地方很多。Oracle SP只不过主
: 要是通过PLSQL实现的,其实Oracle的SP还可能是用java写的。俺自己都写过java的SP
: 处理server上数据文件,为啥非要用SP,坑爹政府DBA不允许其他server连数据库。
B*g
54 楼
你说的这都是relational database的缺点,和plsql自身没关系。对大多数公司来说一
时半会都不会用NoSQL数据库,而且你自己也说过NoSQL数据库的缺点。另外也不用老把
钱拿出来说,用oracle的公司有的是钱,没钱就去用mysql。坑爹美国政府100+个table
的数据库也要用oracle。
你搞个NoSql的讲座吧,很多人其实还不是很清楚咋回事。
【在 g*****g 的大作中提到】
: It's a bit of everything.
: 1. Relational DB doesn't scale that well compared to NoSQL due to
: transaction
: support requirement. More DB nodes will certainly degrade performance. How
: bad
: is probably dependent on how data can be partitioned. On the other hand,
: transaction support is a requirement for most non-trivial websites
: nontheless.
: 2. Oracle license is very expensive, you pay for every CPU added to that.
: Once I notice DB a performance issue and I asked DBA to segment the data,
时半会都不会用NoSQL数据库,而且你自己也说过NoSQL数据库的缺点。另外也不用老把
钱拿出来说,用oracle的公司有的是钱,没钱就去用mysql。坑爹美国政府100+个table
的数据库也要用oracle。
你搞个NoSql的讲座吧,很多人其实还不是很清楚咋回事。
【在 g*****g 的大作中提到】
: It's a bit of everything.
: 1. Relational DB doesn't scale that well compared to NoSQL due to
: transaction
: support requirement. More DB nodes will certainly degrade performance. How
: bad
: is probably dependent on how data can be partitioned. On the other hand,
: transaction support is a requirement for most non-trivial websites
: nontheless.
: 2. Oracle license is very expensive, you pay for every CPU added to that.
: Once I notice DB a performance issue and I asked DBA to segment the data,
g*g
55 楼
不是呀,诸如hibernate的ORM也是用Relational DB的。但是利用caching,
eager/lazy loading 等等可以减少和批量化交易,把计算基本上都放在应用
服务器上,从而减少数据库负担。
不谈钱的问题,单说这个数据库是瓶颈怎么办。第一步当然是尽量减少数据库
负担,再不行了只有cluster DB一条路。
table
【在 B*****g 的大作中提到】
: 你说的这都是relational database的缺点,和plsql自身没关系。对大多数公司来说一
: 时半会都不会用NoSQL数据库,而且你自己也说过NoSQL数据库的缺点。另外也不用老把
: 钱拿出来说,用oracle的公司有的是钱,没钱就去用mysql。坑爹美国政府100+个table
: 的数据库也要用oracle。
: 你搞个NoSql的讲座吧,很多人其实还不是很清楚咋回事。
eager/lazy loading 等等可以减少和批量化交易,把计算基本上都放在应用
服务器上,从而减少数据库负担。
不谈钱的问题,单说这个数据库是瓶颈怎么办。第一步当然是尽量减少数据库
负担,再不行了只有cluster DB一条路。
table
【在 B*****g 的大作中提到】
: 你说的这都是relational database的缺点,和plsql自身没关系。对大多数公司来说一
: 时半会都不会用NoSQL数据库,而且你自己也说过NoSQL数据库的缺点。另外也不用老把
: 钱拿出来说,用oracle的公司有的是钱,没钱就去用mysql。坑爹美国政府100+个table
: 的数据库也要用oracle。
: 你搞个NoSql的讲座吧,很多人其实还不是很清楚咋回事。
B*g
56 楼
hibernate要看看,俺还不是太懂。数据库瓶颈没办法,俺们这儿的java developer老
是让dba改善,dba说没法改善,java developer也说不能改善。
更有甚者,outsource的烙印,从file里load上百万的record,伊们竟然一个一个用sql
insert,这些哥们据说在印度年薪也有7万美元。
俺们这儿复杂一点的事java team都搞不定。不过俺也不关心,好坏也不长工资,明天
小印要给俺进行spring培训,哈哈,头对他们太不满意,逼着俺去搞。
【在 g*****g 的大作中提到】
: 不是呀,诸如hibernate的ORM也是用Relational DB的。但是利用caching,
: eager/lazy loading 等等可以减少和批量化交易,把计算基本上都放在应用
: 服务器上,从而减少数据库负担。
: 不谈钱的问题,单说这个数据库是瓶颈怎么办。第一步当然是尽量减少数据库
: 负担,再不行了只有cluster DB一条路。
:
: table
是让dba改善,dba说没法改善,java developer也说不能改善。
更有甚者,outsource的烙印,从file里load上百万的record,伊们竟然一个一个用sql
insert,这些哥们据说在印度年薪也有7万美元。
俺们这儿复杂一点的事java team都搞不定。不过俺也不关心,好坏也不长工资,明天
小印要给俺进行spring培训,哈哈,头对他们太不满意,逼着俺去搞。
【在 g*****g 的大作中提到】
: 不是呀,诸如hibernate的ORM也是用Relational DB的。但是利用caching,
: eager/lazy loading 等等可以减少和批量化交易,把计算基本上都放在应用
: 服务器上,从而减少数据库负担。
: 不谈钱的问题,单说这个数据库是瓶颈怎么办。第一步当然是尽量减少数据库
: 负担,再不行了只有cluster DB一条路。
:
: table
g*g
57 楼
ft, 这也行。俺面试必问的问题就是你做的系统要scale 10倍怎么打算,
100倍怎么打算,凡是回答不出来的统统毙掉。
sql
【在 B*****g 的大作中提到】
: hibernate要看看,俺还不是太懂。数据库瓶颈没办法,俺们这儿的java developer老
: 是让dba改善,dba说没法改善,java developer也说不能改善。
: 更有甚者,outsource的烙印,从file里load上百万的record,伊们竟然一个一个用sql
: insert,这些哥们据说在印度年薪也有7万美元。
: 俺们这儿复杂一点的事java team都搞不定。不过俺也不关心,好坏也不长工资,明天
: 小印要给俺进行spring培训,哈哈,头对他们太不满意,逼着俺去搞。
100倍怎么打算,凡是回答不出来的统统毙掉。
sql
【在 B*****g 的大作中提到】
: hibernate要看看,俺还不是太懂。数据库瓶颈没办法,俺们这儿的java developer老
: 是让dba改善,dba说没法改善,java developer也说不能改善。
: 更有甚者,outsource的烙印,从file里load上百万的record,伊们竟然一个一个用sql
: insert,这些哥们据说在印度年薪也有7万美元。
: 俺们这儿复杂一点的事java team都搞不定。不过俺也不关心,好坏也不长工资,明天
: 小印要给俺进行spring培训,哈哈,头对他们太不满意,逼着俺去搞。
v*e
61 楼
scalability这个词是有context的,不同的context不能直接比较,
RDBMS和NoSQL是一个spectrum里面两个不同的position,直接
比scalability好比apple vs orange,恐怕不太合适。
选nosql还是rdbms完全是application domain的问题,和这两种技术
谁高谁低无关。
PL/SQL完全可以run 在cluster上,我不知道前面说pl/sql只能run在一个
machine上是怎么来的,
【在 g*****g 的大作中提到】
: It's a bit of everything.
: 1. Relational DB doesn't scale that well compared to NoSQL due to
: transaction
: support requirement. More DB nodes will certainly degrade performance. How
: bad
: is probably dependent on how data can be partitioned. On the other hand,
: transaction support is a requirement for most non-trivial websites
: nontheless.
: 2. Oracle license is very expensive, you pay for every CPU added to that.
: Once I notice DB a performance issue and I asked DBA to segment the data,
RDBMS和NoSQL是一个spectrum里面两个不同的position,直接
比scalability好比apple vs orange,恐怕不太合适。
选nosql还是rdbms完全是application domain的问题,和这两种技术
谁高谁低无关。
PL/SQL完全可以run 在cluster上,我不知道前面说pl/sql只能run在一个
machine上是怎么来的,
【在 g*****g 的大作中提到】
: It's a bit of everything.
: 1. Relational DB doesn't scale that well compared to NoSQL due to
: transaction
: support requirement. More DB nodes will certainly degrade performance. How
: bad
: is probably dependent on how data can be partitioned. On the other hand,
: transaction support is a requirement for most non-trivial websites
: nontheless.
: 2. Oracle license is very expensive, you pay for every CPU added to that.
: Once I notice DB a performance issue and I asked DBA to segment the data,
v*e
62 楼
在oracle rdbms具体到核心层,SP和你在sqlplus run一个sql是
同一个infrastructure,
具体用多少db的cpu/memory/io,是根据具体你做的事情,不太清楚和
是sp还是不是sp有什么太大关系。
vendor
SP
【在 B*****g 的大作中提到】
: 不能scale/duplicate的原因是db license太贵,用cloud需要时加一个在RAC上应该不
: 是很难,几十秒可能就搞定了,而且费用降得很多,你运行java也得付CPU的钱。SP的
: 问题主要是大量使用DB的cpu/memory,对于用户来说cloud提供的最够了,对于vendor
: 来说所有resource都被你用了其他人就没得用了。
: 至于oracle的SP,不可能包括PLSQL。PLSQL可以用的的地方很多。Oracle SP只不过主
: 要是通过PLSQL实现的,其实Oracle的SP还可能是用java写的。俺自己都写过java的SP
: 处理server上数据文件,为啥非要用SP,坑爹政府DBA不允许其他server连数据库。
同一个infrastructure,
具体用多少db的cpu/memory/io,是根据具体你做的事情,不太清楚和
是sp还是不是sp有什么太大关系。
vendor
SP
【在 B*****g 的大作中提到】
: 不能scale/duplicate的原因是db license太贵,用cloud需要时加一个在RAC上应该不
: 是很难,几十秒可能就搞定了,而且费用降得很多,你运行java也得付CPU的钱。SP的
: 问题主要是大量使用DB的cpu/memory,对于用户来说cloud提供的最够了,对于vendor
: 来说所有resource都被你用了其他人就没得用了。
: 至于oracle的SP,不可能包括PLSQL。PLSQL可以用的的地方很多。Oracle SP只不过主
: 要是通过PLSQL实现的,其实Oracle的SP还可能是用java写的。俺自己都写过java的SP
: 处理server上数据文件,为啥非要用SP,坑爹政府DBA不允许其他server连数据库。
B*g
63 楼
这篇post的主题是PLSQL,不能简单把它等同于SP,虽然楼主的本意可能是这个。SP只
是PLSQL的一种应用,当然可以说是最广泛的,一般意义上可以认为SP必须在DB Server
(s)上运行。但是PLSQL并不一定要在DB Server上运行,像Form、Apex都是用PLSQL,
它们完全可以在Oracle Application Server上运行。这个和单纯的SP是有区别的。
另外说SP只能在DB server上运行也不能算完全正确,因为SP应该可以的Oracle
TimesTen In-Memory Database上运行(没具体试过,不保证郑确),当然大家要说In-
Memory Database也是database,俺也不会抬杠。
【在 v***e 的大作中提到】
: 在oracle rdbms具体到核心层,SP和你在sqlplus run一个sql是
: 同一个infrastructure,
: 具体用多少db的cpu/memory/io,是根据具体你做的事情,不太清楚和
: 是sp还是不是sp有什么太大关系。
:
: vendor
: SP
是PLSQL的一种应用,当然可以说是最广泛的,一般意义上可以认为SP必须在DB Server
(s)上运行。但是PLSQL并不一定要在DB Server上运行,像Form、Apex都是用PLSQL,
它们完全可以在Oracle Application Server上运行。这个和单纯的SP是有区别的。
另外说SP只能在DB server上运行也不能算完全正确,因为SP应该可以的Oracle
TimesTen In-Memory Database上运行(没具体试过,不保证郑确),当然大家要说In-
Memory Database也是database,俺也不会抬杠。
【在 v***e 的大作中提到】
: 在oracle rdbms具体到核心层,SP和你在sqlplus run一个sql是
: 同一个infrastructure,
: 具体用多少db的cpu/memory/io,是根据具体你做的事情,不太清楚和
: 是sp还是不是sp有什么太大关系。
:
: vendor
: SP
B*g
64 楼
讨论这么热烈版务也不来发包子,只有俺自己掏腰包奖励积极参加讨论的。
goodbug 20
redbuds 10
verde 10
goodbug 20
redbuds 10
verde 10
L*r
65 楼
hibernate创造了很多工作机会。
这东西把程序搞得不稳定需要很多人维护,
把程序搞复杂需要很多人改了又改,
把程序搞得错误一堆需要很多人测试,
把人员搞多需要很多的管理人员,
把程序搞得很慢需要买很贵的硬件。
对雇员来说这是很好的东西,你用了Hibernate,你会有很多
工作机会,不然几个人就把东西搞定不出问题,很多人就没有
工作了。很多Contract公司都向客户推荐这东西,因为客户
一旦用了,就得一直用这个公司了。老印作Contract的多,特
别是印度国内的,很希望客户用这个东西。
如果我是雇主,谁要在我的系统里用这个东西,我立即开除他!
可惜咱们是雇员,雇主愿意出钱,咱就挣贝?大家欢喜不好?
-----
你说得不错,Hibernate把很多数据库管理系统非常擅长的工作
变成了一个一个用sql insert。这个速度可是好多数量级地慢!
sql
【在 B*****g 的大作中提到】
: hibernate要看看,俺还不是太懂。数据库瓶颈没办法,俺们这儿的java developer老
: 是让dba改善,dba说没法改善,java developer也说不能改善。
: 更有甚者,outsource的烙印,从file里load上百万的record,伊们竟然一个一个用sql
: insert,这些哥们据说在印度年薪也有7万美元。
: 俺们这儿复杂一点的事java team都搞不定。不过俺也不关心,好坏也不长工资,明天
: 小印要给俺进行spring培训,哈哈,头对他们太不满意,逼着俺去搞。
这东西把程序搞得不稳定需要很多人维护,
把程序搞复杂需要很多人改了又改,
把程序搞得错误一堆需要很多人测试,
把人员搞多需要很多的管理人员,
把程序搞得很慢需要买很贵的硬件。
对雇员来说这是很好的东西,你用了Hibernate,你会有很多
工作机会,不然几个人就把东西搞定不出问题,很多人就没有
工作了。很多Contract公司都向客户推荐这东西,因为客户
一旦用了,就得一直用这个公司了。老印作Contract的多,特
别是印度国内的,很希望客户用这个东西。
如果我是雇主,谁要在我的系统里用这个东西,我立即开除他!
可惜咱们是雇员,雇主愿意出钱,咱就挣贝?大家欢喜不好?
-----
你说得不错,Hibernate把很多数据库管理系统非常擅长的工作
变成了一个一个用sql insert。这个速度可是好多数量级地慢!
sql
【在 B*****g 的大作中提到】
: hibernate要看看,俺还不是太懂。数据库瓶颈没办法,俺们这儿的java developer老
: 是让dba改善,dba说没法改善,java developer也说不能改善。
: 更有甚者,outsource的烙印,从file里load上百万的record,伊们竟然一个一个用sql
: insert,这些哥们据说在印度年薪也有7万美元。
: 俺们这儿复杂一点的事java team都搞不定。不过俺也不关心,好坏也不长工资,明天
: 小印要给俺进行spring培训,哈哈,头对他们太不满意,逼着俺去搞。
r*s
68 楼
您这套说辞可以做个模板
然后用在任何
language, framework, tools
都合适。
【在 L*******r 的大作中提到】
: hibernate创造了很多工作机会。
: 这东西把程序搞得不稳定需要很多人维护,
: 把程序搞复杂需要很多人改了又改,
: 把程序搞得错误一堆需要很多人测试,
: 把人员搞多需要很多的管理人员,
: 把程序搞得很慢需要买很贵的硬件。
: 对雇员来说这是很好的东西,你用了Hibernate,你会有很多
: 工作机会,不然几个人就把东西搞定不出问题,很多人就没有
: 工作了。很多Contract公司都向客户推荐这东西,因为客户
: 一旦用了,就得一直用这个公司了。老印作Contract的多,特
然后用在任何
language, framework, tools
都合适。
【在 L*******r 的大作中提到】
: hibernate创造了很多工作机会。
: 这东西把程序搞得不稳定需要很多人维护,
: 把程序搞复杂需要很多人改了又改,
: 把程序搞得错误一堆需要很多人测试,
: 把人员搞多需要很多的管理人员,
: 把程序搞得很慢需要买很贵的硬件。
: 对雇员来说这是很好的东西,你用了Hibernate,你会有很多
: 工作机会,不然几个人就把东西搞定不出问题,很多人就没有
: 工作了。很多Contract公司都向客户推荐这东西,因为客户
: 一旦用了,就得一直用这个公司了。老印作Contract的多,特
r*y
77 楼
这贴居然没上首页, 买买提的首页贴都是人工弄的?
btw, 啥时候版上Java牛人们组织个 North American Chinese Java User Association
啥的.
btw, 啥时候版上Java牛人们组织个 North American Chinese Java User Association
啥的.
t*e
80 楼
开发绝大多数情况就是拼成本,用ORM对application developer来说能节省很多写sql
query的时间。极端情形可以不用写一个query,完全靠QBE和CRUD API来实现数据库访
问,非常便利。你提到的很多关于Hibernate的抱怨,是由于使用不当造成的。ORM最大
的问题是难学。一旦掌握,绝对是开发利器。至于performance,ORM并不会带来
overhead,相反还有2层cache带来的好处。ORM甚至比native sql更加flexbile针对
database schema的修改。DBA们对ORM的太多误解是由于不了解和不当的使用造成的。
【在 L*******r 的大作中提到】
: hibernate创造了很多工作机会。
: 这东西把程序搞得不稳定需要很多人维护,
: 把程序搞复杂需要很多人改了又改,
: 把程序搞得错误一堆需要很多人测试,
: 把人员搞多需要很多的管理人员,
: 把程序搞得很慢需要买很贵的硬件。
: 对雇员来说这是很好的东西,你用了Hibernate,你会有很多
: 工作机会,不然几个人就把东西搞定不出问题,很多人就没有
: 工作了。很多Contract公司都向客户推荐这东西,因为客户
: 一旦用了,就得一直用这个公司了。老印作Contract的多,特
query的时间。极端情形可以不用写一个query,完全靠QBE和CRUD API来实现数据库访
问,非常便利。你提到的很多关于Hibernate的抱怨,是由于使用不当造成的。ORM最大
的问题是难学。一旦掌握,绝对是开发利器。至于performance,ORM并不会带来
overhead,相反还有2层cache带来的好处。ORM甚至比native sql更加flexbile针对
database schema的修改。DBA们对ORM的太多误解是由于不了解和不当的使用造成的。
【在 L*******r 的大作中提到】
: hibernate创造了很多工作机会。
: 这东西把程序搞得不稳定需要很多人维护,
: 把程序搞复杂需要很多人改了又改,
: 把程序搞得错误一堆需要很多人测试,
: 把人员搞多需要很多的管理人员,
: 把程序搞得很慢需要买很贵的硬件。
: 对雇员来说这是很好的东西,你用了Hibernate,你会有很多
: 工作机会,不然几个人就把东西搞定不出问题,很多人就没有
: 工作了。很多Contract公司都向客户推荐这东西,因为客户
: 一旦用了,就得一直用这个公司了。老印作Contract的多,特
L*r
81 楼
ORM并不难学,有时还挺好用。我做了一个小例子,用的是“Emtity Framework”
在SQL Server上。试图解决“Transaction Isolatio
n”
的问题。
http://www.codeproject.com/KB/database/EFTransactionIsolation.a
有兴趣可以看一下。因为ORM是建立在“Run-Time”生成“SQL Statement”
的基础上的,并希望和多数数据库管理系统兼容,所以有些特定的事情做的并不好。就
这个例子来说,如果用Native SQL其实就是两句话,但用“Emtity Framework”要写
很多语句。当然用不用“ORM”系统都是可以工作的,好不好就见仁见智了。
我自己用过“Hibernate”和“Emtity Framework”,两个差不多。“Emtity
Framework”
有自己的Template可以用,所以不需要自己写“XML Mapping”,也能自己生成“
Object
Model”。
一般的问题,ORM不会对速度造成特别大的损害,但对有些特定的任务,尤其是“Batch”
一批很大的数据,直接对数据可进行操作可以充分利用对数据库的了解。效率的的区别
可以很大。我个人还没有找到怎样有效地使用ORM来“Batch”一大批数据。有兴趣可以
看一下对比数据。我没有直接对比使用ORM会怎么样,因为我不知道ORM怎样把一大批数据
送到数据库。
http://www.codeproject.com/KB/database/SQLServerPerformanceComp
很多DBA不喜欢ORM,因为这会给他们的工作造成一定的困难。尤其是他们不愿意给用户
程序
太多的“Permission”。如果ORM要修改Schema,程序需要“Adminis
trative permission”。即使不修改Schema,DBA也不好
控制要怎样去限制
给用户程序什么样的Permission对每一个Table。很多时候用户程序是用
“System Admin”或“DB Owner”的身份和数据库联接的,这会
让DBA们
很不舒服。
ORM也在发展,也许不远的将来这些问题都会很好地解决,但至少现在ORM还不是一个
万灵药。大家也都知道其实世界上真的没有什么万灵药。具体问题还是要具体分析,如果
ORM真的带给你好处,为什么不用呢?
sql
。
【在 t*******e 的大作中提到】
: 开发绝大多数情况就是拼成本,用ORM对application developer来说能节省很多写sql
: query的时间。极端情形可以不用写一个query,完全靠QBE和CRUD API来实现数据库访
: 问,非常便利。你提到的很多关于Hibernate的抱怨,是由于使用不当造成的。ORM最大
: 的问题是难学。一旦掌握,绝对是开发利器。至于performance,ORM并不会带来
: overhead,相反还有2层cache带来的好处。ORM甚至比native sql更加flexbile针对
: database schema的修改。DBA们对ORM的太多误解是由于不了解和不当的使用造成的。
在SQL Server上。试图解决“Transaction Isolatio
n”
的问题。
http://www.codeproject.com/KB/database/EFTransactionIsolation.a
有兴趣可以看一下。因为ORM是建立在“Run-Time”生成“SQL Statement”
的基础上的,并希望和多数数据库管理系统兼容,所以有些特定的事情做的并不好。就
这个例子来说,如果用Native SQL其实就是两句话,但用“Emtity Framework”要写
很多语句。当然用不用“ORM”系统都是可以工作的,好不好就见仁见智了。
我自己用过“Hibernate”和“Emtity Framework”,两个差不多。“Emtity
Framework”
有自己的Template可以用,所以不需要自己写“XML Mapping”,也能自己生成“
Object
Model”。
一般的问题,ORM不会对速度造成特别大的损害,但对有些特定的任务,尤其是“Batch”
一批很大的数据,直接对数据可进行操作可以充分利用对数据库的了解。效率的的区别
可以很大。我个人还没有找到怎样有效地使用ORM来“Batch”一大批数据。有兴趣可以
看一下对比数据。我没有直接对比使用ORM会怎么样,因为我不知道ORM怎样把一大批数据
送到数据库。
http://www.codeproject.com/KB/database/SQLServerPerformanceComp
很多DBA不喜欢ORM,因为这会给他们的工作造成一定的困难。尤其是他们不愿意给用户
程序
太多的“Permission”。如果ORM要修改Schema,程序需要“Adminis
trative permission”。即使不修改Schema,DBA也不好
控制要怎样去限制
给用户程序什么样的Permission对每一个Table。很多时候用户程序是用
“System Admin”或“DB Owner”的身份和数据库联接的,这会
让DBA们
很不舒服。
ORM也在发展,也许不远的将来这些问题都会很好地解决,但至少现在ORM还不是一个
万灵药。大家也都知道其实世界上真的没有什么万灵药。具体问题还是要具体分析,如果
ORM真的带给你好处,为什么不用呢?
sql
。
【在 t*******e 的大作中提到】
: 开发绝大多数情况就是拼成本,用ORM对application developer来说能节省很多写sql
: query的时间。极端情形可以不用写一个query,完全靠QBE和CRUD API来实现数据库访
: 问,非常便利。你提到的很多关于Hibernate的抱怨,是由于使用不当造成的。ORM最大
: 的问题是难学。一旦掌握,绝对是开发利器。至于performance,ORM并不会带来
: overhead,相反还有2层cache带来的好处。ORM甚至比native sql更加flexbile针对
: database schema的修改。DBA们对ORM的太多误解是由于不了解和不当的使用造成的。
t*e
82 楼
ORM上手不难,学好不易。ORM也不仅仅runtime生成sql statement,完全可以生成
precompiled queries. ORM也可以invoke stored proc, 还能自动把结果map成
entities. ORM也没有强迫schema必须从application source code生成。Batch data
processing有各种各样的ETL工具可以处理,hibernate本来就不是干这个的。至于
transaction isolation的例子,本身就有问题,为何要在runtime更改txn isolation
level? 用个pessimistic locking就可以了。况且不是所有database都可以在runtime
改txn isolation level的。
Statement”
【在 L*******r 的大作中提到】
: ORM并不难学,有时还挺好用。我做了一个小例子,用的是“Emtity Framework”
: 在SQL Server上。试图解决“Transaction Isolatio
: n”
: 的问题。
: http://www.codeproject.com/KB/database/EFTransactionIsolation.a
: 有兴趣可以看一下。因为ORM是建立在“Run-Time”生成“SQL Statement”
: 的基础上的,并希望和多数数据库管理系统兼容,所以有些特定的事情做的并不好。就
: 这个例子来说,如果用Native SQL其实就是两句话,但用“Emtity Framework”要写
: 很多语句。当然用不用“ORM”系统都是可以工作的,好不好就见仁见智了。
: 我自己用过“Hibernate”和“Emtity Framework”,两个差不多。“Emtity
precompiled queries. ORM也可以invoke stored proc, 还能自动把结果map成
entities. ORM也没有强迫schema必须从application source code生成。Batch data
processing有各种各样的ETL工具可以处理,hibernate本来就不是干这个的。至于
transaction isolation的例子,本身就有问题,为何要在runtime更改txn isolation
level? 用个pessimistic locking就可以了。况且不是所有database都可以在runtime
改txn isolation level的。
Statement”
【在 L*******r 的大作中提到】
: ORM并不难学,有时还挺好用。我做了一个小例子,用的是“Emtity Framework”
: 在SQL Server上。试图解决“Transaction Isolatio
: n”
: 的问题。
: http://www.codeproject.com/KB/database/EFTransactionIsolation.a
: 有兴趣可以看一下。因为ORM是建立在“Run-Time”生成“SQL Statement”
: 的基础上的,并希望和多数数据库管理系统兼容,所以有些特定的事情做的并不好。就
: 这个例子来说,如果用Native SQL其实就是两句话,但用“Emtity Framework”要写
: 很多语句。当然用不用“ORM”系统都是可以工作的,好不好就见仁见智了。
: 我自己用过“Hibernate”和“Emtity Framework”,两个差不多。“Emtity
相关阅读