[thelist] Help with Database

Mark Groen markgroen at gmail.com
Fri Jun 3 02:18:21 CDT 2005


: Subject: Re: RE: [thelist] Help with Database
:
: scalability and robustness you need, and how you use it are your prime
: considerations. mySQL is simply not in the same league as SQL Server or
: Oracle
:
: Yup, good example here of the differences:
:
: http://www-css.fnal.gov/dsg/external/freeware/mysql-vs-pgsql.html
:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Interesting document. It doesn't list support for High Availability (HA)
though, which is certainly a requirement for enterprise use. Both Oracle and
SQL Server support clustering, and replication between geographically
dispersed servers. I'm not aware of native clustering support in mySQL.

HA clustering is being done with MSQL, albeit not to the same levels as
Oracle/SQL and it's not native, one implementation:
http://www.emicnetworks.com/index.php?option=com_content&task=view&id=32&Itemid=64

As the .gov link (sort of) shows, Oracle/SQL have already built in much of
what needs to be bolted on to MySQL for HA, other than physical redundancy
of course. For instance, in mysql, load distribution mechanisms are usually
combined with the power of *nix. Failover mechanisms are lacking, only
InnoDB tables have automatic crash recovery. Data synchronization is okay,
but definitely not as nice as Oracle when it comes to talking to other types
of databases. Oracle is clearly the leader at this level.

MySQL has it's faults, but for many it's a way of doing the job without
incurring the extra costs. If it's a truly large db install, there's going
to be some extra work out of the box to make things work, and the extra
costs of Oracle start to get slimmer as the time/resources you are spending
setting up MySQL increases exponentially, and Oracle starts looking better
all the time.

But, aren't we talking about a fairly small application from the original
poster and the types of queries would seem to be of the sort that could be
written to take little resources, with not *tons* of data crunching, but
lots of plain calls that MySQL's multi-threading should have no problems
with as long as the hardware keeps up.

Original poster: don't take my word for it in the paragraph preceding, my
first database in the 80's only held 18K rows, and the appy I wrote used
GOTO, those were the days lol, but been open source for so long don't know
the meaning of anything but GPL now and the others have much wider
experience on more types of databases than moi :-)

As I'm merely an amateur, (really, truly, - others like Ken S. have done
waaay more work with db's than me, I'm just an old fart and semi-retired now
with time on my hands once in a while to post, the quality of my db
architecture usually sucks and someone always comes up with something
better), putting my 2 cents in amongst such luminaries on this list and
stirring up the pot, opining MySQL would do just fine in this case.

As always, follow the links, read the white papers, and pick what will work
best for your particular situation.

cheers,

        Mark



More information about the thelist mailing list