c*********e
发帖数: 16335 | 1 sigh,由不得自己啊，现在就是改改legacy code,没啥前途，连spring,hibernate都没
用上。 |
z****e
发帖数: 54598 | 2 你会就行了
以后跳槽你以前公司用什么
没有人知道 |
c*********e
发帖数: 16335 | 3 是啊，搞得我现在经常给自己开小灶，做个project.
【在 z****e 的大作中提到】
: 你会就行了
: 以后跳槽你以前公司用什么
: 没有人知道
|
l*******m
发帖数: 1096 | 4 不少公司直接用jdbc, 主要是快
【在 c*********e 的大作中提到】
: sigh,由不得自己啊，现在就是改改legacy code,没啥前途，连spring,hibernate都没
: 用上。
|
w**z
发帖数: 8232 | 5 我们写service 就直接jdbc with connection pooling . 再加个memcache . Spring
就是用来DI .
【在 l*******m 的大作中提到】
: 不少公司直接用jdbc, 主要是快
|
c*********e
发帖数: 16335 | 6 en,公司里，为了快，用jdbc,hashtable.
【在 l*******m 的大作中提到】
: 不少公司直接用jdbc, 主要是快
|
o**1
发帖数: 6383 | 7 DI 可以用 CDI, spring 已经可以完全不用了。
Spring
【在 w**z 的大作中提到】
: 我们写service 就直接jdbc with connection pooling . 再加个memcache . Spring
: 就是用来DI .
|
b******y
发帖数: 9224 | 8 我负责做的电商网站就是用简单的jdbc + db connection pooling. 对于我们来说，追
求速度和用户体验最重要，越简单越好其实。
但对于找工作来说，如果新单位要求spring/hibernate的话，你自学，加上业余做些项
目，比如说，把你的项目上线做成demo。这样我觉得可以convince单位你有这个能力也
用过这个技术。 |
c*********e
发帖数: 16335 | 9 用过这个技术,是entry-level,还是高手专家级别，人家一问就能问出来啊。。。
【在 b******y 的大作中提到】
: 我负责做的电商网站就是用简单的jdbc + db connection pooling. 对于我们来说，追
: 求速度和用户体验最重要，越简单越好其实。
: 但对于找工作来说，如果新单位要求spring/hibernate的话，你自学，加上业余做些项
: 目，比如说，把你的项目上线做成demo。这样我觉得可以convince单位你有这个能力也
: 用过这个技术。
|
s*****r
发帖数: 43070 | 10 hibernate很多公司不用，比较restrict，不如直接上jdbc。
spring是个好东西 |
|
|
b******y
发帖数: 9224 | 11
那没办法，我觉得你可以找不需要多年hibernate经验的公司，不就完了。而且，如果
这个公司不赏识你肯钻研，愿意接受挑战的精神，只盯着你是否是experienced spring
/hibernate developer来判断你的能力的话，你也趁早别进这种公司了事。否则，进去
了也不舒服。
我的感觉是，有的时候，我们需要转换点观念。公司找合适的developer, 也不容易。
你不用觉得好像他们挑这个挑那个的。其实，往往真正的原因不是你不会哪些技术，而
是他们就不喜欢你，或者不欣赏你。那你完全可以去找欣赏你的地方去工作。
世界之大，有的是公司。我当初挺烦Google, Amazon, Microsoft等公司，动不动就面
试抠算法，有些老印也是诚心的给你使绊的感觉。但后来想了，我热爱编程技术，喜欢
computer science, 居然tnnd进不去这些公司？？那就说明我不适合这种公司而已。此
处不留爷，自有留爷处。
【在 c*********e 的大作中提到】
: 用过这个技术,是entry-level,还是高手专家级别，人家一问就能问出来啊。。。
|
b******y
发帖数: 9224 | 12
靠谱，当初我定方案的时候，也是这样考虑的。感觉hibernate有点像ruby on rail,
就是比较死板。这个可能做B2B或者internal web app可以，但真正public的网站，叫
劲儿性能和可修改的灵活度的时候，还是“手擀面”的jdbc强。
【在 s*****r 的大作中提到】
: hibernate很多公司不用，比较restrict，不如直接上jdbc。
: spring是个好东西
|
w**z
发帖数: 8232 | 13 我们很多是stored procedure .
【在 b******y 的大作中提到】
:
: 靠谱，当初我定方案的时候，也是这样考虑的。感觉hibernate有点像ruby on rail,
: 就是比较死板。这个可能做B2B或者internal web app可以，但真正public的网站，叫
: 劲儿性能和可修改的灵活度的时候，还是“手擀面”的jdbc强。
|
h**k
发帖数: 662 | 14 极度反感stored procedure
【在 w**z 的大作中提到】
: 我们很多是stored procedure .
|
b******y
发帖数: 9224 | 15
哈哈，这个情绪比较熟悉。stored proc像个黑洞，不知道里面都做啥。是不是这个给
人感觉很烦? 反正原先在家公司做的时候，不太记得因为啥原因，有人就是不喜欢
stored
proc. 这些年都不用Oracle stored proc了，搞忘了当初为啥有人对此反感了
【在 h**k 的大作中提到】
: 极度反感stored procedure
|
c*********e
发帖数: 16335 | 16 en,我们也是，data warehouse都是自己写的，用stored procedure,view,table.
【在 w**z 的大作中提到】
: 我们很多是stored procedure .
|
w**z
发帖数: 8232 | 17 以前公司不让用，因为要支持多个数据库。现在自己host, 就无所谓了。只是不好
debug.
【在 b******y 的大作中提到】
:
: 哈哈，这个情绪比较熟悉。stored proc像个黑洞，不知道里面都做啥。是不是这个给
: 人感觉很烦? 反正原先在家公司做的时候，不太记得因为啥原因，有人就是不喜欢
: stored
: proc. 这些年都不用Oracle stored proc了，搞忘了当初为啥有人对此反感了
|
b******y
发帖数: 9224 | 18
多谢。我还想起来，stored proc的问题可能是移植不好，就是容易被lock in到这个数
据库平台上了。但一般business来讲，一旦用了啥软件技术，很难再换了。所以，这个
问题也不大的说。
【在 w**z 的大作中提到】
: 以前公司不让用，因为要支持多个数据库。现在自己host, 就无所谓了。只是不好
: debug.
|
z****e
发帖数: 54598 | 19 +1
【在 h**k 的大作中提到】
: 极度反感stored procedure
|
z****e
发帖数: 54598 | 20 如果dba尽职点的话，store procedure也还好，可以用
就怕是dba他们自己都不知道里面是啥东西
写得乱七八糟的，然后推给开发来维护，那就痛苦了
【在 w**z 的大作中提到】
: 以前公司不让用，因为要支持多个数据库。现在自己host, 就无所谓了。只是不好
: debug.
|
|
|
z****e
发帖数: 54598 | 21 lock in其实还好
就是怕提价，db一旦提价，换的人也不少
主要问题是这是一个脚本语言
所以一旦大了之后，就很不混乱
你不知道这一大坨是个什么玩意
结构变得很混乱，不出问题都还好
但是一旦出了什么问题，纠错起来就很痛苦了
这种问题主要是legacy code
后来的代码几乎都全换成java了
ide里面各种高亮什么的，看起来舒服太多了
【在 b******y 的大作中提到】
:
: 多谢。我还想起来，stored proc的问题可能是移植不好，就是容易被lock in到这个数
: 据库平台上了。但一般business来讲，一旦用了啥软件技术，很难再换了。所以，这个
: 问题也不大的说。
|
F****n
发帖数: 3271 | 22 光用jdbc/sql也会有移植问题
sql根本没有通用性
JPA/hibernate可以提高通用性
【在 b******y 的大作中提到】
:
: 多谢。我还想起来，stored proc的问题可能是移植不好，就是容易被lock in到这个数
: 据库平台上了。但一般business来讲，一旦用了啥软件技术，很难再换了。所以，这个
: 问题也不大的说。
|
c*********e
发帖数: 16335 | 23 老板让我改一个stored procedure,其实根本就不是，沒有in,out参数，里面只有几个
临时表格，其实就是几个view.搞不清到底为啥，view全写成table的样式,放在一个
stored procedure里。
【在 z****e 的大作中提到】
: 如果dba尽职点的话，store procedure也还好，可以用
: 就怕是dba他们自己都不知道里面是啥东西
: 写得乱七八糟的，然后推给开发来维护，那就痛苦了
|
c*********e
发帖数: 16335 | 24 en,可能是基于這個原因，更多的人prefer hibernate to stored procedure
【在 z****e 的大作中提到】
: lock in其实还好
: 就是怕提价，db一旦提价，换的人也不少
: 主要问题是这是一个脚本语言
: 所以一旦大了之后，就很不混乱
: 你不知道这一大坨是个什么玩意
: 结构变得很混乱，不出问题都还好
: 但是一旦出了什么问题，纠错起来就很痛苦了
: 这种问题主要是legacy code
: 后来的代码几乎都全换成java了
: ide里面各种高亮什么的，看起来舒服太多了
|
B*****g
发帖数: 34098 | 25 有几个公司需要通用型呀，而且其实像我这样的完全可以用标准SQL写程序，oracle，
sql server，mysql， db2都能用
【在 F****n 的大作中提到】
: 光用jdbc/sql也会有移植问题
: sql根本没有通用性
: JPA/hibernate可以提高通用性
|
c*********e
发帖数: 16335 | 26 所以，用了sql server,asp.net的公司，基本上就是套牢了，不会转去用oracle,ms软
件公司的目的也达到了。
【在 B*****g 的大作中提到】
: 有几个公司需要通用型呀，而且其实像我这样的完全可以用标准SQL写程序，oracle，
: sql server，mysql， db2都能用
|
F****n
发帖数: 3271 | 27 大部分实际应用都不是标准SQL,
各个DBMS的naming rule, quotation, data type都不一样
很多公司都会经历DB Migration (e.g., mysql -> Oracle),
JPA/hibernate很轻松，JDBC/SQL pain in the ass
【在 B*****g 的大作中提到】
: 有几个公司需要通用型呀，而且其实像我这样的完全可以用标准SQL写程序，oracle，
: sql server，mysql， db2都能用
|
c*********e
发帖数: 16335 | 28 goodbug提到过。
這個mysql确实是。。。现在很多小公司在用。。。跟人类一样，不知道哪天是世界末
日。
【在 F****n 的大作中提到】
: 大部分实际应用都不是标准SQL,
: 各个DBMS的naming rule, quotation, data type都不一样
: 很多公司都会经历DB Migration (e.g., mysql -> Oracle),
: JPA/hibernate很轻松，JDBC/SQL pain in the ass
|
g*****g
发帖数: 34805 | 29 store procedure的最大问题不是vendor lockin，是高并发下的性能问题。
高并发下通常数据库会是瓶颈，你再把一堆代码堆到数据库服务器上，只会更快到
瓶颈，这问题无解。当然，不是所有的应用都高并发。
有些应用，比如每天半夜产生的报表，用SP还是可以的。 |
b******y
发帖数: 9224 | 30
哈哈，典型的microsoft策略。这个对于想做business的朋友，还是值得学习的。不说
micros$ft如何如何吧，至少让你换个平台不方便。
【在 c*********e 的大作中提到】
: 所以，用了sql server,asp.net的公司，基本上就是套牢了，不会转去用oracle,ms软
: 件公司的目的也达到了。
|
|
|
b******y
发帖数: 9224 | 31
强。有道理，这个我搞忘记了，确实是。所有的thread都最后集中到调用一个stored
proc, 这个数据库多大的压力。
【在 g*****g 的大作中提到】
: store procedure的最大问题不是vendor lockin，是高并发下的性能问题。
: 高并发下通常数据库会是瓶颈，你再把一堆代码堆到数据库服务器上，只会更快到
: 瓶颈，这问题无解。当然，不是所有的应用都高并发。
: 有些应用，比如每天半夜产生的报表，用SP还是可以的。
|
w**z
发帖数: 8232 | 32 高并发确实有问题。但可以省network roundtrip, 所以有时还是可以用的。
【在 g*****g 的大作中提到】
: store procedure的最大问题不是vendor lockin，是高并发下的性能问题。
: 高并发下通常数据库会是瓶颈，你再把一堆代码堆到数据库服务器上，只会更快到
: 瓶颈，这问题无解。当然，不是所有的应用都高并发。
: 有些应用，比如每天半夜产生的报表，用SP还是可以的。
|
F****n
发帖数: 3271 | 33 高并发下不管实现在哪里都会有瓶颈问题
比如放到app server一样会有瓶颈，
所以这根本不是stored procedure的问题，
而是system design的失误，
没有正确identify scaling component
只有一种情形下你说的 make sense
就是stored procedure的code和 db query可以完全分开来并行处理
但这种情况比较少见，多数条件下stored procedures 需要直接 access db,
分开来反而增加traffic
【在 g*****g 的大作中提到】
: store procedure的最大问题不是vendor lockin，是高并发下的性能问题。
: 高并发下通常数据库会是瓶颈，你再把一堆代码堆到数据库服务器上，只会更快到
: 瓶颈，这问题无解。当然，不是所有的应用都高并发。
: 有些应用，比如每天半夜产生的报表，用SP还是可以的。
|
B*****g
发帖数: 34098 | 34 举几个例子看看，我拿去和别人吹牛。
不过实际中不标准确实很多，为啥呢，做了十几年不会写sql的Senior DBA成堆，
developer就更不用说了
【在 F****n 的大作中提到】
: 大部分实际应用都不是标准SQL,
: 各个DBMS的naming rule, quotation, data type都不一样
: 很多公司都会经历DB Migration (e.g., mysql -> Oracle),
: JPA/hibernate很轻松，JDBC/SQL pain in the ass
|
B*****g
发帖数: 34098 | 35 有时一个sp会涉及几十个table，如果整个转到java里用hibernate实现，有什么可以注
意的？咱公司的java developer我看多过3个table就开始说no了，常年哭着喊着说谁给
写个sp他们call一下就行了
【在 g*****g 的大作中提到】
: store procedure的最大问题不是vendor lockin，是高并发下的性能问题。
: 高并发下通常数据库会是瓶颈，你再把一堆代码堆到数据库服务器上，只会更快到
: 瓶颈，这问题无解。当然，不是所有的应用都高并发。
: 有些应用，比如每天半夜产生的报表，用SP还是可以的。
|
z****e
发帖数: 54598 | 36 但是store procedure怎么优化？
如果全部剥离出来用java code写
就有很多方法予以优化
比如singleton，就是很好的优化手段
sp怎么搞singleton？
还有spring和jvm的gc调整，这些sp都做不到0
这些都可以在关键时刻提升性能，如果出现瓶颈，加server也容易
如果绑定在db上的话，db的负担会加重
app server出现瓶颈，这是没错，不过理论上这个瓶颈可远比sp的瓶颈要宽得多
traffic问题可以用建立连接池的方式予以解决
还可以自行写cache
另外可以调整存储策略，比如利用临时存储来减少sp跟db之间的互动
还有现在流行的nosql其实也是对db性能不满意的产物
其实早期之所以app server大流行，sp不堪重负也是一个很主要的原因
把所有东西全部推给db做其实是偷懒的想法
【在 F****n 的大作中提到】
: 高并发下不管实现在哪里都会有瓶颈问题
: 比如放到app server一样会有瓶颈，
: 所以这根本不是stored procedure的问题，
: 而是system design的失误，
: 没有正确identify scaling component
: 只有一种情形下你说的 make sense
: 就是stored procedure的code和 db query可以完全分开来并行处理
: 但这种情况比较少见，多数条件下stored procedures 需要直接 access db,
: 分开来反而增加traffic
|
z****e
发帖数: 54598 | 37 只能说你们的developer比较懒
这种join其实是很老旧的设计
应该把关键数据剥离出来，单独用transaction保证其数据安全
transaction可以用container来做
也可以自己用jdbc设置start&end point
或者交给hibernate去管理
然后其它的非关键数据，全部用nosql来搞定
真正一个公司最关键的数据无非两个，一个账户信息，还有一个交易信息
这两个需要transaction，其它的其实无关紧要，什么crm都应该上nosql
就是银行也可以用nosql，更何况其它商业公司
【在 B*****g 的大作中提到】
: 有时一个sp会涉及几十个table，如果整个转到java里用hibernate实现，有什么可以注
: 意的？咱公司的java developer我看多过3个table就开始说no了，常年哭着喊着说谁给
: 写个sp他们call一下就行了
|
z****e
发帖数: 54598 | 38 以我曾经干过的一个行业为例
这个行业最核心的数据保存在主机里面
全世界没几台这种主机，可能整个欧洲那个行业就那么几台
这是上游的企业，然后上游的企业开放接口给中游的公司去用
中游的公司建自己的db，然后开放接口给下游的分销商去用
下游的分销商用nosql现在用得是如火如荼
我觉得这是很好的一个模型 |
c*********e
发帖数: 16335 | 39 好点的数据库比如oracle,memory里专门有一个buffer,如果要调用的sql,已经在buffer
里，那就直接用buffer的。
mysql没有oracle这么精密，会慢很多。
【在 b******y 的大作中提到】
:
: 强。有道理，这个我搞忘记了，确实是。所有的thread都最后集中到调用一个stored
: proc, 这个数据库多大的压力。
|
c*********e
发帖数: 16335 | 40 java developer很多不会写1nf,2nf,3nf的东西。你要他们去从头根据business
requirement定义几个表，而且不要有重复的column,他们可能做不来。
【在 B*****g 的大作中提到】
: 有时一个sp会涉及几十个table，如果整个转到java里用hibernate实现，有什么可以注
: 意的？咱公司的java developer我看多过3个table就开始说no了，常年哭着喊着说谁给
: 写个sp他们call一下就行了
|
|
|
F****n
发帖数: 3271 | 41 我前两天问那个问题就是个例子啊
有的数据库有auto increment ID,
insert record不用管ID值
转到Oracle就不行了啊
【在 B*****g 的大作中提到】
: 举几个例子看看，我拿去和别人吹牛。
: 不过实际中不标准确实很多，为啥呢，做了十几年不会写sql的Senior DBA成堆，
: developer就更不用说了
|
c*********e
发帖数: 16335 | 42 现在哪个大公司在全球不是有多个server? 如果出现瓶颈，多用几个server分布在不同
的地理位置就行了。比如aws,在全球好多分支。
【在 z****e 的大作中提到】
: 但是store procedure怎么优化？
: 如果全部剥离出来用java code写
: 就有很多方法予以优化
: 比如singleton，就是很好的优化手段
: sp怎么搞singleton？
: 还有spring和jvm的gc调整，这些sp都做不到0
: 这些都可以在关键时刻提升性能，如果出现瓶颈，加server也容易
: 如果绑定在db上的话，db的负担会加重
: app server出现瓶颈，这是没错，不过理论上这个瓶颈可远比sp的瓶颈要宽得多
: traffic问题可以用建立连接池的方式予以解决
|
F****n
发帖数: 3271 | 43 application logic/algorithm用Java
query-intensive的用stored procedure
很多stored procedure只是为了方便query
比如select columnA into varB
然后紧接着用varB进行更多的query
这种code也剥离到Java中就属于bad design
【在 z****e 的大作中提到】
: 但是store procedure怎么优化？
: 如果全部剥离出来用java code写
: 就有很多方法予以优化
: 比如singleton，就是很好的优化手段
: sp怎么搞singleton？
: 还有spring和jvm的gc调整，这些sp都做不到0
: 这些都可以在关键时刻提升性能，如果出现瓶颈，加server也容易
: 如果绑定在db上的话，db的负担会加重
: app server出现瓶颈，这是没错，不过理论上这个瓶颈可远比sp的瓶颈要宽得多
: traffic问题可以用建立连接池的方式予以解决
|
c*********e
发帖数: 16335 | 44 oracle有auto increment啊。这又不是啥难事。
【在 F****n 的大作中提到】
: 我前两天问那个问题就是个例子啊
: 有的数据库有auto increment ID,
: insert record不用管ID值
: 转到Oracle就不行了啊
|
z****e
发帖数: 54598 | 45 分布式有先天缺陷
无法保证consistency
如果主机很容易被server替换的话
db也不会太难被nosql搞定
【在 c*********e 的大作中提到】
: 现在哪个大公司在全球不是有多个server? 如果出现瓶颈，多用几个server分布在不同
: 的地理位置就行了。比如aws,在全球好多分支。
|
c*********e
发帖数: 16335 | 46 stored procedure第二次用的时候很快，因为它已经在内存里。
【在 F****n 的大作中提到】
: application logic/algorithm用Java
: query-intensive的用stored procedure
: 很多stored procedure只是为了方便query
: 比如select columnA into varB
: 然后紧接着用varB进行更多的query
: 这种code也剥离到Java中就属于bad design
|
c*********e
发帖数: 16335 | 47 没有哪个银行用nosql.
现在很多公司根据用户的ip address来决定用那个server来服务这个用户。
【在 z****e 的大作中提到】
: 分布式有先天缺陷
: 无法保证consistency
: 如果主机很容易被server替换的话
: db也不会太难被nosql搞定
|
F****n
发帖数: 3271 | 48 Oracle 必须用 sequence, insert的时候不能省
mysql可以省，系统自动加。同一个insert无法通用
【在 c*********e 的大作中提到】
: oracle有auto increment啊。这又不是啥难事。
|
z****e
发帖数: 54598 | 49 因为银行主要是金钱业务
但是其它行业不见得如此
【在 c*********e 的大作中提到】
: 没有哪个银行用nosql.
: 现在很多公司根据用户的ip address来决定用那个server来服务这个用户。
|
z****e
发帖数: 54598 | 50 如果只是查询的话，用sp主要考量是降低io操作，更靠近db
但是问题在于，如果数据存储本身如果是分布式的话
比如a数据在这个server，b数据在那个server
那光是一个rpc就够折腾sp了，数据量一旦上去
最后恐怕还是要回到java code上去
hadoop不就是这样，直接上一个job tracker
然后一堆的task tracker跑在不同的机器上
【在 F****n 的大作中提到】
: application logic/algorithm用Java
: query-intensive的用stored procedure
: 很多stored procedure只是为了方便query
: 比如select columnA into varB
: 然后紧接着用varB进行更多的query
: 这种code也剥离到Java中就属于bad design
|
|
|
B*****g
发帖数: 34098 | 51 oracle大家都用sequence+trigger实现
【在 F****n 的大作中提到】
: Oracle 必须用 sequence, insert的时候不能省
: mysql可以省，系统自动加。同一个insert无法通用
|
B*****g
发帖数: 34098 | 52 是这个理，我现在想说服公司把这种逻辑转到app层，不过我自己也不知道如何搞好
【在 F****n 的大作中提到】
: application logic/algorithm用Java
: query-intensive的用stored procedure
: 很多stored procedure只是为了方便query
: 比如select columnA into varB
: 然后紧接着用varB进行更多的query
: 这种code也剥离到Java中就属于bad design
|
o***i
发帖数: 603 | 53 我们store procedure是程序员负责的
【在 z****e 的大作中提到】
: 如果dba尽职点的话，store procedure也还好，可以用
: 就怕是dba他们自己都不知道里面是啥东西
: 写得乱七八糟的，然后推给开发来维护，那就痛苦了
|
B*****g
发帖数: 34098 | 54 DBA啥都不知道
【在 o***i 的大作中提到】
: 我们store procedure是程序员负责的
|
o***i
发帖数: 603 | 55 我觉得吧，这种东西没有一个通用的方案的，说到底，得看实际情况去考量。
1.有些公司吧，就根本不太可能会换数据库，一条路走到黑的，那管个p的通用性呀。有
些非标准的sql，就是很有用很方便，才会出现呀。
2.瓶颈嘛，哪里都会出现，关键是要合理安排，安排到db层也不是问题呀，有些特别的
情况下，只有安排到db层才是最合理的，比如我们专门有个报表数据库，每天的任务就
是join一大堆表，生成报表数据，这个如果已到java去处理，累死，而且增加很多开销
呀。
3.另一方面，设计一个系统，要整体考虑，因地制宜，想清楚各个瓶颈，合理地分配到
各个层去，最大可能的利用起各个资源。比如说，你搞个很高性能的db server，结果只
是作为一个存储机能，不是很大浪费么？有些非高并发的，join什么的操作你都挪到ap
p server上，那又何苦呢？db有他的优势，也有不足。不能因噎废食。
【在 B*****g 的大作中提到】
: 是这个理，我现在想说服公司把这种逻辑转到app层，不过我自己也不知道如何搞好
|
o***i
发帖数: 603 | 56 我们的dba就负责
每天备份数据
打补丁
。。。
【在 B*****g 的大作中提到】
: DBA啥都不知道
|
B*****g
发帖数: 34098 | 57 and deploy whatever developer codeing
【在 o***i 的大作中提到】
: 我们的dba就负责
: 每天备份数据
: 打补丁
: 。。。
|
w**z
发帖数: 8232 | 58 我们压根就没有dba 自己瞎搞。
【在 B*****g 的大作中提到】
: DBA啥都不知道
|
g*****g
发帖数: 34805 | 59 当然不是，app server cluster很容易做，往上堆机器就行了。相反，Relational DB
scale up，不scale out。这也是NoSQL现在火的原因。
不用SP就是把所有计算的部分都剥离到app server，只把存储相关的留给DB。这样可以
降低数据库服务器CPU和内存的压力。数据库服务器license一般都是按CPU算钱的。
【在 F****n 的大作中提到】
: 高并发下不管实现在哪里都会有瓶颈问题
: 比如放到app server一样会有瓶颈，
: 所以这根本不是stored procedure的问题，
: 而是system design的失误，
: 没有正确identify scaling component
: 只有一种情形下你说的 make sense
: 就是stored procedure的code和 db query可以完全分开来并行处理
: 但这种情况比较少见，多数条件下stored procedures 需要直接 access db,
: 分开来反而增加traffic
|
g*****g
发帖数: 34805 | 60 用hibernate，代码肯定比sp好写，需要注意的是一个transaction太大可能会导致性能
问题。
【在 B*****g 的大作中提到】
: 有时一个sp会涉及几十个table，如果整个转到java里用hibernate实现，有什么可以注
: 意的？咱公司的java developer我看多过3个table就开始说no了，常年哭着喊着说谁给
: 写个sp他们call一下就行了
|
|
|
B*****g
发帖数: 34098 | 61 用hibernate功能怎么share比较好。
写一个sp，谁都可以用，例如直接用sql call，或者一个dotnet也需要这个功能，比较
简单。
用hibernate是不是要搞一个service，要不然别人怎么用呀？
【在 g*****g 的大作中提到】
: 用hibernate，代码肯定比sp好写，需要注意的是一个transaction太大可能会导致性能
: 问题。
|
g*****g
发帖数: 34805 | 62 For end user, expose a web interface, for clients in other languages, expose
a web service interface. You can aggregate, enhance, limit data usage, of
course you have a lot of flexibilities.
【在 B*****g 的大作中提到】
: 用hibernate功能怎么share比较好。
: 写一个sp，谁都可以用，例如直接用sql call，或者一个dotnet也需要这个功能，比较
: 简单。
: 用hibernate是不是要搞一个service，要不然别人怎么用呀？
|
B*****g
发帖数: 34098 | 63 谢谢，要学的东西太多，最近脑子有点胀
expose
【在 g*****g 的大作中提到】
: For end user, expose a web interface, for clients in other languages, expose
: a web service interface. You can aggregate, enhance, limit data usage, of
: course you have a lot of flexibilities.
|
r*****s
发帖数: 985 | 64 什么叫scale up vs scale out?
学习一下
DB
【在 g*****g 的大作中提到】
: 当然不是，app server cluster很容易做，往上堆机器就行了。相反，Relational DB
: scale up，不scale out。这也是NoSQL现在火的原因。
: 不用SP就是把所有计算的部分都剥离到app server，只把存储相关的留给DB。这样可以
: 降低数据库服务器CPU和内存的压力。数据库服务器license一般都是按CPU算钱的。
|
g*****g
发帖数: 34805 | 65 scale up就是升级机器的CPU内存等等，还是一台机器，scale out就是多买几台机器。
scale up是有限的，但对程序影响极小。scale out是无限的，但对系统架构有很多要
求。
基于CAP theorem, RDMBS只能放弃high availability。
【在 r*****s 的大作中提到】
: 什么叫scale up vs scale out?
: 学习一下
:
: DB
|
r*****s
发帖数: 985 | 66 这个theorem好像只applied to very narrow cases, theoratically
没理解RDb怎么就要放弃HA了？
【在 g*****g 的大作中提到】
: scale up就是升级机器的CPU内存等等，还是一台机器，scale out就是多买几台机器。
: scale up是有限的，但对程序影响极小。scale out是无限的，但对系统架构有很多要
: 求。
: 基于CAP theorem, RDMBS只能放弃high availability。
|
g*****g
发帖数: 34805 | 67 这个自己google吧，本质上distributed application，consistency跟availability只
能挑一个。
rdbms要保证consistency，availability就差点。
【在 r*****s 的大作中提到】
: 这个theorem好像只applied to very narrow cases, theoratically
: 没理解RDb怎么就要放弃HA了？
|
r*****s
发帖数: 985 | 68 I meant I was not convinced so.
sigh ...
谦虚一点都不行
拿个Beberley+MIT的Theroem就能prove NoSQL了？
你有点被netflix洗脑了，
抱歉，
说的有点难听。
这个HA, Scalability,ACID本来就是个大标题,
就像你说的，
RDB availability就差“点”，
NoSQL差的地方不是一点了，
小心有一天NoSQL也终于支持SQL statement那就是笑话了，
呵呵。
【在 g*****g 的大作中提到】
: 这个自己google吧，本质上distributed application，consistency跟availability只
: 能挑一个。
: rdbms要保证consistency，availability就差点。
|
g*****g
发帖数: 34805 | 69 这不是一个猜想，这是一个被证明的定理。被提出这么多年还没有反例，
你信不信有用吗？
NoSQL在很多方面有不足毫无疑问，这个本来就是个取舍问题。你要放炮之前，
是不是应该先学习一下基本常识？NoSQL支持SQL也不奇怪，CQL就是这方面的努力之一，
但支持SQL跟支持transaction是两码事。
【在 r*****s 的大作中提到】
: I meant I was not convinced so.
: sigh ...
: 谦虚一点都不行
: 拿个Beberley+MIT的Theroem就能prove NoSQL了？
: 你有点被netflix洗脑了，
: 抱歉，
: 说的有点难听。
: 这个HA, Scalability,ACID本来就是个大标题,
: 就像你说的，
: RDB availability就差“点”，
|
r*****s
发帖数: 985 | 70 车轱辘话我不愿意老讲：
这个proven case is a narrow case。
好的，
我们都来学习一下：
http://en.wikipedia.org/wiki/CAP_theorem
The proof of the CAP theorem by Gilbert and Lynch is a bit narrower than wha
t Brewer had in mind. The theorem sets up a scenario in which a replicated s
ervice is presented with two conflicting requests arriving at distinct locat
ions on a time when a link between them is failed. The obligation to provide
availability despite partitioning failures leads the services to respond; a
t least one of these responses shall necessarily be inconsistent with what a
service implementing a true one-copy replication semantic would have done.
The researchers then go on to show that other forms of consistency are achie
vable, including a property they call t-eventual consistency.
Thus the theorem doesn't rule out achieving consistency in a distributed sys
tem, and says nothing about cloud computing per se or about scalability.
一，
【在 g*****g 的大作中提到】
: 这不是一个猜想，这是一个被证明的定理。被提出这么多年还没有反例，
: 你信不信有用吗？
: NoSQL在很多方面有不足毫无疑问，这个本来就是个取舍问题。你要放炮之前，
: 是不是应该先学习一下基本常识？NoSQL支持SQL也不奇怪，CQL就是这方面的努力之一，
: 但支持SQL跟支持transaction是两码事。
|
|
|
o**1
发帖数: 6383 | 71 cassandra 2.0 也要支持 transaction了。
一，
【在 g*****g 的大作中提到】
: 这不是一个猜想，这是一个被证明的定理。被提出这么多年还没有反例，
: 你信不信有用吗？
: NoSQL在很多方面有不足毫无疑问，这个本来就是个取舍问题。你要放炮之前，
: 是不是应该先学习一下基本常识？NoSQL支持SQL也不奇怪，CQL就是这方面的努力之一，
: 但支持SQL跟支持transaction是两码事。
|
w**z
发帖数: 8232 | 72 你是指CAS 还是atomic batch ？if you want transaction , nosql is not for you.
you won't have roll back.
【在 o**1 的大作中提到】
: cassandra 2.0 也要支持 transaction了。
:
: 一，
|
z****e
发帖数: 54598 | 73 那这样对db的威胁灰常大
因为本身我们使用db就是因为有些地方需要transaction
而大多数地方不需要
那现在nosql是把自身逐步转变成一个db的扩展
变成db+nosql part
这样的话，以后就可以不用db了
涉及钱的交易信息上transaction
其它时候不用，这样基本上满足需求了
【在 o**1 的大作中提到】
: cassandra 2.0 也要支持 transaction了。
:
: 一，
|
o**1
发帖数: 6383 | 74 应该是 CAS 吧，看到一篇文章说 cassandra 2.0 最重要的 new features:
1. lightweight transaction
2. triggers.
you.
【在 w**z 的大作中提到】
: 你是指CAS 还是atomic batch ？if you want transaction , nosql is not for you.
: you won't have roll back.
|
c*********e
发帖数: 16335 | 75 我们也沒有。每个programmer都会写sql.
【在 w**z 的大作中提到】
: 我们压根就没有dba 自己瞎搞。
|
c*********e
发帖数: 16335 | 76 那oracle也可以这么做啊，把不涉及钱的交易的部分弄成nosql
【在 z****e 的大作中提到】
: 那这样对db的威胁灰常大
: 因为本身我们使用db就是因为有些地方需要transaction
: 而大多数地方不需要
: 那现在nosql是把自身逐步转变成一个db的扩展
: 变成db+nosql part
: 这样的话，以后就可以不用db了
: 涉及钱的交易信息上transaction
: 其它时候不用，这样基本上满足需求了
|
g*****g
发帖数: 34805 | 77 你最好理解一下这段话什么意思再跟我争。tunable consistency的意思就是，颜色不
一顶要黑的，或者白的，也可以是灰色的。一个系统甚至可以黑一块白一块灰一块，但
不会改变任意一块不会同时又黑又白的本质。而一个RDBMS，但凡支持transaction，就
意味着是白的。
如果RDBMS灰了，就不是传统意义上的RDBMS了。
wha
s
locat
provide
a
【在 r*****s 的大作中提到】
: 车轱辘话我不愿意老讲：
: 这个proven case is a narrow case。
: 好的，
: 我们都来学习一下：
: http://en.wikipedia.org/wiki/CAP_theorem
: The proof of the CAP theorem by Gilbert and Lynch is a bit narrower than wha
: t Brewer had in mind. The theorem sets up a scenario in which a replicated s
: ervice is presented with two conflicting requests arriving at distinct locat
: ions on a time when a link between them is failed. The obligation to provide
: availability despite partitioning failures leads the services to respond; a
|
z****e
发帖数: 54598 | 78 这么做的话
开源免费的优势会很明显
【在 c*********e 的大作中提到】
: 那oracle也可以这么做啊，把不涉及钱的交易的部分弄成nosql
|
B*****g
发帖数: 34098 | 79 可惜了，很多公司（比如说我们公司），什么贵买什么
【在 z****e 的大作中提到】
: 这么做的话
: 开源免费的优势会很明显
|
c*********e
发帖数: 16335 | 80 其实，和钱有关的部分是最难做的。
【在 z****e 的大作中提到】
: 这么做的话
: 开源免费的优势会很明显
|
|
|
B*****g
发帖数: 34098 | 81 最后啥都有了，不就变成Relational database了吗
【在 o**1 的大作中提到】
: 应该是 CAS 吧，看到一篇文章说 cassandra 2.0 最重要的 new features:
: 1. lightweight transaction
: 2. triggers.
:
: you.
|
s*****r
发帖数: 43070 | 82 这个还是用sp吧，hibernate不是拿来做复杂sql的，而且不支持result set和cursor，
不适合复杂的db processing，尤其是需要batch processing的时候。
【在 B*****g 的大作中提到】
: 有时一个sp会涉及几十个table，如果整个转到java里用hibernate实现，有什么可以注
: 意的？咱公司的java developer我看多过3个table就开始说no了，常年哭着喊着说谁给
: 写个sp他们call一下就行了
|
z****e
发帖数: 54598 | 83 我很怀疑你们美帝有几家真正烧钱的公司
那没见你说过websphere和主机这些
oracle db比起这些来说，其实license不算太贵
【在 B*****g 的大作中提到】
: 可惜了，很多公司（比如说我们公司），什么贵买什么
|
z****e
发帖数: 54598 | 84 hibernate可以有batch做啊
http://docs.jboss.org/hibernate/orm/3.3/reference/en/html/batch
而且越是复杂的逻辑越应该让java code去搞
sp太复杂的话，很难维护
【在 s*****r 的大作中提到】
: 这个还是用sp吧，hibernate不是拿来做复杂sql的，而且不支持result set和cursor，
: 不适合复杂的db processing，尤其是需要batch processing的时候。
|
s*****r
发帖数: 43070 | 85 nf都是欺骗学生的考试题，现实中不dnf才是主流，所谓data integrity啥的根本是借
口。有了nosql，这些nf rule更可以见鬼了。
【在 c*********e 的大作中提到】
: java developer很多不会写1nf,2nf,3nf的东西。你要他们去从头根据business
: requirement定义几个表，而且不要有重复的column,他们可能做不来。
|
s*****r
发帖数: 43070 | 86 报表啥的可以用hive去做，非常适合map-reduce的应用
。有
果只
ap
【在 o***i 的大作中提到】
: 我觉得吧，这种东西没有一个通用的方案的，说到底，得看实际情况去考量。
: 1.有些公司吧，就根本不太可能会换数据库，一条路走到黑的，那管个p的通用性呀。有
: 些非标准的sql，就是很有用很方便，才会出现呀。
: 2.瓶颈嘛，哪里都会出现，关键是要合理安排，安排到db层也不是问题呀，有些特别的
: 情况下，只有安排到db层才是最合理的，比如我们专门有个报表数据库，每天的任务就
: 是join一大堆表，生成报表数据，这个如果已到java去处理，累死，而且增加很多开销
: 呀。
: 3.另一方面，设计一个系统，要整体考虑，因地制宜，想清楚各个瓶颈，合理地分配到
: 各个层去，最大可能的利用起各个资源。比如说，你搞个很高性能的db server，结果只
: 是作为一个存储机能，不是很大浪费么？有些非高并发的，join什么的操作你都挪到ap
|
g*****g
发帖数: 34805 | 87 不是，相当于一个超集。想SQL就SQl，想NoSQL就NoSQL。
【在 B*****g 的大作中提到】
: 最后啥都有了，不就变成Relational database了吗
|
s*****r
发帖数: 43070 | 88 所以俺不看好Oracle，这些transaction data，至少historic的，放进nosql没有什么
问题，query时候搞两次就好，一个去Oracle找最近的，一个去nosql找老的。麻烦是
join，但join on历史数据的要求并不多，主要是报表才需要，这个也可以用nosql来解
决。
如果hibernate开始支持CQL，Oracle估计可以砍掉一半人。
【在 g*****g 的大作中提到】
: 不是，相当于一个超集。想SQL就SQl，想NoSQL就NoSQL。
|
z****e
发帖数: 54598 | 89 报表可以直接写java code来搞
只要不频繁写数据，java code其实没啥问题
主要开销都在insert和update这两个操作上
报表相对简单，因为只读不改，所以就不需要全部锁定所有表
每次fetch数据之后放在内存里，然后挨个执行
最后再归并，其实跟普通的mapreduce操作没有太大差别
【在 s*****r 的大作中提到】
: 所以俺不看好Oracle，这些transaction data，至少historic的，放进nosql没有什么
: 问题，query时候搞两次就好，一个去Oracle找最近的，一个去nosql找老的。麻烦是
: join，但join on历史数据的要求并不多，主要是报表才需要，这个也可以用nosql来解
: 决。
: 如果hibernate开始支持CQL，Oracle估计可以砍掉一半人。
|
c*********e
发帖数: 16335 | 90 太小看oracle了，人家是rd的老大，larry ellison可是全球排名前5的首富。
【在 s*****r 的大作中提到】
: 所以俺不看好Oracle，这些transaction data，至少historic的，放进nosql没有什么
: 问题，query时候搞两次就好，一个去Oracle找最近的，一个去nosql找老的。麻烦是
: join，但join on历史数据的要求并不多，主要是报表才需要，这个也可以用nosql来解
: 决。
: 如果hibernate开始支持CQL，Oracle估计可以砍掉一半人。
|
|
|
z****e
发帖数: 54598 | 91 挨踢更新很快的
oracle股价刚跌了9％
因为营收离预期太远
【在 c*********e 的大作中提到】
: 太小看oracle了，人家是rd的老大，larry ellison可是全球排名前5的首富。
|
c*********e
发帖数: 16335 | 92 "报表相对简单，因为只读不改，所以就不需要全部锁定所有表“，这个其实是误解。
database里面，如果你在读一行，有另外一个人稍微在你后面一点点，在改这行的数据
，那这行要lock起来吗？分好多中情况的，什么phantom之类的，记不起来了。
【在 z****e 的大作中提到】
: 报表可以直接写java code来搞
: 只要不频繁写数据，java code其实没啥问题
: 主要开销都在insert和update这两个操作上
: 报表相对简单，因为只读不改，所以就不需要全部锁定所有表
: 每次fetch数据之后放在内存里，然后挨个执行
: 最后再归并，其实跟普通的mapreduce操作没有太大差别
|
z****e
发帖数: 54598 | 93 一般报表精度不会要求得这么高
真要挑剔起来的话
你出报表到领导读报表这段时间内数据也会有变化
报表大多数时候只是出一个general的数据就好了
而且很多人压根不看数据，关键是图
【在 c*********e 的大作中提到】
: "报表相对简单，因为只读不改，所以就不需要全部锁定所有表“，这个其实是误解。
: database里面，如果你在读一行，有另外一个人稍微在你后面一点点，在改这行的数据
: ，那这行要lock起来吗？分好多中情况的，什么phantom之类的，记不起来了。
|
o**1
发帖数: 6383 | 94 我觉得 nosql 对oracle肯定冲击会很大，只会越来越大。
之前大家没选择，以后很多 application 会选用 nosql 的，因为很多应用数据不是那
么 critical. nosql 速度又快，扩展也容易，又便宜，不用才怪呢。
【在 c*********e 的大作中提到】
: 太小看oracle了，人家是rd的老大，larry ellison可是全球排名前5的首富。
|
z****e
发帖数: 54598 | 95 当年mysql就对oracle db有很大的冲击
要不是sun吃饱了跑去收购mysql，mysql可能会抢先一步砸下oracle的收益
而不用等到现在，很多dba都是同时会mysql和oracle
就是害怕开源的冲击太强烈，只是后来sun被oracle吞并超出了所有人的预期
【在 o**1 的大作中提到】
: 我觉得 nosql 对oracle肯定冲击会很大，只会越来越大。
: 之前大家没选择，以后很多 application 会选用 nosql 的，因为很多应用数据不是那
: 么 critical. nosql 速度又快，扩展也容易，又便宜，不用才怪呢。
|
g*****g
发帖数: 34805 | 96 这个叫做isolation level.
【在 c*********e 的大作中提到】
: "报表相对简单，因为只读不改，所以就不需要全部锁定所有表“，这个其实是误解。
: database里面，如果你在读一行，有另外一个人稍微在你后面一点点，在改这行的数据
: ，那这行要lock起来吗？分好多中情况的，什么phantom之类的，记不起来了。
|
c*********e
发帖数: 16335 | 97 mysql做低端的还可以，但是银行还是用oracle,sql server.
【在 z****e 的大作中提到】
: 当年mysql就对oracle db有很大的冲击
: 要不是sun吃饱了跑去收购mysql，mysql可能会抢先一步砸下oracle的收益
: 而不用等到现在，很多dba都是同时会mysql和oracle
: 就是害怕开源的冲击太强烈，只是后来sun被oracle吞并超出了所有人的预期
|
z****e
发帖数: 54598 | 98 银行用oracle主要是历史原因
银行业固然重要，但是如果跟其它所有行业整体比起来
那这块蛋糕显然还是太小了
mysql以前曾被用来投票计数
这个足够说明其是否够reliable了
【在 c*********e 的大作中提到】
: mysql做低端的还可以，但是银行还是用oracle,sql server.
|
s*****r
发帖数: 43070 | 99 报表涉及实时数据的情况不多，主要是历史数据，完全可以脱离transaction db，用
nosql和hive来做，比join什么的好使很多
【在 c*********e 的大作中提到】
: "报表相对简单，因为只读不改，所以就不需要全部锁定所有表“，这个其实是误解。
: database里面，如果你在读一行，有另外一个人稍微在你后面一点点，在改这行的数据
: ，那这行要lock起来吗？分好多中情况的，什么phantom之类的，记不起来了。
|
B*****g
发帖数: 34098 | 100 其实大多数公司用mysql足够了，至于他们为啥非要用oracle、sql server，就不是我
这种小屁屁能关心的了得
【在 z****e 的大作中提到】
: 银行用oracle主要是历史原因
: 银行业固然重要，但是如果跟其它所有行业整体比起来
: 那这块蛋糕显然还是太小了
: mysql以前曾被用来投票计数
: 这个足够说明其是否够reliable了
|
|
|
a*w
发帖数: 4495 | 101 出了事有替罪羊。
【在 B*****g 的大作中提到】
: 其实大多数公司用mysql足够了，至于他们为啥非要用oracle、sql server，就不是我
: 这种小屁屁能关心的了得
|
r*****s
发帖数: 985 | 102 那请问MySQL、Oracle允许灰吗？
还是不是传统意义上的RDBMS？
【在 g*****g 的大作中提到】
: 你最好理解一下这段话什么意思再跟我争。tunable consistency的意思就是，颜色不
: 一顶要黑的，或者白的，也可以是灰色的。一个系统甚至可以黑一块白一块灰一块，但
: 不会改变任意一块不会同时又黑又白的本质。而一个RDBMS，但凡支持transaction，就
: 意味着是白的。
: 如果RDBMS灰了，就不是传统意义上的RDBMS了。
:
: wha
: s
: locat
: provide
|
g*****g
发帖数: 34805 | 103 You probably want to discuss it in case by case manner.
e.g. MySQL cluster allows lagging readonly instances, it has high
availability for read, but it's not consistent when you read from readonly
instances.
That's the point of my back and white Metaphor. RDBMS can implement non-
transaction operation too for high availability, but those operations won't
be consistent.
【在 r*****s 的大作中提到】
: 那请问MySQL、Oracle允许灰吗？
: 还是不是传统意义上的RDBMS？
|
z****e
发帖数: 54598 | 104 决策层用什么其实跟屁民没有太大关系
但是屁民需要了解市场形势
跳槽和找下家接盘这都是很现实的事
现在cassandra用得如火如荼，linkedin上有hadoop和cassandra经验的话
中介踏破门，这点我的感觉跟不少人是一致的
【在 B*****g 的大作中提到】
: 其实大多数公司用mysql足够了，至于他们为啥非要用oracle、sql server，就不是我
: 这种小屁屁能关心的了得
|
c*********e
发帖数: 16335 | 105 投票计数的功能太简单了。
【在 z****e 的大作中提到】
: 银行用oracle主要是历史原因
: 银行业固然重要，但是如果跟其它所有行业整体比起来
: 那这块蛋糕显然还是太小了
: mysql以前曾被用来投票计数
: 这个足够说明其是否够reliable了
|
z****e
发帖数: 54598 | 106 单独拆开的话，都很简单
但是这个不允许错，我说的是reliability
【在 c*********e 的大作中提到】
: 投票计数的功能太简单了。
|
m*****r
发帖数: 298 | 107 想起很久以前见过的一个系统，几个表的外链，链了几层变成了一个环，这是不是个巨
奇葩脑残的设计？
【在 c*********e 的大作中提到】
: java developer很多不会写1nf,2nf,3nf的东西。你要他们去从头根据business
: requirement定义几个表，而且不要有重复的column,他们可能做不来。
|
m*****r
发帖数: 298 | 108 啊，一层又一层的nf都是骗人的啊？只知道过高的nf未必好，但也不能一点nf不讲究吧？
【在 s*****r 的大作中提到】
: nf都是欺骗学生的考试题，现实中不dnf才是主流，所谓data integrity啥的根本是借
: 口。有了nosql，这些nf rule更可以见鬼了。
|
c*********e
发帖数: 16335 | 109 应该有基本的几个entity,然后其它的表可以用foreign key指引到这几个基本的entity.
【在 m*****r 的大作中提到】
: 想起很久以前见过的一个系统，几个表的外链，链了几层变成了一个环，这是不是个巨
: 奇葩脑残的设计？
|
z****e
发帖数: 54598 | 110 是不是把配置文件都写到这里面去？
美其名曰基本表？
entity.
【在 c*********e 的大作中提到】
: 应该有基本的几个entity,然后其它的表可以用foreign key指引到这几个基本的entity.
|
|
|
V***l
发帖数: 2108 | 111 这个很赞。
我Java也不错，coding 也是干净，整齐。现在却要 experienced spring/hibernate d
eveloper，不太看重个人的水平，这些技术过几年淘汰了也说不叮。
spring
【在 b******y 的大作中提到】
:
: 强。有道理，这个我搞忘记了，确实是。所有的thread都最后集中到调用一个stored
: proc, 这个数据库多大的压力。
|
