Redian新闻
>
菜人问问,你们都在database上干什么??
avatar
菜人问问,你们都在database上干什么??# DotNet - 窗口里的风景
vn
1
- 做很多view的操作吗?加index啥的不?还干神马其他的?
- 你们都把sql query写成stored procedure吗?前段时间好像就是在这个版上看到一
种观点就是用linq 这样在c#里面就可以改 比stored procedure方便。。。这个理解对
不对?
- 用其他的方式访问db 比如NHibernate 还有什么工具?
avatar
vn
2
脚踏实地的问题木人讨论 都跑到隔壁去吵架 唉
avatar
N*n
3

只要关联查询多了,VIEW是必不可少的。复杂数据库INDEX必加。
SQL没法调试,做BUSINESS LOGCI不方便,写个循环都费劲。LINQ虽然方
便但最终还是执行SQL(除非是IN-MEMORY QUERY),DB端的优化不可少。
微软有ENTITY FRAMEWORK。ORM不是万能的,CASE BY CASE, 有时候生成
出来的SQL QUERY会degrade数据库效率,使用时注意。

【在 vn 的大作中提到】
: - 做很多view的操作吗?加index啥的不?还干神马其他的?
: - 你们都把sql query写成stored procedure吗?前段时间好像就是在这个版上看到一
: 种观点就是用linq 这样在c#里面就可以改 比stored procedure方便。。。这个理解对
: 不对?
: - 用其他的方式访问db 比如NHibernate 还有什么工具?

avatar
W*n
4
我们公司的db team强制所有东西都用stored proc包起来,甚至在里面包上业务逻辑。
。。看着那一堆xxxx_v2 xxxx_v3.....欲哭无泪
avatar
x*n
5
View是必不可少的。
Stored Procedure看情况决定了。
通常我们直接用LINQ to Entity Framework,但是在特殊情况下用Entity SQL。至于
Business Logic在什么地方是由Architect根据project决定的,DB Team的意见也就是
参考了。
avatar
vn
6

大牛的回答真是很让人涨见识

【在 N********n 的大作中提到】
:
: 只要关联查询多了,VIEW是必不可少的。复杂数据库INDEX必加。
: SQL没法调试,做BUSINESS LOGCI不方便,写个循环都费劲。LINQ虽然方
: 便但最终还是执行SQL(除非是IN-MEMORY QUERY),DB端的优化不可少。
: 微软有ENTITY FRAMEWORK。ORM不是万能的,CASE BY CASE, 有时候生成
: 出来的SQL QUERY会degrade数据库效率,使用时注意。

avatar
vn
7
看着就痛苦啊 我是最不喜欢sp了 我只会inline code。。。

【在 W********n 的大作中提到】
: 我们公司的db team强制所有东西都用stored proc包起来,甚至在里面包上业务逻辑。
: 。。看着那一堆xxxx_v2 xxxx_v3.....欲哭无泪

avatar
vn
8
那你们就是用Entity Framework喽 是C# 4吗?好用吗?

【在 x**n 的大作中提到】
: View是必不可少的。
: Stored Procedure看情况决定了。
: 通常我们直接用LINQ to Entity Framework,但是在特殊情况下用Entity SQL。至于
: Business Logic在什么地方是由Architect根据project决定的,DB Team的意见也就是
: 参考了。

avatar
x*n
9
很简单,以前需要一个专业DB Developer两个星期的东西现在一个人两三天就搞定了。
性能没什么差别,可维护性高了很多。bug也少。
EF 4要4.1以上的才行,EF5和.net 4.5就更好了。

【在 vn 的大作中提到】
: 那你们就是用Entity Framework喽 是C# 4吗?好用吗?
avatar
vn
10
- 做很多view的操作吗?加index啥的不?还干神马其他的?
- 你们都把sql query写成stored procedure吗?前段时间好像就是在这个版上看到一
种观点就是用linq 这样在c#里面就可以改 比stored procedure方便。。。这个理解对
不对?
- 用其他的方式访问db 比如NHibernate 还有什么工具?
avatar
vn
11
脚踏实地的问题木人讨论 都跑到隔壁去吵架 唉
avatar
N*n
12

