>On Sat, 06 Jul 2002 15:27:47 -0500 >> Do you have *ANY* idea how quickly: >> >> "select * from MyTable" can be parsed and an execution plan selected?! >> >> It's CHUMP CHANGE in time. >> >> *ONLY* if your SQL is so incredibly complicated that you can't even >> understand it will the parse/compile time of SQL be a factor in >> performance. > >It is "CHUMP CHANGE" when you make a tinie web site with 2 users. Do the >math. If you have a SQL statement that takes 250 milliseconds to parse >and create an execution plan, then 250 * 1,000,000 page request per week >(which is what the site I finished averages, the company I >work for has 110,000 employees) = ??? This is second grade math. > >No matter how you look at it, 10 extra milliseconds here or there >adds up when you work on a big site. The db's I work with are not >simple "select foo from bar" queries. An enterprise db is usually pretty >complex. My main reason for posting a reply was not to start a stupid >flame war with you. It was from stopping you from filling the heads of >new programmers on this list with bunk. Stored procedures are not junk! >I wonder why they are the most requested feature for MySQL? Why would all >the Big DB's (Oracle, DB2, PostgreSQL, SQL Server, etc.) support them >if they had no benifit? The biggest benifit is SPEED, the second is >the ability to encapsulate the underlying database structure. A DBA can >change the db structure at will as long as the sproc returns the same >columns.
Yes, if your site gets millions of hits, an SPROC can improve raw SPEED. And it *MAY* be the only option available to wring out that performance you need. There are some significant down-sides to the administration of SRPOC, as I noted earlier. The company I was working for was *NOT* getting millions of hits, had no *CHANCE* of getting millions of hits, and mindlessly wasted weeks' of developer time and drastically increased maintenance costs because "SPROCS make it faster" has been the watch-word. Their DBA was their chief IT who was their main lead developer, and then there was me. Two programmers in the entire 7-person company. If somebody actually *HAS* a system large enough to need SPROCs and *has* a DBA who isn't also the chief-bottle-washer, they almost-for-sure don't need me, or you, to tell them about SPROCs. :-) My primary concern is the little guy who's going to run out and change their entire architecture around for a 3000-hits-a-month web-site because they keep hearing "SPROCs will make it faster" without anybody ever bothering to mention little things like "overhead" and "administration" and "maintenance" to them. I'm sorry my rant touched off a nerve, and if there *IS* anybody stuck with a million-hits-a-day site, by all means, *TEST* some SPROCs and see if they improve your performance enough to make the maintenance hit worthwhile! By all means, *DESIGN* the darn thing with as many layers of solid, clean, simple API as it takes. But if you're trying to improve page load speed on a low-traffic site, SPROCs are almost for sure not your answer. If you don't even *have* a speed problem, running out and spending a gazillion $$$ worth of people-hours on SPROCs is downright silly. -- Like Music? http://l-i-e.com/artists.htm -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
