z****e 发帖数: 54598 | 1 不用对付store procedure
比db简单太多,都是java |
n*****t 发帖数: 22014 | 2 Nosql 很简单吗?sp 很难吗?都是 java 吗?
赵老师,你不要欺负我们书读少好不好。。。
【在 z****e 的大作中提到】 : 不用对付store procedure : 比db简单太多,都是java
|
z****e 发帖数: 54598 | 3
那当然sp难,我每次看到sp都头疼
nosql都是java的api,虽然也有js什么
但是如果是java call的话,就是java直接做
看起来容易太多,sp真是够呛
【在 n*****t 的大作中提到】 : Nosql 很简单吗?sp 很难吗?都是 java 吗? : 赵老师,你不要欺负我们书读少好不好。。。
|
x***4 发帖数: 1815 | 4 不能同意更多。我很不明白除了历史原因以外为什么sql(我指query language ,不是
指db)还在用。
【在 z****e 的大作中提到】 : : 那当然sp难,我每次看到sp都头疼 : nosql都是java的api,虽然也有js什么 : 但是如果是java call的话,就是java直接做 : 看起来容易太多,sp真是够呛
|
w**z 发帖数: 8232 | 5 你什么意思?不用SQL 用什么?谁能搞出一个更好的?
【在 x***4 的大作中提到】 : 不能同意更多。我很不明白除了历史原因以外为什么sql(我指query language ,不是 : 指db)还在用。
|
m*********r 发帖数: 119 | 6 sql对于business I 之前还是用处大的 数据量不大 有很多逻辑性的东西
现在数据大了 很多东西都是放在云上处理或者放到其他软件里再加工
nosql就强大了起来 |
d******e 发帖数: 2265 | 7 需要速度时,都是要裸体sql的。
【在 x***4 的大作中提到】 : 不能同意更多。我很不明白除了历史原因以外为什么sql(我指query language ,不是 : 指db)还在用。
|
l******n 发帖数: 9344 | 8 啥是裸sql?
【在 d******e 的大作中提到】 : 需要速度时,都是要裸体sql的。
|
c*********e 发帖数: 16335 | 9 nosql不是join难搞吗?
【在 z****e 的大作中提到】 : 不用对付store procedure : 比db简单太多,都是java
|
m*********r 发帖数: 119 | 10 就是没有 join 和transaction
但是迅速解决了容量和速度的问题
【在 c*********e 的大作中提到】 : nosql不是join难搞吗?
|
|
|
m*********r 发帖数: 119 | |
c*********e 发帖数: 16335 | 12 银行不用nosql.这玩艺,用在facebook之类的网站不错,但是涉及到钱的网站,还是谨
慎为妙。
【在 m*********r 的大作中提到】 : 就是没有 join 和transaction : 但是迅速解决了容量和速度的问题
|
n*****t 发帖数: 22014 | 13 不一定,app 手工去 join,每条记录 back n forth,不一定快到哪里。
你或者说我 join 好了放在 sub doc 里,但又带来其他问题。
【在 m*********r 的大作中提到】 : 就是没有 join 和transaction : 但是迅速解决了容量和速度的问题
|
z****e 发帖数: 54598 | 14 你自己在内存里面join吧,是麻烦,但是db join多了更想屎
:nosql不是join难搞吗?
: |
z****e 发帖数: 54598 | 15 连接池,真要速度,你就不要persistence,直接放内存中算
:需要速度时,都是要裸体sql的。
: |
d******e 发帖数: 2265 | 16 raw sql statement +jdbc
【在 l******n 的大作中提到】 : 啥是裸sql?
|
c*********e 发帖数: 16335 | 17 放内存中算,突然停电了或者internet connection lost了,就死菜了。
aws突发过几次,isp这些网络服务霸王,突然把你internet connection给断了,你找
它咋说理去?
【在 z****e 的大作中提到】 : 连接池,真要速度,你就不要persistence,直接放内存中算 : : :需要速度时,都是要裸体sql的。 : :
|
z****e 发帖数: 54598 | 18
断了就不存入persistence,重新做
这样等于自动rollback
【在 c*********e 的大作中提到】 : 放内存中算,突然停电了或者internet connection lost了,就死菜了。 : aws突发过几次,isp这些网络服务霸王,突然把你internet connection给断了,你找 : 它咋说理去?
|
n*****t 发帖数: 22014 | 19 DB 设计出来就是干这活的,你非得回到史前时代,赵老师你可是真轴啊
【在 z****e 的大作中提到】 : : 断了就不存入persistence,重新做 : 这样等于自动rollback
|
z****e 发帖数: 54598 | 20 理论上是对的,但是db因为死活要套上sql这个script lang.
导致一些很简单的crud变得复杂起来
而要让sql这个script lang.做crud简单,就要orm
你说何必呢?hibernate很容易?
【在 n*****t 的大作中提到】 : DB 设计出来就是干这活的,你非得回到史前时代,赵老师你可是真轴啊
|
|
|
r***r 发帖数: 39 | 21 真要在工作中用Java、C#、C++写出可靠并且还有点效率的transaction processing,
对大多数开发人员都太难了,更不大可能有足够的时间来验证系统。还用那几个久经考
验的RDMBS现实些。 |
z****e 发帖数: 54598 | 22 transaction没那么难了,最简单的做一个timestamp,然后每次对比一下就好了
做一个logical timestamp就行,难的是分布式transaction
而且这个怎么都会遇到,这个是挺难的,目前没有什么特别好的方法
不是慢就是容易造成不一致,没有银弹 |
L*********s 发帖数: 3063 | 23 分布式transaction还是要靠JavaEE, 缺点是速度慢
【在 z****e 的大作中提到】 : transaction没那么难了,最简单的做一个timestamp,然后每次对比一下就好了 : 做一个logical timestamp就行,难的是分布式transaction : 而且这个怎么都会遇到,这个是挺难的,目前没有什么特别好的方法 : 不是慢就是容易造成不一致,没有银弹
|