只要关联查询多了,VIEW是必不可少的。复杂数据库INDEX必加。
SQL没法调试,做BUSINESS LOGCI不方便,写个循环都费劲。LINQ虽然方
便但最终还是执行SQL(除非是IN-MEMORY QUERY),DB端的优化不可少。
微软有ENTITY FRAMEWORK。ORM不是万能的,CASE BY CASE, 有时候生成
出来的SQL QUERY会degrade数据库效率,使用时注意。

【在 vn 的大作中提到】
: - 做很多view的操作吗?加index啥的不?还干神马其他的?
: - 你们都把sql query写成stored procedure吗?前段时间好像就是在这个版上看到一
: 种观点就是用linq 这样在c#里面就可以改 比stored procedure方便。。。这个理解对
: 不对?
: - 用其他的方式访问db 比如NHibernate 还有什么工具?

avatar
W*n
13
我们公司的db team强制所有东西都用stored proc包起来,甚至在里面包上业务逻辑。
。。看着那一堆xxxx_v2 xxxx_v3.....欲哭无泪
avatar
x*n
14
View是必不可少的。
Stored Procedure看情况决定了。
通常我们直接用LINQ to Entity Framework,但是在特殊情况下用Entity SQL。至于
Business Logic在什么地方是由Architect根据project决定的,DB Team的意见也就是
参考了。
avatar
vn
15

大牛的回答真是很让人涨见识

【在 N********n 的大作中提到】
:
: 只要关联查询多了,VIEW是必不可少的。复杂数据库INDEX必加。
: SQL没法调试,做BUSINESS LOGCI不方便,写个循环都费劲。LINQ虽然方
: 便但最终还是执行SQL(除非是IN-MEMORY QUERY),DB端的优化不可少。
: 微软有ENTITY FRAMEWORK。ORM不是万能的,CASE BY CASE, 有时候生成
: 出来的SQL QUERY会degrade数据库效率,使用时注意。

avatar
vn
16
看着就痛苦啊 我是最不喜欢sp了 我只会inline code。。。

【在 W********n 的大作中提到】
: 我们公司的db team强制所有东西都用stored proc包起来,甚至在里面包上业务逻辑。
: 。。看着那一堆xxxx_v2 xxxx_v3.....欲哭无泪

avatar
vn
17
那你们就是用Entity Framework喽 是C# 4吗?好用吗?

【在 x**n 的大作中提到】
: View是必不可少的。
: Stored Procedure看情况决定了。
: 通常我们直接用LINQ to Entity Framework,但是在特殊情况下用Entity SQL。至于
: Business Logic在什么地方是由Architect根据project决定的,DB Team的意见也就是
: 参考了。

avatar
x*n
18
很简单,以前需要一个专业DB Developer两个星期的东西现在一个人两三天就搞定了。
性能没什么差别,可维护性高了很多。bug也少。
EF 4要4.1以上的才行,EF5和.net 4.5就更好了。

【在 vn 的大作中提到】
: 那你们就是用Entity Framework喽 是C# 4吗?好用吗?
avatar
B*g
19
你这水平不行,05年俺面dotnet工作就这水平,面试被大牛秒据

辑。

【在 vn 的大作中提到】
: 看着就痛苦啊 我是最不喜欢sp了 我只会inline code。。。
avatar
c*t
20
这叫separation,是好的方向

【在 W********n 的大作中提到】
: 我们公司的db team强制所有东西都用stored proc包起来,甚至在里面包上业务逻辑。
: 。。看着那一堆xxxx_v2 xxxx_v3.....欲哭无泪

avatar
c*t
21
那是你做得东西小。这种code gen的东东遇到大数据量,或者是复杂的join基本歇菜。

【在 x**n 的大作中提到】
: 很简单,以前需要一个专业DB Developer两个星期的东西现在一个人两三天就搞定了。
: 性能没什么差别,可维护性高了很多。bug也少。
: EF 4要4.1以上的才行,EF5和.net 4.5就更好了。

avatar
S*k
22
为什么sql没法调试呢?这里这个调试是指什么?

