[thelist] MySQL vs MS SQL

Ken Schaefer ken at adOpenStatic.com
Thu Feb 19 05:10:40 CST 2004

From: "Hershel Robinson" <hershelr at netvision.net.il>
Subject: RE: [thelist] MySQL vs MS SQL

: > : MS SQL has support for transactions, built in load balancing
: > : solutions in the enterprise product line, and a number of
: > : advanced features which might make scaling
: > : the business a lot easier.  ODBC overhead can become a
: > : factor in high traffic environments.
: >
: > This is where I agree totally with Jonathon. SQL Server (and
: > DB2, Oracle
: > etc) are true enterprise RDBMSes, and provide the feature set
: > that will (a)
: > keep your DB Server up and running (provided you have a
: > competant DBA) and
: > (b) scale to anything you throw at it.
: The client says that $5K for a single processor license is doable if I
: it is the right way to go. That's the price for Standard Edition. He says
: $20K for Enterprise is beyond the budget at this point.
: Can I ask if anyone can confirm that Standard Edition SQL Server 2K will
: indeed outperform MySQL? And to what degree?

What are you looking for? Performance or scalability? Usually these are
opposites (for a while). A simple system will outperform a more scalable
system at low loads (a classic example is ASP pages -vs- COM objects).
However, the simple system will not be able to scale, and will eventually
just fall over. If you want examples of how you can scale enterprise DBMSes,
take a look at: www.tpc.org

Additionally, if this is some kind of system that absolutely requires
database integrity, then you need the type of enterprise features that are
available in DB2, Oracle or SQL Server.

Secondly, you'll never get a definitive answer to your question. Whilst a
particular system may perform faster in scenario x, it won't perform faster
in scenario y. However, a lot comes down to the administrator. A competent
mySQL admin will probably be able to get much more out of mySQL than a lousy
SQL Server admin.

: > I understand that you application is built using Perl, and if
: > you do use
: > ODBC to connect, then it can become a bit chatty as ODBC is
: > COM-based. If
: > you migrate your application to .Net, then you can take
: > advantage of the
: > native providers in .Net which are much more perfomant (there
: > are providers
: > for a few different DBMSes available).
: There are methods aside from ODBC to connect from Perl to SQL
: Server. Can you explain (or anyone) what it means that because
: ODBC is COM-based it can become a bit 'chatty?'

I'm referring to the amount of information that needs to be marshalled
across process boundaries, or across the network. COM is (relatively)


More information about the thelist mailing list