S****h
发帖数: 558 | 1 本人理论物理 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 前景如何？
先谢谢了。 |
B*****g
发帖数: 34098 | 2 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 前景如何？
: 先谢谢了。
|
g*****g
发帖数: 34805 | 3 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 前景如何？
: 先谢谢了。
|
S****h
发帖数: 558 | |
B*****g
发帖数: 34098 | 5 这垃圾死掉是早晚的事
【在 S****h 的大作中提到】
: yeah
|
y***d
发帖数: 2330 | 6 PL 这么凄惨？
【在 B*****g 的大作中提到】
: 这垃圾死掉是早晚的事
|
B*****g
发帖数: 34098 | 7 自身血淋淋的事实
【在 y***d 的大作中提到】
: PL 这么凄惨？
|
s*******e
发帖数: 3042 | 8 展开说说? 我还挺喜欢用PL/SQL的呢
【在 B*****g 的大作中提到】
: 自身血淋淋的事实
|
B*****g
发帖数: 34098 | 9 谁也不会因为你PLSQL牛给你150k+，做java150k+的有的是。（限于美东）
【在 s*******e 的大作中提到】
: 展开说说? 我还挺喜欢用PL/SQL的呢
|
B*****g
发帖数: 34098 | 10 另外你们会PLSQL的赶紧去CINAOUG报到。
【在 s*******e 的大作中提到】
: 展开说说? 我还挺喜欢用PL/SQL的呢
|
|
|
s*******e
发帖数: 3042 | 11 哦你是从DBA的角度来说的，我是从developer的角度看的，要是没有了PL/SQL，干很多
事还真是不方便。
【在 B*****g 的大作中提到】
: 谁也不会因为你PLSQL牛给你150k+，做java150k+的有的是。（限于美东）
|
B*****g
发帖数: 34098 | 12 我就是developer，我是从钱的角度来说的。PLSQL这些东西都可以用java做，用java做
的人挣钱多。
【在 s*******e 的大作中提到】
: 哦你是从DBA的角度来说的，我是从developer的角度看的，要是没有了PL/SQL，干很多
: 事还真是不方便。
|
s*******e
发帖数: 3042 | 13 用java做，虽然功能上可以一样，但是性能上没法比吧，尤其是我们有些app动辄上千
万行data的，用PL处理一下一点压力都没有，用java搬进搬出就杯具了
【在 B*****g 的大作中提到】
: 我就是developer，我是从钱的角度来说的。PLSQL这些东西都可以用java做，用java做
: 的人挣钱多。
|
t*******e
发帖数: 684 | 14 可能你只是熟悉core Java，对server side programming不熟。我干Java快十年了，除
了是学生的时候，工作中真没用过PL/SQL。
【在 s*******e 的大作中提到】
: 哦你是从DBA的角度来说的，我是从developer的角度看的，要是没有了PL/SQL，干很多
: 事还真是不方便。
|
B*****g
发帖数: 34098 | 15 性能对公司有用，对我来说我只关心我的paycheck。凭嘛俺们oracle developer没有人
家java developer挣得多？至于你说的技术问题java如何解决，等java大牛来回答。
对于能力比较强新人来说，如果没有特殊偏好，当然是哪个工作多工资高就学哪个。对
于能力不是很强的新人来说，只能是能学哪个学哪个。
【在 s*******e 的大作中提到】
: 用java做，虽然功能上可以一样，但是性能上没法比吧，尤其是我们有些app动辄上千
: 万行data的，用PL处理一下一点压力都没有，用java搬进搬出就杯具了
|
s*******e
发帖数: 3042 | 16 晕，这个结论从何而来啊
【在 t*******e 的大作中提到】
: 可能你只是熟悉core Java，对server side programming不熟。我干Java快十年了，除
: 了是学生的时候，工作中真没用过PL/SQL。
|
B*****g
发帖数: 34098 | 17 这个恐怕木有说服力，做PLSQL的10几年的基本都不会java。另外你们谁要是能写关于
PLSQL和JAVA性能对比的文章，请发到CINAOUG，俺给你们发包子。
【在 t*******e 的大作中提到】
: 可能你只是熟悉core Java，对server side programming不熟。我干Java快十年了，除
: 了是学生的时候，工作中真没用过PL/SQL。
|
S****h
发帖数: 558 | 18 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. |
s*******e
发帖数: 3042 | 19 我原来在软件公司做产品的时候，的确不太关心数据库的性能，data layer给了API，
照着写就行了（那个时候hibernate还不流行，ORM都是自家写的）。但是后来转到非软
件公司做architect，就没这么超脱了，性能就是自己的责任了，推也推不掉呀。我们
的data每天都有大量新的进来，最多一天400million rows，而且很多处理都是time
sensitive的，除了DBA做的优化之外，很多预处理都要靠stored procedure。不过这个
好像是不太值得专门做，自己看看书，再偶尔问问DBA，貌似也够用了。
【在 B*****g 的大作中提到】
: 性能对公司有用，对我来说我只关心我的paycheck。凭嘛俺们oracle developer没有人
: 家java developer挣得多？至于你说的技术问题java如何解决，等java大牛来回答。
: 对于能力比较强新人来说，如果没有特殊偏好，当然是哪个工作多工资高就学哪个。对
: 于能力不是很强的新人来说，只能是能学哪个学哪个。
|
t*******e
发帖数: 684 | 20 真要追求性能，可能就不用relational database了。况且PL/SQL还有个vendor
lockin的问题。
【在 s*******e 的大作中提到】
: 晕，这个结论从何而来啊
|
|
|
s*******e
发帖数: 3042 | 21 也没有这么极端吧，很多每天几十亿transaction的都还run着db2呢。
【在 t*******e 的大作中提到】
: 真要追求性能，可能就不用relational database了。况且PL/SQL还有个vendor
: lockin的问题。
|
B*****g
发帖数: 34098 | 22 俺们公司也一样，只要是java team搞出来的东西，第一开发时间长，第二performance
差，不过公司舍不得花钱请真牛好虫一类的，不知道请java大牛能不能改善。至于俺们
工资就更低了。
另外你为啥会来java版？如果没加入cinaoug，加一个吧。
【在 s*******e 的大作中提到】
: 我原来在软件公司做产品的时候，的确不太关心数据库的性能，data layer给了API，
: 照着写就行了（那个时候hibernate还不流行，ORM都是自家写的）。但是后来转到非软
: 件公司做architect，就没这么超脱了，性能就是自己的责任了，推也推不掉呀。我们
: 的data每天都有大量新的进来，最多一天400million rows，而且很多处理都是time
: sensitive的，除了DBA做的优化之外，很多预处理都要靠stored procedure。不过这个
: 好像是不太值得专门做，自己看看书，再偶尔问问DBA，貌似也够用了。
|
s*******e
发帖数: 3042 | 23 晕，我一直是做java的，学database是赶鸭子上架没办法的事。看了一下，原来
cinaoug是专门给oracle的？感觉没什么共同语言啊
performance
【在 B*****g 的大作中提到】
: 俺们公司也一样，只要是java team搞出来的东西，第一开发时间长，第二performance
: 差，不过公司舍不得花钱请真牛好虫一类的，不知道请java大牛能不能改善。至于俺们
: 工资就更低了。
: 另外你为啥会来java版？如果没加入cinaoug，加一个吧。
|
t*******e
发帖数: 684 | 24 想回楼主的，错回给你了。就想说明不同工业，不同应用，用什么的都有。没什么绝对
的好坏对错。
【在 s*******e 的大作中提到】
: 也没有这么极端吧，很多每天几十亿transaction的都还run着db2呢。
|
B*****g
发帖数: 34098 | 25 俺们组里java/.net/sql server/db2/cloud的大牛都有，当然不少是被我忽悠进去的。
现在北美似乎只有俺们这一个老中IT的全国性组织。
【在 s*******e 的大作中提到】
: 晕，我一直是做java的，学database是赶鸭子上架没办法的事。看了一下，原来
: cinaoug是专门给oracle的？感觉没什么共同语言啊
:
: performance
|
g*****g
发帖数: 34805 | 26 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搬进搬出就杯具了
|
B*****g
发帖数: 34098 | 27 你写篇文章详细比较一下吧。另外，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
发帖数: 34805 | 28 我对PL/SQL的了解不够，不过Oracle RAC又贵又复杂是肯定的。
相比而言，在应用层做clustering现成的架构很多，机器又便宜。
我见过的应用，优化到最后大部分瓶颈都在DB上，所以这是个问题。
【在 B*****g 的大作中提到】
: 你写篇文章详细比较一下吧。另外，plsql也可以在其他server上run。
|
B*****g
发帖数: 34098 | 29 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上，所以这是个问题。
|
s*******e
发帖数: 3042 | 30 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.
|
|
|
B*****g
发帖数: 34098 | 31 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.
|
g*****g
发帖数: 34805 | 32 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.
|
B*****g
发帖数: 34098 | 33 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.
|
g*****g
发帖数: 34805 | 34 别忘了很重要的一条，性能。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又
|
B*****g
发帖数: 34098 | 35 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.
:
: ),
|
g*****g
发帖数: 34805 | 36 我从来没有认为Java可以替代一切呀，都要具体应用具体看。
但论趋势，SP用得越来越少是毫无疑问的。SP要是那么好用，
hibernate哪能主流呀。
【在 B*****g 的大作中提到】
: eCommerce在我看来就不该用oracle，mysql足够了（mysql也有SP，哈哈）。这个贴子
: 在这讨论反响不大，移到CINAOUG吧，上百砖头会扔过来。
|
B*****g
发帖数: 34098 | 37 俺也是这个观点，呵呵，早晚的事。
贴子
【在 g*****g 的大作中提到】
: 我从来没有认为Java可以替代一切呀，都要具体应用具体看。
: 但论趋势，SP用得越来越少是毫无疑问的。SP要是那么好用，
: hibernate哪能主流呀。
|
r*****s
发帖数: 985 | 38 i fully second goodbug's points.
我咋觉得这SP vs Java的讨论不是月经也是鸡精贴了？
从市场角度：
SP是不太符合现在cloud computing的政策精神的，
钱也都让Oracle赚去了，
大家活不活啦？
还有，
您这个cinaoug在哪？
【在 B*****g 的大作中提到】
: eCommerce在我看来就不该用oracle，mysql足够了（mysql也有SP，哈哈）。这个贴子
: 在这讨论反响不大，移到CINAOUG吧，上百砖头会扔过来。
|
B*****g
发帖数: 34098 | 39 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在哪？
|
r*****s
发帖数: 985 | 40 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又不给钱，哈哈。
|
|
|
B*****g
发帖数: 34098 | 41 不能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.
|
L*******r
发帖数: 8961 | 42 做java150k+的有的是？给几个链接？短期Contract除外。
【在 B*****g 的大作中提到】
: 谁也不会因为你PLSQL牛给你150k+，做java150k+的有的是。（限于美东）
|
B*****g
发帖数: 34098 | 43 不是根据网上工作，根据mitbbs上ID。做数据库developer的应该没有超过120k的（<
130k），做java的150k的人不少，真牛好虫都是这个级别。凭java去大公司的更是成堆
，你看GFA那个要plsql了？
【在 L*******r 的大作中提到】
: 做java150k+的有的是？给几个链接？短期Contract除外。
|
g*****g
发帖数: 34805 | 44 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连数据库。
|
B*****g
发帖数: 34098 | 45 你说的这都是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,
|
g*****g
发帖数: 34805 | 46 不是呀，诸如hibernate的ORM也是用Relational DB的。但是利用caching,
eager/lazy loading 等等可以减少和批量化交易，把计算基本上都放在应用
服务器上，从而减少数据库负担。
不谈钱的问题，单说这个数据库是瓶颈怎么办。第一步当然是尽量减少数据库
负担，再不行了只有cluster DB一条路。
table
【在 B*****g 的大作中提到】
: 你说的这都是relational database的缺点，和plsql自身没关系。对大多数公司来说一
: 时半会都不会用NoSQL数据库，而且你自己也说过NoSQL数据库的缺点。另外也不用老把
: 钱拿出来说，用oracle的公司有的是钱，没钱就去用mysql。坑爹美国政府100+个table
: 的数据库也要用oracle。
: 你搞个NoSql的讲座吧，很多人其实还不是很清楚咋回事。
|
B*****g
发帖数: 34098 | 47 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
|
g*****g
发帖数: 34805 | 48 ft, 这也行。俺面试必问的问题就是你做的系统要scale 10倍怎么打算，
100倍怎么打算，凡是回答不出来的统统毙掉。
sql
【在 B*****g 的大作中提到】
: hibernate要看看，俺还不是太懂。数据库瓶颈没办法，俺们这儿的java developer老
: 是让dba改善，dba说没法改善，java developer也说不能改善。
: 更有甚者，outsource的烙印，从file里load上百万的record，伊们竟然一个一个用sql
: insert，这些哥们据说在印度年薪也有7万美元。
: 俺们这儿复杂一点的事java team都搞不定。不过俺也不关心，好坏也不长工资，明天
: 小印要给俺进行spring培训，哈哈，头对他们太不满意，逼着俺去搞。
|
B*****g
发帖数: 34098 | 49 有答案吗？俺们现在急需解决方案，load速度上不去呀
developer老
明天
【在 g*****g 的大作中提到】
: ft, 这也行。俺面试必问的问题就是你做的系统要scale 10倍怎么打算，
: 100倍怎么打算，凡是回答不出来的统统毙掉。
:
: sql
|
g*****g
发帖数: 34805 | 50 这个要具体问题具体分析，一个上马了的方案，直接说推掉架构
重来是不可能的。但数据库瓶颈，无非就是把计算拉到应用服务器
和提高数据库处理能力两种方法。
【在 B*****g 的大作中提到】
: 有答案吗？俺们现在急需解决方案，load速度上不去呀
:
: developer老
: 明天
|
|
|
r*****s
发帖数: 985 | 51 至少要找个人profile一下
到底bottleneck在哪里，
这是一般10x可以解决的问题。
100x多半要动architecture了，
当然也不一定，
ORM一不留神能让你的程序100x slower.
【在 g*****g 的大作中提到】
: 这个要具体问题具体分析，一个上马了的方案，直接说推掉架构
: 重来是不可能的。但数据库瓶颈，无非就是把计算拉到应用服务器
: 和提高数据库处理能力两种方法。
|
v***e
发帖数: 2108 | 52 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,
|
v***e
发帖数: 2108 | 53 在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连数据库。
|
B*****g
发帖数: 34098 | 54 这篇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
|
B*****g
发帖数: 34098 | 55 讨论这么热烈版务也不来发包子，只有俺自己掏腰包奖励积极参加讨论的。
goodbug 20
redbuds 10
verde 10 |
L*******r
发帖数: 8961 | 56 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培训，哈哈，头对他们太不满意，逼着俺去搞。
|
N*****m
发帖数: 42603 | 57 haha, so true
【在 L*******r 的大作中提到】
: hibernate创造了很多工作机会。
: 这东西把程序搞得不稳定需要很多人维护，
: 把程序搞复杂需要很多人改了又改，
: 把程序搞得错误一堆需要很多人测试，
: 把人员搞多需要很多的管理人员，
: 把程序搞得很慢需要买很贵的硬件。
: 对雇员来说这是很好的东西，你用了Hibernate，你会有很多
: 工作机会，不然几个人就把东西搞定不出问题，很多人就没有
: 工作了。很多Contract公司都向客户推荐这东西，因为客户
: 一旦用了，就得一直用这个公司了。老印作Contract的多，特
|
r*****s
发帖数: 985 | 58 谢谢，
不过这包子能当饭吃吗？
呵呵
你还不如让你老板把你们那Scalability问题
包给我们,
consulting一下。
你来湾区我买真的小笼包给你吃，
哈哈。
【在 B*****g 的大作中提到】
: 讨论这么热烈版务也不来发包子，只有俺自己掏腰包奖励积极参加讨论的。
: goodbug 20
: redbuds 10
: verde 10
|
r*****s
发帖数: 985 | 59 您这套说辞可以做个模板
然后用在任何
language, framework, tools
都合适。
【在 L*******r 的大作中提到】
: hibernate创造了很多工作机会。
: 这东西把程序搞得不稳定需要很多人维护，
: 把程序搞复杂需要很多人改了又改，
: 把程序搞得错误一堆需要很多人测试，
: 把人员搞多需要很多的管理人员，
: 把程序搞得很慢需要买很贵的硬件。
: 对雇员来说这是很好的东西，你用了Hibernate，你会有很多
: 工作机会，不然几个人就把东西搞定不出问题，很多人就没有
: 工作了。很多Contract公司都向客户推荐这东西，因为客户
: 一旦用了，就得一直用这个公司了。老印作Contract的多，特
|
v***e
发帖数: 2108 | 60 谢谢，我是做database internal的，上面应用层的东西不是太清楚
向大家学习学习。
【在 B*****g 的大作中提到】
: 讨论这么热烈版务也不来发包子，只有俺自己掏腰包奖励积极参加讨论的。
: goodbug 20
: redbuds 10
: verde 10
|
|
|
B*****g
发帖数: 34098 | 61 做db加入CINAOUG是必需的
【在 v***e 的大作中提到】
: 谢谢，我是做database internal的，上面应用层的东西不是太清楚
: 向大家学习学习。
|
L*******r
发帖数: 8961 | 62 你说得不错，这种现象真的很普遍。但是Hibernate这东西
直接在数据库管理系统（很多时候是IT的心脏）附近玩把戏，
让人很不爽。就像前面一个老兄说的，当他对系统的运作负责
的时候，效率就真的很重要了。
【在 r*****s 的大作中提到】
: 您这套说辞可以做个模板
: 然后用在任何
: language, framework, tools
: 都合适。
|
B*****g
发帖数: 34098 | 63 郁闷，今天第一天培训就是hibernate
【在 L*******r 的大作中提到】
: 你说得不错，这种现象真的很普遍。但是Hibernate这东西
: 直接在数据库管理系统（很多时候是IT的心脏）附近玩把戏，
: 让人很不爽。就像前面一个老兄说的，当他对系统的运作负责
: 的时候，效率就真的很重要了。
|
z****e
发帖数: 54598 | 64 没有hibernate，一个最简单的查询分页不同的db都有不同的实现
搞什么搞，还让不让人活了
我要当cio，谁不用我直接开除谁，面向对象和软件工程的基础概念都没培养起来
【在 L*******r 的大作中提到】
: 你说得不错，这种现象真的很普遍。但是Hibernate这东西
: 直接在数据库管理系统（很多时候是IT的心脏）附近玩把戏，
: 让人很不爽。就像前面一个老兄说的，当他对系统的运作负责
: 的时候，效率就真的很重要了。
|
L*******r
发帖数: 8961 | 65 虽然不完全同意你的意见，没准你还真的能当CIO。很多事不是仅仅技术上的
东西就能算数的。其实你当了CIO还是很可能的。人际关系很重要，这里老中
吃亏一些。但努力吧，祝你好运。
不要老拿面向对象和软件工程的基础概念说事，那是大学二年级的东西，不是
很多人GPA都很差的。不少人这个课拿的都是A。CIO要看大方向。
【在 z****e 的大作中提到】
: 没有hibernate，一个最简单的查询分页不同的db都有不同的实现
: 搞什么搞，还让不让人活了
: 我要当cio，谁不用我直接开除谁，面向对象和软件工程的基础概念都没培养起来
|
v***e
发帖数: 2108 | 66 谢谢，已经加入了。
看到自己在oracle rdbms做的新feature被你们讨论，来自第一线用户的
feedback，也有些启发。
Oracle RDBMS 12g会有一些massive scalability的东西出来。
【在 B*****g 的大作中提到】
: 做db加入CINAOUG是必需的
|
B*****g
发帖数: 34098 | 67 多去发技术文章吧
【在 v***e 的大作中提到】
: 谢谢，已经加入了。
: 看到自己在oracle rdbms做的新feature被你们讨论，来自第一线用户的
: feedback，也有些启发。
: Oracle RDBMS 12g会有一些massive scalability的东西出来。
|
r***y
发帖数: 4379 | 68 这贴居然没上首页, 买买提的首页贴都是人工弄的?
btw, 啥时候版上Java牛人们组织个 North American Chinese Java User Association
啥的. |
B*****g
发帖数: 34098 | 69 你不要搞分裂，java是俺们oracle不可缺少的一部分
Association
【在 r***y 的大作中提到】
: 这贴居然没上首页, 买买提的首页贴都是人工弄的?
: btw, 啥时候版上Java牛人们组织个 North American Chinese Java User Association
: 啥的.
|
r***y
发帖数: 4379 | 70 木有,木有
是你那个 CINAOUG 名字起的明显不想带俺们java guys 玩啊
【在 B*****g 的大作中提到】
: 你不要搞分裂，java是俺们oracle不可缺少的一部分
:
: Association
|
|
|
t*******e
发帖数: 684 | 71 开发绝大多数情况就是拼成本，用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的多，特
|
L*******r
发帖数: 8961 | 72 ORM并不难学，有时还挺好用。我做了一个小例子，用的是“Emtity Framework”
在ＳＱＬ Ｓｅｒｖｅｒ上。试图解决“Ｔｒａｎｓａｃｔｉｏｎ Ｉｓｏｌａｔｉｏ
ｎ”
的问题。
http://www.codeproject.com/KB/database/EFTransactionIsolation.a
有兴趣可以看一下。因为ＯＲＭ是建立在“Ｒｕｎ－Ｔｉｍｅ”生成“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也在发展，也许不远的将来这些问题都会很好地解决，但至少现在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
发帖数: 684 | 73 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”
: 在ＳＱＬ Ｓｅｒｖｅｒ上。试图解决“Ｔｒａｎｓａｃｔｉｏｎ Ｉｓｏｌａｔｉｏ
: ｎ”
: 的问题。
: http://www.codeproject.com/KB/database/EFTransactionIsolation.a
: 有兴趣可以看一下。因为ＯＲＭ是建立在“Ｒｕｎ－Ｔｉｍｅ”生成“SQL Statement”
: 的基础上的，并希望和多数数据库管理系统兼容，所以有些特定的事情做的并不好。就
: 这个例子来说，如果用Native SQL其实就是两句话，但用“Emtity Framework”要写
: 很多语句。当然用不用“ORM”系统都是可以工作的，好不好就见仁见智了。
: 我自己用过“Hibernate”和“Emtity Framework”，两个差不多。“Emtity
|
r*****s
发帖数: 985 | 74 什么很普遍，
这叫“睡不着觉怪床歪”的人很多。
是个工具，
总有pros and cons，
就是把榔头，
你也不能用它舀水不是。
套用你的
我还可以说数据库管理系统这个东西，
直接在OS Kernel(真的IT心脏）附近玩把戏，
让人很不爽...
【在 L*******r 的大作中提到】
: 你说得不错，这种现象真的很普遍。但是Hibernate这东西
: 直接在数据库管理系统（很多时候是IT的心脏）附近玩把戏，
: 让人很不爽。就像前面一个老兄说的，当他对系统的运作负责
: 的时候，效率就真的很重要了。
|