【在 N********n 的大作中提到】
:
: 只要关联查询多了,VIEW是必不可少的。复杂数据库INDEX必加。
: SQL没法调试,做BUSINESS LOGCI不方便,写个循环都费劲。LINQ虽然方
: 便但最终还是执行SQL(除非是IN-MEMORY QUERY),DB端的优化不可少。
: 微软有ENTITY FRAMEWORK。ORM不是万能的,CASE BY CASE, 有时候生成
: 出来的SQL QUERY会degrade数据库效率,使用时注意。

avatar
a9
23
那岂不是数据库服务器很容易成瓶颈?

辑。

【在 c**t 的大作中提到】
: 这叫separation,是好的方向
avatar
B*g
24
将来移到cloud上,数据库服务器无限强大。当然说sp有点土,俺们都说service。

【在 a9 的大作中提到】
: 那岂不是数据库服务器很容易成瓶颈?
:
: 辑。

avatar
c*t
25
多级缓存,async,不好的design才会hit DB hard。

【在 a9 的大作中提到】
: 那岂不是数据库服务器很容易成瓶颈?
:
: 辑。

avatar
vn
26
你面的又不是dba
该不会是你美人计使得过了头。。。

【在 B*****g 的大作中提到】
: 你这水平不行,05年俺面dotnet工作就这水平,面试被大牛秒据
:
: 辑。

avatar
vn
27
。。。现在好像不是了 至少不占主流

【在 c**t 的大作中提到】
: 这叫separation,是好的方向
avatar
vn
28
不理解
就拿同样的复杂join来说
写在sp里比写在code里为什么能提高效率呢?

【在 c**t 的大作中提到】
: 那是你做得东西小。这种code gen的东东遇到大数据量,或者是复杂的join基本歇菜。
avatar
vn
29
coask 是debug吗
虽然我都写的比较水 没调试过 但是应该可以调试吧。。。

【在 S***k 的大作中提到】
: 为什么sql没法调试呢?这里这个调试是指什么?
avatar
B*g
30
慢慢学吧

【在 vn 的大作中提到】
: 不理解
: 就拿同样的复杂join来说
: 写在sp里比写在code里为什么能提高效率呢?

avatar
N*n
31

SQL SERVER 2005时DEBUG功能被砍了。后来SQL SERVER 2008时又回来了。

【在 S***k 的大作中提到】
: 为什么sql没法调试呢?这里这个调试是指什么?
avatar
x*n
32
这个在多年以前确实是对的,现在嘛,20毫秒和20.5毫秒有区别吗?
SQL Server的新版本对dynamic sql statement的支持提高了很多,跟stored
procedure没什么区别。另外,database的本身就是提供数据存取,Business Logic就
应该在Domain Model中。

【在 vn 的大作中提到】
: 不理解
: 就拿同样的复杂join来说
: 写在sp里比写在code里为什么能提高效率呢?

avatar
vn
33
re 某版版花请 跟我一块儿来向技术前沿的大牛学习

【在 x**n 的大作中提到】
: 这个在多年以前确实是对的,现在嘛,20毫秒和20.5毫秒有区别吗?
: SQL Server的新版本对dynamic sql statement的支持提高了很多,跟stored
: procedure没什么区别。另外,database的本身就是提供数据存取,Business Logic就
: 应该在Domain Model中。

avatar
B*g
34
前沿啥?要前沿就不要用RD,d-sql还不是sql。你就一个select然后一个update用什么
sp,inline足够了。你要处理几百M的数据涉及几十个table(可能在不同的database)
通过几十步才能完成,再加上考虑安全性,一致性啥的,不用sp你怎么搞?

【在 vn 的大作中提到】
: re 某版版花请 跟我一块儿来向技术前沿的大牛学习
avatar
vn
35
花花不要太绝对
我说90%的网站操作linq2sql就可以 对不?
另外你说的那些非常人所及的事情就让神仙花mm和sp来做 满意不?

【在 B*****g 的大作中提到】
: 前沿啥?要前沿就不要用RD,d-sql还不是sql。你就一个select然后一个update用什么
: sp,inline足够了。你要处理几百M的数据涉及几十个table(可能在不同的database)
: 通过几十步才能完成,再加上考虑安全性,一致性啥的,不用sp你怎么搞?

