Topic: 有没有人愿意讨论一下stored procedure在大型web项目中的使用问题。最近公司里有人担心将来scaling以及可迁移性的问题，建议把sp全部从数据库中迁移出来。 @佛州华人论坛:佛州枫下论坛 The Rolia Forum of Florida

工作学习 / 专业技术讨论 / 有没有人愿意讨论一下stored procedure在大型web项目中的使用问题。最近公司里有人担心将来scaling以及可迁移性的问题，建议把sp全部从数据库中迁移出来。网上search了一下，有关这个问题有很多争论，有的论点很极端，比如这个：http://www.tonymarston.net/php-mysql/stored-procedures-are-evil.html，但听着也不无道理，再加上听说ebay就是避免用任何sp和trigger，心里很是疑惑，想听听大家的意见。

顺便说一下，我们在开发一个类似于myspace的social network网站，那位大侠知道那里有有关现有的一些大网站，如yahoo,google,myspace,facebook,youtube的设计架构之类的资料(当然是公开的），指点一下，本人不胜感激。 -gudongfish(咕咚来了); 2007-8-9 {434} (#3858542@0)

那个只是再给mysql的sp缺陷找借口，属于PR的文章，不能算专业文章。 -canadiantire(轮胎-TFoselPoep); 2007-8-9 (#3858561@0)
那些资料，如果是公开的，作为业者你自己应该能找的；如果不是公开的，那就有巨大的市场价值，谁会告诉你？同学，你自助吧 -coaster(三叶虫); 2007-8-9 (#3858562@0)

任何技术讨论我都欢迎，但是冷嘲热讽就算了吧. 我当然自己也作research，但是每个人的research都有可能有局限性和盲点，我想如果有人愿意指点一下就指点一下，不想费事就算了，这个要求也不过分吧？至于说专业资料，我也说了我想看“公开的”资料，也就是网上公开的，我有可能遗漏的资料，而且我也没有要求多么详细，能有一些idea就行，我想这样的资料还是有的，比如这个：http://www.addsimplicity.com/downloads/eBaySDForum2006-11-29.pdf

也许是我的表述不太准确吧，如果是就向您道歉了。 -gudongfish(咕咚来了); 2007-8-9 {276} (#3858608@0)

scaling:很多数据库都有cluster; 可迁移:即使不用SP,换数据库也不是简单的事; SP:效率高,可充分利用数据库的性能;trigger:尽量不用 -newkid(newkid); 2007-8-9 (#3858588@0)

我现在的公司就是一个SP都不用，不过到时有很多 trigger，哈哈。算了，反正公司大，也不到我说了算 -sowen(sowen); 2007-8-9 (#3858610@0)

你们公司迟早会吃苦头的……触发器应该只用作简单的审计或数据校验。 -newkid(newkid); 2007-8-9 (#3858622@0)

恩，我的公司也是，原则就是一个trigger都不用。 -canadiantire(轮胎-TFoselPoep); 2007-8-9 (#3858635@0)
我同意 - trigger还是能不用就不用，trigger不利于维护而且用得不好容易引起出乎意料的问题。但是sp - 说老实话，一下子不让我用还真有点接受不了。一个不使用sp 的理由就是business logic和data access layer的分离，也就是说business logic 要尽可能的放在数据库外，我的理解是这样做利于将来的horizonal scaling,但是这样做要损失performance（不能充分利用数据库的功能）以及安全性，但我不知道具体损失有多少，两方面得失孰轻孰重... -gudongfish(咕咚来了); 2007-8-9 {269} (#3858661@0)

与我心有戚戚焉。补充一点，我主张stored procedure仅用于后台数据处理。在real time的web application里不要直接使用stored procedure。 -bdbs(不多不少); 2007-8-9 (#3858702@0)

我们的realtime事务全用存储过程。这不是最需要performance的地方吗？ -newkid(newkid); 2007-8-9 (#3858725@0)

真正的performance来源于数据库的合理规划和设计以及应用程序清晰简洁的逻辑，而不是靠stored procedure来获得。避免实时调用stored procedure是避免stored procedure被滥用。许多程序员对于现有的functions、stored procedures、objects methods等等的都当作black box，只管哪来用，而不管这样的用法是否是有效。也许，一个简单的含有table join的query可以取代多个stored procedures的调用也未必。我见到过太多被滥用的例子，所以不主张stored procedure被real time application直接调用。 -bdbs(不多不少); 2007-8-9 {279} (#3858777@0)

我们的开发人员都有明确分工，存储过程也有明确的用途，不存在滥用问题。"一个简单的含有table join的query可以取代多个stored procedures的调用"那只说明这些sp都是低级的table api而不是事务级的。 -newkid(newkid); 2007-8-9 (#3858807@0)

我上面只是举个例子而已。事务级的SP，时间比较长，也不适合real time application。尤其是流量比较大的web application，一个0点几秒的SP都太慢。 -bdbs(不多不少); 2007-8-9 (#3858981@0)

这理由就更不成立了。我至今还没发现一个这种例子。不使用SP,实际上就是把实现business logic的部分用另一种语言实现,当然这种做法见仁见智，但那些SQL一条都少不了的，最终还是要提交给数据库运行，怎么会更快？如果business logic要用到的数据不在application server cache,那就必须再读出来，就更慢了 -newkid(newkid); 2007-8-9 {85} (#3859040@0)

当然不是简单地“把实现business logic的部分用另一种语言实现”，如果是那样，还是用SP吧。我给你一个例子吧。如内： -bdbs(不多不少); 2007-8-9 {666} (#3859150@0)

哈哈，这个我做过。用ORACLE的self join 一个SQL搞定。即使没有自连接，也用不着递归。只需对category表反复扫描(通常parent id有很好的索引)并将你的结果存放到中间表，最后把中间表和product表join就可以了。 -newkid(newkid); 2007-8-9 (#3859170@0)

如果你不用SP,实现方法肯定类似，无法就是把category表放到内存里遍历罢了。到最后，COUNT一次和多次你说哪个快？ -newkid(newkid); 2007-8-9 (#3859183@0)
是的，这是一个很典型的例子。相信很多人都碰到过。不用SP就会迫使application developer用一个更好的方法来实现。假如有那么个SP在，谁会不去用呢？另外，反复扫描外加使用中间表也不是最好的solution。：） -bdbs(不多不少); 2007-8-9 (#3859184@0)

哦，那你说说你的更好方法。如何遍历并生成树？最后SELECT COUNT的时候是一个SQL还是多个？ -newkid(newkid); 2007-8-9 (#3859191@0)

需要遍历的肯定快不了。俺的专利办法是～～～咳咳，既然是专利，就不能随便乱说的啦。：）不过可以提示一下，帮大家开拓一下思路。有没有办法让ID本身包含更多的信息以避免遍历？ -bdbs(不多不少); 2007-8-9 {124} (#3859245@0)

这哪里是什么专利？不就是 1.2.3.4 这样的ID表示它的上级和祖先吗？那你完全可以把这个信息存在数据库里，只扫描一遍。 -newkid(newkid); 2007-8-9 (#3859252@0)

close了，但不是。只扫描一遍? 拜托，real time application，数据随时会变的，包括category本身，可以随时添加、删除，甚至把整个树叉从一个树干挪到另一个树干上去。 -bdbs(不多不少); 2007-8-9 (#3859265@0)

category的修改是后台管理系统的事情。如果你的OLTP有cache就得注意同步的问题。所以最准确的数据还是得查询数据库。这个查询不管你写在SP之内或之外开销都是一定的。如果你在ID上用了什么技巧，同样也适用于SP。你光说有秘方又不肯示人，当然把自己立于不败之地了！ -newkid(newkid); 2007-8-9 (#3859280@0)

“所以最准确的数据还是得查询数据库” －所以我说用中间表不好。什么败不败的，只是一个用SP不好的例子而已。简单的东西不需要用SP，不得不用SP的performance必定好不了，不适合high traffic real time web application。that's my point. -bdbs(不多不少); 2007-8-9 (#3859320@0)

1.如果能用单个SELECT(connect by或multi-segment id)肯定要优于中间表,这也可在SP中做到；2.修改category的事情极少发生,你放在这里有点钻牛角尖；3.你的例子不能说明sp不好，至多说明某个蹩脚程序员没写好;4.your point我已经知道，但你没能举出有说服力的例子 -newkid(newkid); 2007-8-9 (#3859354@0)

还挺押韵挺上口的呀。：）1. SP当然能做到，我的例子中有两种情况，SP怎么写？还是用两个不同的SP？Point不是如何实现而是如果有效率地实现。2.我当时的实例category更新很频繁。3.蹩脚程序员太多了，本地职场还没碰到过好的程序员，估计高手都不写程序了。4. 不如你帮我想个好点的例子？LZ扔一砖跑了，咱俩掐什么掐？ -bdbs(不多不少); 2007-8-9 {79} (#3859417@0)

你这两种情况: 1.返回一个总数，2.返回一个结果集，当然是两个SP。如果发现它们有很多共同点，可以抽出来再写一个sub sp, 或把共同的子查询做成view. 我的观点是sp能够有效率地实现。我当然不能替我的反方举例:) 楼主虽然跑了，但我们的帖子过后也许能给他一些idea. -newkid(newkid); 2007-8-9 (#3859453@0)

那你就以上例子show一下你的SP(s)，让我看看如何能有效的实现，不受数据多少和层数的影响。 -bdbs(不多不少); 2007-8-9 (#3859516@0)

我只懂ORACLE，思路就是那样的了，没有时间写 -newkid(newkid); 2007-8-9 (#3859589@0)

这跟什么DB没关系吧。何况，你不是说做过嘛。 -bdbs(不多不少); 2007-8-9 (#3859652@0)

好吧，SQL在这,别忘了把你的玉抛出来： -newkid(newkid); 2007-8-9 {1001} (#3859722@0)

完了，俺的oracle算是彻底过时了，咋看不懂了涅。这是SP？嗯，算了，#3859671 -bdbs(不多不少); 2007-8-9 (#3860049@0)

这是SP的body,从WITH开始是一个SQL。我记得MS SQL是支持WITH子查询的。self join语法见内：http://download-east.oracle.com/docs/cd/B14117_01/server.101/b10759/queries003.htm#i2053935

http://download-east.oracle.com/docs/cd/B14117_01/server.101/b10759/functions149.htm

还有什么不理解的尽管问。

我这砖都砌成堆了，您就把玉亮一亮吧，要不咱们再开一贴？ -newkid(newkid); 2007-8-9 {265} (#3860158@0)

俺都说了不掐了呀#3859671。你要觉得没过瘾就另开一贴吧。 -bdbs(不多不少); 2007-8-10 (#3860800@0)

看你们两个掐的正过瘾呢，怎么又把我扯出来？ - 我不抛这一“砖”，怎么能引出你们的“玉”呢？说实话，看你们掐还是挺学东西的，接着干。 -gudongfish(咕咚来了); 2007-8-9 {40} (#3859648@0)

楼梯长得没法看，不掐了。：） -bdbs(不多不少); 2007-8-9 (#3859671@0)

这种问题弄不出一个标准答案的，乐趣就在于争论过场大家能听到不同意见。不能求有结果. -win(秋天的菠菜); 2007-8-10 (#3861014@0)

另外我说只扫描一遍是说只SELECT一次，和category的修改没有任何关系(况且修改category的情形并不经常发生) -newkid(newkid); 2007-8-9 (#3859294@0)

hierarchy data? does "connect by" clause do this job? -win(秋天的菠菜); 2007-8-9 (#3859188@0)

这就是我说的ORACLE方法啦。 -newkid(newkid); 2007-8-9 (#3859193@0)

how about this:define the table as

product table:
productid, category_code,....,

category table:
categoryid, category_code,...

category_code is like 'A',B','AA'...

AA is A's sub catrgory.

you can get the total quantity for category 'AACC' like:
select sum(quantity) from product where category_code like ('AACC%');

the restriction is you can only have limited( 26, or 26+26+10 ) sub categorys. -holdon(again); 2007-8-10 {413} (#3861315@0)

你是谁的马甲？BTW，也可以弄得没有restriction的。 -bdbs(不多不少); 2007-8-10 (#3861322@0)

我也在这里混了很久了，虽然大多潜水。 -holdon(again); 2007-8-10 (#3861352@0)

应该问，你还有没有别的马甲？俺觉得你有可能是。。。。。。：） -bdbs(不多不少); 2007-8-10 (#3861367@0)

"避免实时调用stored procedure是避免stored procedure被滥用" ? sounds very "Abandon eating to prevent choking" to me.... -win(秋天的菠菜); 2007-8-9 (#3858817@0)

不是Abandon eating，而是force to get a better way to eat。：） -bdbs(不多不少); 2007-8-9 (#3858987@0)

那怎么做audit? -poohbear(毛毛熊); 2007-8-9 (#3858750@0)

链接里的文章是不懂数据库的人写的，他自己也不否认。里面有很多错误观点。我想一个大型系统必定要有数据库的人才参与，哪怕不用SP,也得懂得数据库知识。 -newkid(newkid); 2007-8-9 (#3858634@0)

Agree. The author is a guy working at DAL/BL layer and he wants to collect all things into his hand rather than others'. SP is much more effecient because of eliminating a lot of communication workload between DB and AS -marsher(住家男人); 2007-8-10 (#3861500@0)

请大家看看这个链接，关于ebay的，关于他们的做法，大家有什么看法？ -gudongfish(咕咚来了); 2007-8-9 {44} (#3858686@0)

这简直不可理喻：referential integrity, joins, sorting done in the application layer! 特别是这个join,集合操作是SQL的强项 -newkid(newkid); 2007-8-9 (#3858720@0)

Me too. The database are already ordered in database, why not waste time and I/O to reload them and order in memory? -liquid(avaya); 2007-8-9 (#3858728@0)
I guess they are using EJB to do this, and might need to update database with results. -poohbear(毛毛熊); 2007-8-9 (#3858757@0)
Not really. InformaticaETL already process data outside SQL, I guess with huge memory, SQL wouldn't do anything better than line-by-line process, even for summary. -findinghouse(不写错别字。8); 2007-8-9 (#3859154@0)

ebay是个巨型的OLTP,跟ETL没啥关系吧。 -newkid(newkid); 2007-8-9 (#3859215@0)

这个也能理解，凭ｅｂａｙ的实力可以作出比数据库更实用的ｊｏｉｎ和排序算法 -wuyg719(wuyg719); 2007-8-9 (#3859695@0)

你也可以说：凭ebay的实力可以作出更实用的数据存取方案。还要数据库干吗？把已经很成熟的技术再发明一遍，这就是吃力不讨好。 -newkid(newkid); 2007-8-9 (#3859729@0)

Google就自己做了不少轮子，卡迪拉克也自己作轮子，你还是先问问他们吧 -wuyg719(wuyg719); 2007-8-18 (#3878473@0)

EBAY的主营业务和GOOGLE不同，他们的IT投资应该在于应用而不是研发。 -newkid(newkid); 2007-8-19 (#3879738@0)

触发器太多了不好，但存储过程还是要用吧，如果一个sp运行很长时间，完成同样的功能，在其他层做不会更长？为了移植方便和结构清晰，还说的过去。Java写的数据库存储过程怎么没有人用呢？估计大部分人认为应该放在其他层吧 -palwang2000(sammy); 2007-8-9 (#3859147@0)
楼主引用的文章里面已经说明了理由，我也是赞成　少用存储过程的。　理由很多：难维护，难测试，存储过程的语言是一种简单的语言，不能完成复杂的任务 -wuyg719(wuyg719); 2007-8-9 (#3859687@0)

你的理由同样适用于non-sp方案。这完全取决于程序怎么写了 -newkid(newkid); 2007-8-9 (#3859724@0)

有意思，我们这正在尽量把business rule 用sp来实现呢。 -guestagain(guest again); 2007-8-10 (#3860904@0)
Although SQL looks like very simple, from data perspective, it’s very powerful. SQL itself is (data) set/table oriented. If you still try it in common language’s logic, it’s really waste. -deep_blue(BLUE); 2007-8-10 {858} (#3861437@0)

agree with the 2nd paragraph and there after. -bdbs(不多不少); 2007-8-10 (#3861562@0)

I used to work in a huge enterprise and was told to use SP whenever and wherever we can. Now I work here in a small company but still like the concept. SP is easier to develop, test and maintain not like someone mentioned abovebecause not need to re-compile the application in IDE like VS -marsher(住家男人); 2007-8-10 {61} (#3861522@0)

这个，怎么说呢，只能说时代变了。俺以前也是那么被教导的。所以上面咕咚说“sp - 说老实话，一下子不让我用还真有点接受不了”，我是很有同感的。 -bdbs(不多不少); 2007-8-10 (#3861572@0)

I don't have chance to consider system scalability kind of things. But if need to move SP to BL, it's really a challege. I re-wrote a SP with more than 1k rows and improve the performancefrom 1.5 hours to just 5 minutes in this company. But if move to BL, I really don't know how to achieve and how long it will take me to do that. -marsher(住家男人); 2007-8-10 {145} (#3861621@0)

1. 对已有的系统，尤其是大公司，不可能说改就改说移就移的，除非是象你这个例子中的critical situation(1.5hour)。所以这个你不用担心。New rule will only apply to the new systems. 2. if your DB only serves 1 or few AS,SP is still the best place to implement the business logic. -bdbs(不多不少); 2007-8-10 {59} (#3861636@0)

对于大型网站架构设计，一直是很令人关注的话题 -walacato(一天到晚游泳的鱼); 2007-8-11 {85} (#3862698@0)

太谢谢了！我就想看一些这样的文档。顺便也谢谢楼上所有的人，尤其是不多不少和newkid，很喜欢看你们掐仗啊：） -gudongfish(咕咚来了); 2007-8-11 (#3863165@0)
好人啊 -wuyg719(wuyg719); 2007-8-19 (#3878983@0)

大型web程序，SP和Triger都不应该使用。 -lok(lok); 2007-8-20 (#3881310@0)
如果你考虑用Oracle的话，强烈建议读一下Tom Kyte的Expert Oracle Database Architecture: 9i and 10g Programming Techniques and Solutions因为其中有关于如何考虑可扩展性的思路。并非简单的用或不用 -oftengo(PALO); 2007-8-25 (#3892364@0)

@Florida

Topic

More Topics