l*s
发帖数: 783 | 1 ☆─────────────────────────────────────☆
vn (jmj) 于 (Fri Oct 19 10:25:39 2012, 美东) 提到:
- 做很多view的操作吗？加index啥的不？还干神马其他的？
- 你们都把sql query写成stored procedure吗？前段时间好像就是在这个版上看到一
种观点就是用linq 这样在c#里面就可以改 比stored procedure方便。。。这个理解对
不对？
- 用其他的方式访问db 比如NHibernate 还有什么工具？
☆─────────────────────────────────────☆
vn (jmj) 于 (Mon Oct 22 09:57:38 2012, 美东) 提到:
脚踏实地的问题木人讨论 都跑到隔壁去吵架 唉
☆─────────────────────────────────────☆
NeverLearn (24K golden bear) 于 (Mon Oct 22 17:36:01 2012, 美东) 提到:
只要关联查询多了，VIEW是必不可少的。复杂数据库INDEX必加。
SQL没法调试，做BUSINESS LOGCI不方便，写个循环都费劲。LINQ虽然方
便但最终还是执行SQL(除非是IN-MEMORY QUERY)，DB端的优化不可少。
微软有ENTITY FRAMEWORK。ORM不是万能的，CASE BY CASE, 有时候生成
出来的SQL QUERY会degrade数据库效率，使用时注意。
☆─────────────────────────────────────☆
WinterDawn (WinterDawn) 于 (Sat Oct 27 07:36:14 2012, 美东) 提到:
我们公司的db team强制所有东西都用stored proc包起来，甚至在里面包上业务逻辑。
。。看着那一堆xxxx_v2 xxxx_v3.....欲哭无泪
☆─────────────────────────────────────☆
xpan (没事瞎忙) 于 (Sun Oct 28 05:02:29 2012, 美东) 提到:
View是必不可少的。
Stored Procedure看情况决定了。
通常我们直接用LINQ to Entity Framework，但是在特殊情况下用Entity SQL。至于
Business Logic在什么地方是由Architect根据project决定的，DB Team的意见也就是
参考了。
☆─────────────────────────────────────☆
vn (jmj) 于 (Fri Nov 2 17:08:22 2012, 美东) 提到:
拜
大牛的回答真是很让人涨见识
☆─────────────────────────────────────☆
vn (jmj) 于 (Fri Nov 2 17:09:29 2012, 美东) 提到:
看着就痛苦啊 我是最不喜欢sp了 我只会inline code。。。
☆─────────────────────────────────────☆
vn (jmj) 于 (Fri Nov 2 17:19:30 2012, 美东) 提到:
那你们就是用Entity Framework喽 是C# 4吗？好用吗？
☆─────────────────────────────────────☆
xpan (没事瞎忙) 于 (Sat Nov 3 01:47:55 2012, 美东) 提到:
很简单，以前需要一个专业DB Developer两个星期的东西现在一个人两三天就搞定了。
性能没什么差别，可维护性高了很多。bug也少。
EF 4要4.1以上的才行，EF5和.net 4.5就更好了。
☆─────────────────────────────────────☆
Beijing (我是猪--听说猪是被祝福的) 于 (Mon Nov 5 22:04:33 2012, 美东) 提到:
你这水平不行，05年俺面dotnet工作就这水平，面试被大牛秒据
辑。
☆─────────────────────────────────────☆
cogt (苦荆茶) 于 (Tue Nov 6 10:45:32 2012, 美东) 提到:
这叫separation,是好的方向
☆─────────────────────────────────────☆
cogt (苦荆茶) 于 (Tue Nov 6 10:46:58 2012, 美东) 提到:
那是你做得东西小。这种code gen的东东遇到大数据量，或者是复杂的join基本歇菜。
☆─────────────────────────────────────☆
Spark (spark) 于 (Tue Nov 6 13:19:13 2012, 美东) 提到:
为什么sql没法调试呢？这里这个调试是指什么？
☆─────────────────────────────────────☆
a9 (嗯) 于 (Tue Nov 6 13:47:28 2012, 美东) 提到:
那岂不是数据库服务器很容易成瓶颈？
辑。
☆─────────────────────────────────────☆
Beijing (我是猪--听说猪是被祝福的) 于 (Tue Nov 6 17:15:43 2012, 美东) 提到:
将来移到cloud上，数据库服务器无限强大。当然说sp有点土，俺们都说service。
☆─────────────────────────────────────☆
cogt (苦荆茶) 于 (Tue Nov 6 21:09:19 2012, 美东) 提到:
多级缓存，async，不好的design才会hit DB hard。
☆─────────────────────────────────────☆
vn (jmj) 于 (Wed Nov 7 14:23:52 2012, 美东) 提到:
你面的又不是dba
该不会是你美人计使得过了头。。。
☆─────────────────────────────────────☆
vn (jmj) 于 (Wed Nov 7 14:24:49 2012, 美东) 提到:
。。。现在好像不是了 至少不占主流
☆─────────────────────────────────────☆
vn (jmj) 于 (Wed Nov 7 14:26:52 2012, 美东) 提到:
不理解
就拿同样的复杂join来说
写在sp里比写在code里为什么能提高效率呢？
☆─────────────────────────────────────☆
vn (jmj) 于 (Wed Nov 7 14:45:22 2012, 美东) 提到:
coask 是debug吗
虽然我都写的比较水 没调试过 但是应该可以调试吧。。。
☆─────────────────────────────────────☆
Beijing (我是猪--听说猪是被祝福的) 于 (Wed Nov 7 16:06:09 2012, 美东) 提到:
慢慢学吧
☆─────────────────────────────────────☆
NeverLearn (24K golden bear) 于 (Wed Nov 7 19:43:06 2012, 美东) 提到:
SQL SERVER 2005时DEBUG功能被砍了。后来SQL SERVER 2008时又回来了。
☆─────────────────────────────────────☆
xpan (没事瞎忙) 于 (Thu Nov 8 03:25:30 2012, 美东) 提到:
这个在多年以前确实是对的，现在嘛，20毫秒和20.5毫秒有区别吗？
SQL Server的新版本对dynamic sql statement的支持提高了很多，跟stored
procedure没什么区别。另外，database的本身就是提供数据存取，Business Logic就
应该在Domain Model中。
☆─────────────────────────────────────☆
vn (jmj) 于 (Thu Nov 8 10:24:37 2012, 美东) 提到:
re 某版版花请 跟我一块儿来向技术前沿的大牛学习
☆─────────────────────────────────────☆
Beijing (我是猪--听说猪是被祝福的) 于 (Thu Nov 8 10:38:27 2012, 美东) 提到:
前沿啥？要前沿就不要用RD，d-sql还不是sql。你就一个select然后一个update用什么
sp，inline足够了。你要处理几百M的数据涉及几十个table（可能在不同的database）
通过几十步才能完成，再加上考虑安全性，一致性啥的，不用sp你怎么搞？
☆─────────────────────────────────────☆
vn (jmj) 于 (Thu Nov 8 11:33:36 2012, 美东) 提到:
花花不要太绝对
我说90%的网站操作linq2sql就可以 对不？
另外你说的那些非常人所及的事情就让神仙花mm和sp来做 满意不？
☆─────────────────────────────────────☆
Beijing (我是猪--听说猪是被祝福的) 于 (Thu Nov 8 11:56:49 2012, 美东) 提到:
能做不一定等于方法对，越多人能做说明简单。所谓避免用sp，和什么dynamic sql，
linq都没啥关系。只要你用sql，就不可能比sp快，而且你还是在用db的资源，sql还是
要被送到DB里运行。避免sp是说要把逻辑关系，逻辑运算尽量移到app上（尽量不是一
定，具体情况具体分析）。举个例子，你有一些数据在数据库里，你需要把其中符合
Luhn Algorithm的数提取出来。你可以在db写个sp做验证，然后把符合的数据提出来；
你也可以把数据提出来后在app端验证，这个孰胜孰略一目了然。
具体问题具体分析，各种方法都有优缺点。当然sql早晚会死的，嘿嘿
其实inline sql有一个巨大的好处你们都没说，deploy不要通过DBA，哈哈，我最喜欢了
☆─────────────────────────────────────☆
WinterDawn (WinterDawn) 于 (Thu Nov 8 12:09:50 2012, 美东) 提到:
嗯，大型项目前端谁还关心后台数据怎么访问，一切都是SOA, everything is a web
service, either distributed or cloud，哪里有机会让你用orm，app开发者考虑好你
的domain model和dto mapping。小网站的话,orm提供快速开发很不错。
☆─────────────────────────────────────☆
Beijing (我是猪--听说猪是被祝福的) 于 (Thu Nov 8 12:40:40 2012, 美东) 提到:
这是哪个大牛披着马甲上来了，我ws的去搜一下
☆─────────────────────────────────────☆
les (Walk the walk, talk the talk) 于 (Thu Nov 8 21:08:25 2012, 美东) 提到:
由于组里developers水平参差不齐，我是这样要求的：所有CUD以及复杂的Query操作放
在SP，简单query可以用LINQ。Business logic不能放在SP里。从此世界清静了。
☆─────────────────────────────────────☆
xpan (没事瞎忙) 于 (Fri Nov 9 04:01:41 2012, 美东) 提到:
这个是基本的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的。
☆─────────────────────────────────────☆
xpan (没事瞎忙) 于 (Fri Nov 9 04:07:32 2012, 美东) 提到:
现在的dynamic sql一样是预先compile了的，而且执行的plan和SP一样从buffer里取得
，这个效率的提高和developer的开销比起来，整个就是九牛一毛。除非，你的应用是
某些特殊的extreme performance的东西，而且预算极为充足，老板也没有schedule的
问题。
☆─────────────────────────────────────☆
rodeo (rodeo) 于 (Fri Nov 9 11:14:17 2012, 美东) 提到:
复杂操作像report，search用到几十个table和parameter的时候用SP
用到database mapped object做select，insert和update
就用Entity Framework或者Linq2SQL的inline SQL，各有各的用处
用inline sql可以绕过DBA还是不错的
☆─────────────────────────────────────☆
anna09 (anna) 于 (Fri Nov 9 11:30:28 2012, 美东) 提到:
agree
☆─────────────────────────────────────☆
vn (jmj) 于 (Fri Nov 9 12:00:14 2012, 美东) 提到:
你在暗示这是cogt的马甲？hmm。。。possible~
☆─────────────────────────────────────☆
vn (jmj) 于 (Fri Nov 9 12:05:34 2012, 美东) 提到:
版主高明
发几个包子吧~
看在。。。那个版花的面子上。。。
建议这个版也搞个水枪包子~~~行不
☆─────────────────────────────────────☆
vn (jmj) 于 (Fri Nov 9 12:08:04 2012, 美东) 提到:
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. :)
☆─────────────────────────────────────☆
vn (jmj) 于 (Fri Nov 9 12:10:46 2012, 美东) 提到:
上面不是我自己写的 copy stackoverflow来的 。。。
但是蛮有道理的
用sp做所有db操作应该是往事了。。。
☆─────────────────────────────────────☆
vn (jmj) 于 (Fri Nov 9 12:15:21 2012, 美东) 提到:
re |
|
