| Author |
Topic |
|
jhermiz
3564 Posts |
 Posted - 2005-01-14 : 16:28:38
|
http://weblogs.asp.net/fbouma/archive/2003/11/18/38178.aspx
Keeping the web experience alive -- [url]http://www.web-impulse.com[/url]
|
|
|
ehorn
Master Smack Fu Yak Hacker
1632 Posts |
Posted - 2005-01-14 : 16:54:11
|
| It also proved to be an effective sales tool. Our company is evaluating several O/R Mappers, including his. |
 |
|
|
Merkin
Funky Drop Bear Fearing SQL Dude!
4970 Posts |
Posted - 2005-01-14 : 20:07:52
|
If by "interesting" you mean "wrong"  Damian |
|
|
|
ehorn
Master Smack Fu Yak Hacker
1632 Posts |
Posted - 2005-01-14 : 20:32:08
|
quote:
Originally posted by Merkin
If by "interesting" you mean "wrong"
Could you elaborate ?? |
|
|
|
nr
SQLTeam MVY
12543 Posts |
Posted - 2005-01-14 : 20:57:01
|
| think I've been involved in this one before.The arguement is that good embedded sql is better than a bad stored procedure.And that it is easier to get a good application developer than database developer.They may be true but it's not a good premise to base an architecture on.I'll go with Damian on this one.Just reading it it's obvious that there is a basic lack of understanding of design fundamentals.Reminds me a bit of the "normalisation is bad" post.Note - he's an application developer not a database developer.==========================================Cursors are useful if you don't know sql.DTS can be used in a similar way.Beer is not cold and it isn't fizzy. |
|
|
|
ehorn
Master Smack Fu Yak Hacker
1632 Posts |
Posted - 2005-01-14 : 21:28:16
|
| I have learned a great deal regarding SQL from both of you guys, and from other at this site. And it has proven to be a great experience for me. But in all honesty and humilty - I gain very little from vague responses like these. Can either of you, or other knowledgable SQLTeam members elaborate on what and why you disagree with the post? |
|
|
|
jsmith8858
Dr. Cross Join
7423 Posts |
Posted - 2005-01-14 : 22:05:07
|
| I disagree more with the title of his post than the content. The title states that "stored procs are bad", but the article itself mostly attempts to point out reasons in which in-line SQL is acceptable or "just as good as" using stored procs. He is really just defending dynamic SQL, not attacking stored procs. I didn't see any points (other than they are "another thing to maintain") that indicates are good argument AGAINST stored procs.Probably just a bad title, I guess (though he probably picked it to get attention).- Jeff |
|
|
|
ehorn
Master Smack Fu Yak Hacker
1632 Posts |
|
|
jsmith8858
Dr. Cross Join
7423 Posts |
Posted - 2005-01-14 : 22:34:09
|
Unfortunately, that was not a well-written stored proc at all-- it is about as inefficient as you can make a sql statement with optional parameters. And it also has nothing to do with using stored procs versus not using them -- you can build dynamic SQL within stored procs as well, similiar to what he did in code, if you like. too bad comments are closed on that post....  Seriously, it's pretty irresponsible to try to do an apples-to-oranges comparison like that, the way he did, just to "prove his point" -- he lost all credibility with me after seeing that post...- Jeff |
|
|
|
ehorn
Master Smack Fu Yak Hacker
1632 Posts |
Posted - 2005-01-14 : 22:39:14
|
| How would have you re-written the proc? I would be happy to re-run the tests given a tuned procedure. |
|
|
|
jhermiz
3564 Posts |
Posted - 2005-01-14 : 22:49:36
|
I'd really agree with nr, his point about him being an application developer and db developer. I also agree regarding the comment made on the design principles.I love jeff's comment about the comments being closed, didn't notice that until I double checked, so much for adding a bit of insight? Then again he's an MVP, he must be better than all of us :) (just a joke).I also think jeff's right, the title is catchy to the point where one says wow did he just say that, but no where in that entire thread is he giving any real reasoning behind sprocs being bad ... mkay ?
Keeping the web experience alive -- [url]http://www.web-impulse.com[/url]
|
|
|
|
ehorn
Master Smack Fu Yak Hacker
1632 Posts |
Posted - 2005-01-14 : 22:54:10
|
| Agree with this opinion - good point on that opinion. Blah, Blah, Blah...Can anyone offer up any objectivity. My kingdom for some objectivity!!Anyone... Going once, twice... |
|
|
|
jhermiz
3564 Posts |
Posted - 2005-01-15 : 00:28:54
|
We did...read the posts...the guy isnt making fair comparisons...nor is he saying why they are so bad?What exactly are you looking for ehorn? Did you read the blog entry ????? His title reads "Stored Procedures are Bad..mkay"...where in the article did HE back that up ???/????
Keeping the web experience alive -- [url]http://www.web-impulse.com[/url]
|
|
|
|
rockmoose
SQL Natt Alfen
3279 Posts |
Posted - 2005-01-15 : 06:38:19
|
| Bad title on the article.Somewhat of an architectural discussion stating that well designed O/R mappers and SP's can be "just as good".The calims&examples that sp's are worse than dynamic O/R mapping are not very wellfounded imo.One can discuss where it is appropriate to place the layer of code/interfaces that will access the data stored in the db.In the O/R mapper or in SP's.subjective opinion:I like to have the SQL close to the data (SP), btw a good O/R would provide access to sp's as well.objective opinion:This way the database itself will provide all the interfaces needed to access it's data, and can be reused by any client.rockmoose |
|
|
|
nr
SQLTeam MVY
12543 Posts |
Posted - 2005-01-15 : 06:52:00
|
| >> Can anyone offer up any objectivity.Read the article and think about what it is saying (or not saying).I was going to post passages but can't get through to it - maybe it's been taken down after all the criticism.==========================================Cursors are useful if you don't know sql.DTS can be used in a similar way.Beer is not cold and it isn't fizzy. |
|
|
|
ehorn
Master Smack Fu Yak Hacker
1632 Posts |
Posted - 2005-01-15 : 08:18:55
|
| Some years back, he wrote a ORM/Code Gen'er that was based on Sp's (his first version). It was a nice producticvity tool but he, and others, found it lacking in its flexibility and robustness for anything other than simple CRUD.Based on all "recommended" best-practices (ie. use sp's, sp's are good, sp's are fast, sp's are more secure, etc..) - and after spending many months evaluating how he could improve the framework in his ORM using sp's, he stepped back and looked at the business/value proposition of sp's versus d-sql from the following points:* Flexibility* Performance* Security* Productivity* OO Principlesand found no reasonable justification for sp's to be considered a best-practice over d-sql. Though he certainly recognizes the place where sp's have a benefit - in cases where you must manage multiple set-based processes (typically a result of performing all BL in the sp or complex aggregations). Now Object Oriented best practices say BL should be managed in the BLL not the DAL, and for good reasons (but that is another debate, and possibly another forum :) ). So he built a querying engine which can generate parameterized sql on the fly in a DAL and be marshalled from a code generated BLL, hence LLBL Gen.The article which Jon posted is one of many he has posted regarding this topic - and its interesting to see his transformational viewpoint from sp's as a framework to d-sql.... and his viewpoint seems justified based on his arguments, comments and tests. IMHO, a valuable discussion might contain support/refute to his claims. |
|
|
|
nr
SQLTeam MVY
12543 Posts |
Posted - 2005-01-15 : 08:29:23
|
| >> Now Object Oriented best practices say BL should be managed in the BLL not the DALThink that has been generally debunked now - although it still turns up occasionally.>> and found no reasonable justification for sp's to be considered a best-practice over d-sqlThe only arguements I've seen in favour of that are based on a misunderstanding of design principles.Usually starting off withIf you change the database structure you have to change the stored procedures and the application rather than just the application.If you change the pplication then you are forced to change the stored procedures as well.The article in question makes the same mistake as is often the case when systems are designed from the application viewpoint rather than acknowledging that the application is a user of data and the data structures should model the business entities.==========================================Cursors are useful if you don't know sql.DTS can be used in a similar way.Beer is not cold and it isn't fizzy. |
|
|
|
ehorn
Master Smack Fu Yak Hacker
1632 Posts |
Posted - 2005-01-15 : 08:45:30
|
OK now were getting somewhere - thanks for responding Nigel.>>The article in question makes the same mistake as is often the case when systems are designed from the application viewpoint rather than acknowledging that the application is a user of data and the data structures should model the business entities.A valid viewpoint, but some varying, and also valid, viewpoints are that db's describe data, relations, and constraints -- NOT behavior.eg. http://www.agiledata.org/essays/drivingForces.html>>The only arguements I've seen in favour of that are based on a misunderstanding of design principlesI believe these are valid viewpoints - do you?>>Think that has been generally debunked now - although it still turns up occasionallyWHAT??? man someone needs to tell the gurus (ie. GoF, The 3 amigos, Ambler, Fowler, OMG's MDA, etc..) that they are "livin in the past"  Can you elaborate on this point in the context of OO principles?But again, it is a question of viability of the posters arguments.. |
|
|
|
nr
SQLTeam MVY
12543 Posts |
Posted - 2005-01-15 : 09:14:32
|
| If you want to build an effiecient system you should carry out the processing where it is best suited.SPs are good at set based operations.You could retrieve all the data into the business layer, process it there using set based operations then update the database but that would mean treating the database just as a data store and buildning the relational processing features in another layer (and there are systems that do this) but why not just say that the business layer is a logical concept and that it can include SPs as well as application code.In OO terms it's the difference between design and implementation.I think it's humerous when people talk about OO in terms of languages. It's perfectly possible to implement an OO system in cobol or assembler.>> and also valid, viewpoints are that db's describe data, relations, and constraints -- NOT behaviorI think that's what I said.Therefore changing the data structure should not necessarily affect the application - that's what SPs are for.==========================================Cursors are useful if you don't know sql.DTS can be used in a similar way.Beer is not cold and it isn't fizzy. |
|
|
|
rockmoose
SQL Natt Alfen
3279 Posts |
Posted - 2005-01-15 : 09:23:57
|
| >> Now Object Oriented best practices say BL should be managed in the BLL not the DALIn my world the DAL doesn't enforce any BL, it is a "dumb" layer that mechanically passes data to&from a db.BL should be enforced in the database, that's what constraints etc are used for.A well written application will make sure that any Objects also enforce BL, (eg. not inserting order before customer).>> A valid viewpoint, but some varying, and also valid, viewpoints are that db's describe data, relations, and constraints -- NOT behavior.Nobody said that the db should describe behavior.>> found no reasonable justification for sp's to be considered a best-practice over d-sqlAlso no reasonable justification for d-sql to be considered a best-practice over sp's* Flexibility (comes in many flavors, it depends...)* Performance (well, I would say sp's can be tuned and optimized to a greater extent than d-sql)* Security (wouldn't it be easier to manage sp security ?)* Productivity (wouldn't this depend on the skillset of the developers)* OO Principles (is there really a conflict between sp & d-sql here ?)rockmoose |
|
|
|
ehorn
Master Smack Fu Yak Hacker
1632 Posts |
Posted - 2005-01-15 : 09:42:14
|
| Morning Rockmoose,>>Nobody said that the db should describe behavior... I hate to steer the discussion towards this (which is why I made the caveat). I will only state my opinion in the context of BL- I view behavior as application specific BL. This isn't to say it cannot be performed at the db level also (ie constraints, sp's, etc.. from a data integrity standpoint) But I think there is validity in saying application specific behavior (ie. business rules) belong in the application(s) BLL. There are strong arguments along the lines of "seperation of concerns" which leads to pushing behavior away from a data repository. I will certainly not disagree with validation in all application layers, nor will I contest the critical importance of the db as the last and most important line of defense in support of data integrity.>>Also no reasonable justification for d-sql to be considered a best-practice over sp's Exactly my point - they are both viable>>* Flexibility (comes in many flavors, it depends...)>>* Performance (well, I would say sp's can be tuned and optimized to a greater extent than d-sql)Again, there are instances where sp's will out-perform d-sql - I am certainly not arguing this but for the majority of crud there appears to be no performance benefit. In fact in some instances - the contrary has been displayed. I would love to see a re-test of his search proc. Any takers on tuning that?>>* Security (wouldn't it be easier to manage sp security ?)How so?>>* Productivity (wouldn't this depend on the skillset of the developers)Yep..>>* OO Principles (is there really a conflict between sp & d-sql here ?)Well only in the context of where you put your BL and design principles. Though these all tie in with coupling, cohesion, "seperation of concerns", flexibility, maintainability, n-ility :) |
|
|
|
Next Page
|
Interesting Article