This topic has been archived. It cannot be replied.
-
工作学习 / 专业技术讨论 / bdbs(不多不少)大虾，请就你的题目#3859150给出你的完美解答，谢谢！
-newkid(newkid);
2007-8-10
(#3860931@0)
-
刚逛了一下ebay,他们的category也就六层，除了第二层多一些（几百个），其他层都是十来个条目。
-newkid(newkid);
2007-8-10
(#3860951@0)
-
说了俺的不示人的#3859245，不过类似的方法在以前和你一起参和过的贴子里有提到过。：） 说说你的#3859722吧，你觉得performance会怎么样？就按照eBay百分之一的数据量来考虑好了。
-bdbs(不多不少);
2007-8-10
(#3860987@0)
-
没劲，你这态度可不利于共同进步。我这SQL是基于你的表设计做的，真要提高performance那方法可多了。但全都是数据库的solution,全部适用于在sp中实现。ebay的最多一类也才百万；如果一万行的数据怎么折腾都行，响应速度都不会差。
-newkid(newkid);
2007-8-10
(#3861031@0)
-
兄弟啊，你没考虑流量。你一个SP假如执行速度那怕是0.01s，如果同时有一千个request，就是10s，还不算Web Server, Web Application Server的响应时间和DB Server的其它load。逻辑性事务如果从DB移到Application layer，可以很容易地靠增加Web Server/Application Server来分担工作量。DB clustering当然也可以，不过要比application load balance复杂得多，牵涉到data synchronization的问题。所以原则上是，能让application干的就不要让DB去干。DB就做最简单的操作。
-bdbs(不多不少);
2007-8-10
{217}
(#3861079@0)
-
1.你这个例子结果集很小，network traffic 可以忽略 2.别忘了数据库有cache,它不会傻傻地反复执行同样的查询 3.你这例子再怎么解决，都不能缓解数据库负担。你最多把遍历树的部分在AS做掉，但这对数据库而言是小菜一碟，重头在product表的查询4.DB clustering 成熟可靠，它的同步要比 AS 的CACHE同步稳定且快速
-newkid(newkid);
2007-8-10
{63}
(#3861119@0)
-
1.not the traffic between web server and the db server, but the requests submitted from the web server to the db server. 2. there's always the balance between the cache and real time, plus, the caching can only cache the distinct query.a slight parameter change will be treated complete different queries and won't be cached. 3. the sample was not to find the best algorithm, but intend to show SP is not a good solution 4. DB clustering can never be better than AS clustering.
-bdbs(不多不少);
2007-8-10
{243}
(#3861351@0)
-
1.不用SP的话request更多，本来一次调用变成了多次执行SQL. 2.data buffer就是干这个的，数据库比你更清楚表改过了没有。只要PRODUCT表没改过就不用再读盘。不用SP你照样要查PRODUCT表! 3. 4. 无法继续讨论
-newkid(newkid);
2007-8-10
(#3861376@0)
-
product表是没改过，可是如果每次where condition不一样，还要不要重新读盘了呢？再说，high traffic web appliation里又不仅仅是这一两个query，新的query会很容易地把老query的结果从cache里冲掉的。
-bdbs(不多不少);
2007-8-10
(#3861421@0)
-
"product表是没改过……" 难道你在SP外算出所有树叶，多次SELECT就不必读盘？每个树叶的数据都不一样！
-newkid(newkid);
2007-8-10
(#3861452@0)
-
见#3861539内容部分
-bdbs(不多不少);
2007-8-10
(#3861549@0)
-
同意,跨SERVER SQL从来不是强项.AS能最主动地分配WORKLOAD.
-findinghouse(不写错别字。8);
2007-8-10
(#3861239@0)
-
AS能分配的只有它们自己的本分工作。到最后，所有SQL一条不少地全部得提交给数据库执行。
-newkid(newkid);
2007-8-10
(#3861384@0)
-
第一：虽然一条不少，但由复杂query变成简单query，DB负担有减无增。第二：相似query成为相同query，使得query result能够被DB cache，进一步降低DB负担。
-bdbs(不多不少);
2007-8-10
(#3861406@0)
-
"由复杂query变成简单query"这是优化器做的事情，你认为你能做得更好? "query result能够被DB cache" 这我上贴说过，你终于也承认这点了。
-newkid(newkid);
2007-8-10
(#3861423@0)
-
1. 优化器难道不占系统资源？ 2. 优化器也是人做的，为什么我就不能做得更好？ 3. 就算我做得不如优化器，优化器把100%的load降到10%，我只能做到20%，同样接受10个AS的访问，前者要用到10%*10=100%的DB资源，后者仍旧是20%。孰优孰劣？3. 我没有否认过cache的功用，但是cache有其局限性。select * from table where id > 1 和 select * from table where id > 10是两个不同的query，无法被cache的。
-bdbs(不多不少);
2007-8-10
{152}
(#3861479@0)
-
1. 同意，但优化器生成计划是一次性的，优化后可反复使用 2.虽然不100%同意但仍表示钦佩 3. 不明白你的20%为什么就是一个常数而不是10*20%select * from table where id > 1 和 select * from table where id > 10是两个不同的query，无法被cache的。
这也同意，但也说明了你多次算每个树叶的QUANTITY并无捷径可走，不能减轻数据库负担。
-newkid(newkid);
2007-8-10
{187}
(#3861514@0)
-
3. 因为逻辑在AS中实现，没有额外的负担加给DB。10个AS提交的是10个完全相同的query，所以DB只需忙活一次。最后，如果一个query完成整个树的quantity，然后由AS来决定是取其中一个树叶还是一段树枝或者整个树，数据库负担是否能被减轻呢？
-bdbs(不多不少);
2007-8-10
{121}
(#3861539@0)
-
"DB只需忙活一次"明明是一个SQL要分解成多个还说是一次？"如果一个query完成整个树的quantity"你是指SP方案还是NON-SP? 你的意思是总数应该由AS来计算?
-newkid(newkid);
2007-8-10
(#3861589@0)
-
what if I can use only ONE query to get the full list of Category ID, Category Code, Quantity?sample result
Category ID, Category Code, quantity
0, , 70 <---- Root
1, A, 50
2, AA, 30
3. AAA, 12
4, AAB, 7
5, AAC, 11
6, AB, 10
7, AC, 10
8, B, 20
9, BA, 12
10, BB, 8
-bdbs(不多不少);
2007-8-10
{183}
(#3861657@0)
-
如果这是你的方案，那么我们是一致的，只不过我把它包在SP中。这样的好处是让DB developer容易维护、调优。如果你的意思是只执行一次（从根开始）然后CACHE住让所有AS访问，那么请问你何时刷新你的CACHE?
-newkid(newkid);
2007-8-10
(#3861679@0)
-
upon business requirement, can be either pre-set time or on demand. 如果你有一个SP可以返回指定树枝或树叶的quantity list，相信application developer绝对不会每次都去拿整个树，然后在AS中找出自己要用的那部分。于是程序中不同的地方必定会有不同的SP call，DB就要接受到不同的request，反复去做相似的工作。
-bdbs(不多不少);
2007-8-10
{90}
(#3861712@0)
-
还是不懂……把SQL写在AS中而不是SP中，AS developer就会想到CACHE方案？如果允许用CACHE而不是实时数据，那么数据库也有定时自动更新的快照，不管调用几次都不怕！
-newkid(newkid);
2007-8-10
(#3861760@0)
-
1. 你可以要求AS Developer怎么做 2. 如果是OO language，可以用一个private method来读DB的数据，public method通过调用这个private method外加一些简单逻辑来得到结果。很多办法，可以确保调用同一个query。至于cache不cache，就没AS developer什么事了。
-bdbs(不多不少);
2007-8-10
(#3861798@0)
-
1.你也可以教育程序员如何调用SP 2.适用于SP 3.cache问题：如果不要实时数据，数据库快照是很好的解决方案因为其他系统也可共享到这个计算结果而不是仅存于某套系统的CACHE中
-newkid(newkid);
2007-8-10
(#3861818@0)
-
如果你有一个SP，需要接受一个参数，那么不管你怎么教育，AS Developer每次调用都会是一个不同的query request。你怎么牛角尖里还钻不出来呢？这里讨论的不是能否实现的问题，而是如何给DB减负，提高整体Application的Performance。
-bdbs(不多不少);
2007-8-10
(#3861843@0)
-
是因为SP有参数的原因？你才在牛角尖里呢。我所有帖子没有一个不是跟PERFORMANCE相关的，包括你现在说的非实时CACHE,数据库都能给出很好的解决方案。
-newkid(newkid);
2007-8-10
(#3861880@0)
-
从维护角度，如果不用SP而用一个query能实现，就可以做成VIEW。DB Developer一样可以维护。
-bdbs(不多不少);
2007-8-10
(#3861729@0)
-
这我也同意，但如果没有一种方法把起点category id传给view,每次从view查数据的时候，都得被迫算整棵树，哪怕我只要其中一个枝。用ORACLE是有办法把参数PUSH到VIEW的WHERE CLAUSE去。
-newkid(newkid);
2007-8-10
(#3861771@0)
-
是的。这个例子就是要被迫查整个树，这样query result才能被cache住。
-bdbs(不多不少);
2007-8-10
(#3861802@0)
-
这种问题弄不出一个标准答案的，侧重不同.乐趣就在于争论过场大家能听到不同意见。不能求有结果.
-win(秋天的菠菜);
2007-8-10
(#3861046@0)
-
扩展Category Table: 加一个LEVEL列.0 代表自己,1代表儿子,2 代表孙子.... 这样避免递归.
-findinghouse(不写错别字。8);
2007-8-10
(#3861063@0)
-
yeah, that is what my company is doing. do not have problem on the performence, here.
-win(秋天的菠菜);
2007-8-10
(#3861066@0)
-
光保存层数还不够，最好把从叶到根的整个路径保存下来。
-newkid(newkid);
2007-8-10
(#3861099@0)
-
there would be a record for self<-->grandson and so on
-win(秋天的菠菜);
2007-8-10
(#3861111@0)
-
yeah, that's the idea in my solution. all the detail information are built into the id, but not in the 1.2.3.4 format. 1.2.3.4 format is not good for querying
-bdbs(不多不少);
2007-8-10
(#3861120@0)
-
你最好还是不要打ID的主意。ID应该是终生不变的，而你却说整个分叉有可能挂到别的枝条下。另外弄个FIELD,字符串型就能够很好的索引，绝不亚于你的秘方。
-newkid(newkid);
2007-8-10
(#3861136@0)
-
#3861315
-bdbs(不多不少);
2007-8-10
(#3861329@0)
-
这就是你的方法？和我说的并无本质区别，只是去掉了中间的点。去掉点就必定用固定位数（他的方法是用一位，你也就是多用几位吧？）能表示的就很有限。
-newkid(newkid);
2007-8-10
(#3861362@0)
-
对，其实12.34.56和这个方法一样的，就是串长一些，好处是subcategory无限。另外改分叉很容易：in my application, the category_code is always start with ^:
^A , ^AA,^ABC
update products set category_code =
replace ( category_code, '^'+old_code, '^'+new_code) where category_code like '^'+old_code
-holdon(again);
2007-8-10
{218}
(#3861397@0)
-
你这是category_code，不是category_id，当然可以改。一开始他说在ID上做文章，我的意思是ID不能动，必须另外搞个field,比如你这个category_code.
-newkid(newkid);
2007-8-10
(#3861411@0)
-
你这有点咬文嚼字了，我之前说的ID上做文章指的是#3859150 Product Table里的category id。用Category Code取代Category ID难道不是在ID上做文章么？再说，ID就非得被spelled as ID么？Category Code在Category Table里本身不能做ID么？谁规定ID就不能动呢？能不能动应该由Business Requirement来决定。
-bdbs(不多不少);
2007-8-10
{62}
(#3861458@0)
-
这下子看来，你的认识确实有误。PRODUCT 上的CATEGORY ID 是不能改的。每次改动分类结构只能动CATEGORY表。不管你叫它ID也好，CODE也好，PATH也好，总之就是改CATEGORY表。你愿意UPDATE PRODUCT这样一个大表？
-newkid(newkid);
2007-8-10
(#3861474@0)
-
我之前只是提出一个idea而已，上面这个贴是依据holdon (again) 的贴#3861315说的 。改不改由business requirement决定。你说的这个case当然不改为好。喂，别扯远了，咱们是讨论SP不SP的问题。咕咚要改名叫咕咚笑了呢。
-bdbs(不多不少);
2007-8-10
(#3861507@0)
-
能表示的什么很有限？固定位数不仅可以很容易得到hierarchy，得到level，也可以很容易地被join。你的方法是无法轻松实现select sum(quantity) from product where category_code like ('AACC%') 的
-bdbs(不多不少);
2007-8-10
(#3861413@0)
-
你看过我的SQL没有？SELECT SUM(quantity) FROM vw_all_quantity v2 WHERE v2.connection_path||'/' LIKE v1.connection_path||'/%'这是干什么的？
-newkid(newkid);
2007-8-10
(#3861435@0)
-
要注意我的SQL是忠实地基于你的表结构的，所以我自己用子查询算出了connection_path。要不然只要一次SELECT就可以了。
-newkid(newkid);
2007-8-10
(#3861445@0)
-
结论是：提高performance要从整体考虑。数据结构的设计直接影响到整个项目的性能。如果有用复杂逻辑在SP里的必要，不妨尝试1.改变数据结构；2.改变AS中的数据调用逻辑
-bdbs(不多不少);
2007-8-10
(#3861525@0)
-
我真服了，我那不是在接你的招吗？当然就按你的题目来做。要是我自己的项目，我当然有自己的设计了。
-newkid(newkid);
2007-8-10
(#3861540@0)
-
我本来就是说用SP能实现，但不是好的solution。是你自己要坚持走SP的路线，怎么能怪我？你的方法改动一下，也可以成为一个单独的query而不需要SP。而且，query能被cache，SP不能吧。
-bdbs(不多不少);
2007-8-10
(#3861544@0)
-
SP的代码能被CACHE; 运行结果有时能，有时不能；SP里面每个SQL都归SQL引擎管，这是另一个CACHE
-newkid(newkid);
2007-8-10
(#3861559@0)
-
这个我同意。我指的是有时能有时不能其实是大多数情况不能的运行结果。
-bdbs(不多不少);
2007-8-10
(#3861565@0)
-
“但不是好的solution”恰恰相反，在这个设计还不完善的例子中，SP也是不逊于NON-SP solution. 难道你不用SP就能变出一个connection path 来？
-newkid(newkid);
2007-8-10
(#3861569@0)
-
看我原贴#3859150“当然不是简单地“把实现business logic的部分用另一种语言实现”，如果是那样，还是用SP吧。” #3858777“真正的performance来源于数据库的合理规划和设计以及应用程序清晰简洁的逻辑，而不是靠stored procedure来获得。”
-bdbs(不多不少);
2007-8-10
(#3861587@0)
-
直到目前也没看出你如何靠放弃SP来提高性能。改善数据结构设计只会让SP受益，而不是说可以把部分计算转移出去。
-newkid(newkid);
2007-8-10
(#3861610@0)
-
我觉得你有点在钻牛角尖了。
-bdbs(不多不少);
2007-8-10
(#3861590@0)
-
我说的全是实在话，但你始终没有说明不用SP该怎样做，不愧是太极高手！
-newkid(newkid);
2007-8-10
(#3861626@0)
-
我说了，只是你钻在自己的牛角尖里了不明白。#3861657
-bdbs(不多不少);
2007-8-10
(#3861663@0)
-
如果要遍历某个节点下的整个树叉，光有level还是不能避免递归的。
-bdbs(不多不少);
2007-8-10
(#3861089@0)
-
没有用过SQL2K5 Hierarchy Query 吗?1. you can use table function to return all the children and inner join with Product Table to calculate the quantity sum.
2. I wouldn't query over the live table if you are afraid the query affects the live server, I would make a copy to another table or SSIS to another server.
3. The performance wouldn't be bad and no path required.
-sunday8(sunday8);
2007-8-10
{343}
(#3861666@0)
-
那也能叫query么？看看一个简单的request得做多少事。你的DB哪怕仅仅serve一个AS也能被crash掉。
-bdbs(不多不少);
2007-8-10
(#3861693@0)
-
well.. You have 3 choices. 1. use SQL2k5 Hierachy query, 2. Build our own recursive query 3. use SSIS. SSIS can be automated, so user request is over result table instead of live query. It wont crash your DB.
-sunday8(sunday8);
2007-8-10
(#3861743@0)