avatar
B*g
36
能做不一定等于方法对,越多人能做说明简单。所谓避免用sp,和什么dynamic sql,
linq都没啥关系。只要你用sql,就不可能比sp快,而且你还是在用db的资源,sql还是
要被送到DB里运行。避免sp是说要把逻辑关系,逻辑运算尽量移到app上(尽量不是一
定,具体情况具体分析)。举个例子,你有一些数据在数据库里,你需要把其中符合
Luhn Algorithm的数提取出来。你可以在db写个sp做验证,然后把符合的数据提出来;
你也可以把数据提出来后在app端验证,这个孰胜孰略一目了然。
具体问题具体分析,各种方法都有优缺点。当然sql早晚会死的,嘿嘿
其实inline sql有一个巨大的好处你们都没说,deploy不要通过DBA,哈哈,我最喜欢了

【在 vn 的大作中提到】
: 花花不要太绝对
: 我说90%的网站操作linq2sql就可以 对不?
: 另外你说的那些非常人所及的事情就让神仙花mm和sp来做 满意不?

avatar
W*n
37
嗯,大型项目前端谁还关心后台数据怎么访问,一切都是SOA, everything is a web
service, either distributed or cloud,哪里有机会让你用orm,app开发者考虑好你
的domain model和dto mapping。小网站的话,orm提供快速开发很不错。
avatar
B*g
38
这是哪个大牛披着马甲上来了,我ws的去搜一下

【在 W********n 的大作中提到】
: 嗯,大型项目前端谁还关心后台数据怎么访问,一切都是SOA, everything is a web
: service, either distributed or cloud,哪里有机会让你用orm,app开发者考虑好你
: 的domain model和dto mapping。小网站的话,orm提供快速开发很不错。

avatar
l*s
39
由于组里developers水平参差不齐,我是这样要求的:所有CUD以及复杂的Query操作放
在SP,简单query可以用LINQ。Business logic不能放在SP里。从此世界清静了。

【在 vn 的大作中提到】
: - 做很多view的操作吗?加index啥的不?还干神马其他的?
: - 你们都把sql query写成stored procedure吗?前段时间好像就是在这个版上看到一
: 种观点就是用linq 这样在c#里面就可以改 比stored procedure方便。。。这个理解对
: 不对?
: - 用其他的方式访问db 比如NHibernate 还有什么工具?

avatar
x*n
40
这个是基本的seperation of concern原则,每一个东西有自己的responsibility,这
是最基本的architecture的原则。那种所谓每一个query要几百个Megabytes读取,所以
要把Busines Logic放到数据库中的自己去找设计上的错,或则继续生活在20年前。就
像上面说的,Business Logic绝对不能放在SP里,数据库就是做自己的CRUD的。不管你
那一层用什么,你都逃不掉OR/M,什么大型应用不用OR/M,纯属瞎扯。越是大型的应用
,OR/M越发重要,只有你做点小小的自娱自乐的东西可以bypass OR/M,甚至你可以用
transaction script,还没听说有那个严肃的application 不需要 OR/M的。
avatar
x*n
41
现在的dynamic sql一样是预先compile了的,而且执行的plan和SP一样从buffer里取得
,这个效率的提高和developer的开销比起来,整个就是九牛一毛。除非,你的应用是
某些特殊的extreme performance的东西,而且预算极为充足,老板也没有schedule的
问题。

【在 vn 的大作中提到】
: 不理解
: 就拿同样的复杂join来说
: 写在sp里比写在code里为什么能提高效率呢?

avatar
r*o
42
复杂操作像report,search用到几十个table和parameter的时候用SP
用到database mapped object做select,insert和update
就用Entity Framework或者Linq2SQL的inline SQL,各有各的用处
用inline sql可以绕过DBA还是不错的
avatar
a*9
43
agree

