I've found, in my many years of app dev work with Oracle, MSSQL, and now a little MySQL, that stored procedures are a very mixed blessing.
Depending on your application architecture, they be just what you want, a means of encapsulating a complicated, data-centric function. Database stored procedures are notiriously difficult to manage in terms of version management, mostly due to the advance of excellent GUIs for editing stored procedures directly in the DB (TOAD). The other major drawback is that unless your entire application in based in the database (e.g. Oracle's web toolkit) then it adds another language to your application, as well as another location for code. This obviously increases maintainance time/cost, which is acceptable sometimes, but not others. I am definately _for_ stored procedures. Especially in MySQL -- between SP and subqueries, most of the limiting features of MySQL are going away, and Oracle and MSSQL folks will have less and less ground from which to point fingers. Just remember that they are not a magic bullet, and try not to mix too much of your application and/or business logic directly in them. [stepping down from soap box] > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: Tuesday, January 06, 2004 10:01 AM > To: [EMAIL PROTECTED] > Subject: Re: Bet the Business > > > Quoting robert_rowe <[EMAIL PROTECTED]>: > > > > > I'm lead developer for a company that writes custom > software for the mining > > industry. We support MSSQL and MySQL. I've found that from > a programming > > aspect (VB + ADO) there is relatively little difference > between MSSQL and > > MySQL. There is some sight syntax differences and MySQL > versions < 5.0 do not > > support stored procedures. We use the InnoDB table type for > MySQL as it > > provides row level locking and transactions. Our largest > client has about 1 > > gig of data and averages 125 users. I've found that MySQL usua > > lly out performs MSSQL if you tune it properly and use good > programming > > techniques. It is less integrated with Microsoft products > though so if your > > clients will be accessing the data via MS Office > applications then MSSQL will > > seem easier. We offer both platforms mainly because a lot > of IT managers are > > convinced that Microsoft solutions are the best even when > benchmarks say > > different. > > > > I admit to dome degree I am one of the IT Managers - the it > 'sounds to good to > be true' syndrome I suppose. But I'm coming around. The > decision will be for > MSSQL Server due to us using other MS products and the > supporting of one > product, but I'm interested for future reference when it does > become an option > (probably other jobs). > > As an aside, stored procedures seem to be a big thing with > some people, namely > the MS people I encounter (the ASP.NET mantra of using stored > procedures for all > databases access and even processing tasks), yet people seem > to get along with > them fine, until recently, in MySQL. > > This makes me thing they may not be the holy grail people say > they are...in > MySQL, until recently, all SQL must have been done at the > code level rather than > at the database server level - is that a major issue? Does it > even provide some > advantages? > > > -- > MySQL General Mailing List > For list archives: http://lists.mysql.com/mysql > To unsubscribe: > http://lists.mysql.com/[EMAIL PROTECTED] > > -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
