List:General Discussion« Previous MessageNext Message »
From:Matt Davies Date:January 6 2004 3:17pm
Subject:Re: Bet the Business
View as plain text  
As I understand stored procedures:

Stored procedures offer a level of performance that you normally can not
replicate in code. The stored procedure actually has the query stored in the
query parser ready to rumble. You do not have to invoke network or socket
overhead in calling a long query and you do not have to invoke the query parser
at each invocation of the procedure. Hopefully, the procedure takes advantages
of the caches found in most database servers. Theoretically, the performance
gains are tremendous if you can knock out network access and the CPU cycles of
parsing the query.

That being said, I am a fan of MySQL and would use it over MSSQL any day. Not
having sub-selects, stored procedures, and until recently transaction support I
have found programmatic methods to get around these issues. 

My experience has been this - let the application that is closest to the data do
the manipulation. This is true if the primary purpose is to store, retrieve,
and manipulate data. So, when MySQL supports stored procedures you will see,
again, a jump in usability and performance.


Quoting ian.orourke@stripped:

> Quoting robert_rowe <robert_rowe@stripped>:
> > 
> > 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
> 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:
> To unsubscribe:

Bet the BusinessIan O'Rourke6 Jan
  • Re: Bet the BusinessDaniel Kasak6 Jan
  • Re: Bet the BusinessJochem van Dieten6 Jan
  • Re: Bet the Businessrobert_rowe6 Jan
    • Re: Bet the Businessian.orourke6 Jan
      • Re: Bet the BusinessMatt Davies6 Jan
  • Re: Bet the BusinessMichael Bacarella6 Jan
  • Re: Bet the Businessrobert_rowe6 Jan
    • Re: Bet the BusinessIan O'Rourke6 Jan
    • Re: Bet the BusinessMartijn Tonies6 Jan
  • ..mysql question bank.. Needed..Amanullah7 Jan
  • Re: Bet the BusinessMike7 Jan
    • Re: Bet the Businessian.orourke7 Jan
  • Re: Bet the Businessrobert_rowe7 Jan
  • Re: Bet the Businessrobert_rowe7 Jan
RE: Bet the BusinessDan Greene6 Jan
Re: Bet the BusinessUdikarni7 Jan