【在 x**n 的大作中提到】
: 这个是基本的seperation of concern原则,每一个东西有自己的responsibility,这
: 是最基本的architecture的原则。那种所谓每一个query要几百个Megabytes读取,所以
: 要把Busines Logic放到数据库中的自己去找设计上的错,或则继续生活在20年前。就
: 像上面说的,Business Logic绝对不能放在SP里,数据库就是做自己的CRUD的。不管你
: 那一层用什么,你都逃不掉OR/M,什么大型应用不用OR/M,纯属瞎扯。越是大型的应用
: ,OR/M越发重要,只有你做点小小的自娱自乐的东西可以bypass OR/M,甚至你可以用
: transaction script,还没听说有那个严肃的application 不需要 OR/M的。

avatar
vn
44
你在暗示这是cogt的马甲?hmm。。。possible~

【在 B*****g 的大作中提到】
: 这是哪个大牛披着马甲上来了,我ws的去搜一下
avatar
vn
45
版主高明
发几个包子吧~
看在。。。那个版花的面子上。。。
建议这个版也搞个水枪包子~~~行不

【在 l*s 的大作中提到】
: 由于组里developers水平参差不齐,我是这样要求的:所有CUD以及复杂的Query操作放
: 在SP,简单query可以用LINQ。Business logic不能放在SP里。从此世界清静了。

avatar
vn
46
Some advantages of LINQ over sprocs:
1.Type safety: I think we all understand this.
2.Abstraction: This is especially true with LINQ-to-Entities. This
abstraction also allows the framework to add additional improvements that
you can easily take advantage of. PLINQ is an example of adding multi-
threading support to LINQ. Code changes are minimal to add this support. It
would be MUCH harder to do this data access code that simply calls sprocs.
3.Debugging support: I can use any .NET debugger to debug the queries. With
sprocs, you cannot easily debug the SQL and that experience is largely tied
to your database vendor (MS SQL Server provides a query analyzer, but often
that isn't enough).
4.Vendor agnostic: LINQ works with lots of databases and the number of
supported databases will only increase. Sprocs are not always portable
between databases, either because of varying syntax or feature support (if
the database supports sprocs at all).
5.Deployment: Others have mentioned this already, but it's easier to deploy
a single assembly than to deploy a set of sprocs. This also ties in with #4.
6.Easier: You don't have to learn T-SQL to do data access, nor do you have
to learn the data access API (e.g. ADO.NET) necessary for calling the sprocs
. This is related to #3 and #4.
Some disadvantages of LINQ vs sprocs:
1.Network traffic: sprocs need only serialize sproc-name and argument data
over the wire while LINQ sends the entire query. This can get really bad if
the queries are very complex. However, LINQ's abstraction allows Microsoft
to improve this over time.
2.Less flexible: Sprocs can take full advantage of a database's featureset.
LINQ tends to be more generic in it's support. This is common in any kind
of language abstraction (e.g. C# vs assembler).
3.Recompiling: If you need to make changes to the way you do data access,
you need to recompile, version, and redeploy your assembly. Sprocs can
sometimes allow a DBA to tune the data access routine without a need to
redeploy anything.
Security and manageability are something that people argue about too.
1.Security: For example, you can protect your sensitive data by restricting
access to the tables directly, and put ACLs on the sprocs. With LINQ,
however, you can still restrict direct access to tables and instead put ACLs
on updatable table views to achieve a similar end (assuming your database
supports updatable views).
2.Manageability: Using views also gives you the advantage of shielding your
application non-breaking from schema changes (like table normalization). You
can update the view without requiring your data access code to change.
I used to be a big sproc guy, but I'm starting to lean towards LINQ as a
better alternative in general. If there are some areas where sprocs are
clearly better, then I'll probably still write a sproc but access it using
LINQ. :)
avatar
vn
47
上面不是我自己写的 copy stackoverflow来的 。。。
但是蛮有道理的
用sp做所有db操作应该是往事了。。。
avatar
vn
48
re

【在 a****9 的大作中提到】
: agree
相关阅读
logo
联系我们隐私协议©2024 redian.news
Redian新闻
Redian.news刊载任何文章,不代表同意其说法或描述,仅为提供更多信息,也不构成任何建议。文章信息的合法性及真实性由其作者负责,与Redian.news及其运营公司无关。欢迎投稿,如发现稿件侵权,或作者不愿在本网发表文章,请版权拥有者通知本网处理。