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
: 而且这个怎么都会遇到，这个是挺难的，目前没有什么特别好的方法
: 不是慢就是容易造成不一致，没有银弹
|
