>Stored procedures are like any other type of programming construct. >You can do them right or you can do them wrong.
Yeah, and GOTO is perfectly fine... In the right place. >When making a stored >procedure you should stick to ansi SQL as much as possible. All my SQL was so dirt-simple, it couldn't have been non ANSI. select name, skill from applicants where job_id = $job_id >Most of >my stored procedures I can move from a SQL Server 2000 box to an Oracle >8i box with not problems at all. Oh they *MOVED* okay. Now update the Stored Procedures for sub-section A of your on-line application on the Development box, and try to push the changes through to the Production Server. So, which Stored Procedures got changed? You have to keep track of them all, cuz MS sure doesn't. >Stored procedures are NOT over head. They are a *LOT* of painful administrative overhead, and their gains are mythical, not real. >If you need to change an SQL statement, then you would have to search >through all your code to make changes intstead of just one stored proc. Bullshit. If I have to change an SQL statement, I know right where it is, right where it belongs, right in the code. >If you don't see any speed increase from stored procs then you are doing >something wrong. Stored procs are compile SQL statements. Every >time a your php page does something like $query="Select * from MyTable" >the DB needs to parse the query and create an execution plan. 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. >The stored >procs do it only ONCE the first time it is ran and all the other calls to >it save you many millisecond to seconds. That might not sound like much >but if you have a site with more than 5 users you will see a difference. >The intranet I finished for my company has 100,000 users and sustains >almost 1,000 users per second. The pages took 7 to 10 seconds without >stored >procs and went down to 3-4 seconds with them. *NOTHING* else changed, except you went to stored procedures?... I'm from Missouri. Show me. >Also, new features needed to >be >added to the site and required some tables to be changed. I only had to >change >one SQL in on location and everything was fine. I only have to change one SQL in one location, and everything is fine. -- 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
