[ale] MySQL training?

[Greg]

I have followed MySQL for awhile now and am somewhat amused at it's
evolution/revolution/what have you.  MySQL was designed in the beginning to
support internet development via a *FAST* and simple database that was
tailored specifically for the gross majority of internet database
operations - i.e. simple reads from a database and now and then simple
inserts.  If you wanted other stuff then (at that time) you could program it
in C or whatever you were using to accomplish your goals or use something
else.  Transactions, views, whatever was done via programming.  MySQL was
not for you.  If you had to use something that had to be *FAST* as a primary
requirement, then you were not likely to be a simple web programmer working
for a small company but more likely someone who was dealing with very big
databases, complicated applications, a cast of thousands, and could do it
easily in the programming layer and not in the database.  It was not meant
to be a true textbook ACID compliant RDBMS.  It was simple and easy because
it was designed to be *FAST* first and foremost .... and then came the
wanna's ... we wanna it be like Oracle/MS SQL/DB2 ... we wanna triggers  ...
we wanna nice GUI admin screens ... we wanna  this and we wanna that.  So
they tried to resist this and failed.  At first MySQL said they would only
add features *if* they wouldn't slow it down (since speed was it's main
claim to fame and primary purpose), but after a while they stopped holding
the line on this since you can't have your wanna's and be fast at the same
time.  Regardless of the fact that these features make it slower (like
everyone else) the folks that do MySQL started to come under the sway of the
crowd and started adding them.  Kinda like PHP has caved in to the wanna
OO/wanna C++/C#/J2EE crowd ... kinda like MS has caved in to every ... well
you get the idea.  The fact is that about 95% of the time DB work is done
with 5% of the features of a DB and the old MySQL had/has that 5% already.
Simple stuff is the main order of the day and all of the "hot" features of a
commercial RDBMS are simply not needed.  5% of the time someone will need
triggers, views, stored procedures, etc (in this case use as in "95% of the
time" we use this stuff) and they are usually in cases where they can afford
and should be using something with all of the bells and whistles.

So it really comes down to using the right tool for the job - and hoping
that there are more projects that will resist the "wanna's", or there will
be in the future just one type of database - slow, ugly, and expensive.  If
you don't know what I am talking about, then look at Sun's crappy half-assed
attempt at an IDE (bigger and slower than MS's Visual Studio - even on a
dual processor box) or how some Linux distros have now turned into Windows
wanna-be bloat-ware with every unix server turned on for the world to
exploit.  Compare that to really tight operations like OpenBSD, Slackware,
Debian, etc ... that don't give a damm about wanna's but are focused on 1
thing and doing that 1 thing better than everyone else with no apologies to
the wanna's of the world.

Greg

> -----Original Message-----
> From: ale-bounces at ale.org [mailto:ale-bounces at ale.org]On Behalf Of Greg
> Sabino Mullane
> Sent: Tuesday, June 15, 2004 7:48 PM
> To: ale at ale.org
> Subject: Re: [ale] MySQL training?
>
>
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> > And, to be honest, most of the stuff we need doesn't especially need
> > the likes of triggers, views, etc... and besides, I'm not too much of
> > a fan of such things since my impression has been that the performance
> > gains that they bring often come at the expensive of transparency and
> > ease of deployment/porting/etc.  It may be ignorance on my part but I
> > have a feeling that a lot of the pro-postgres/anti-mysql sentiment
> > stems from a lack of understanding of mysql's new features (particularly
> > in non-myisam databases) and from a general snobbishness about these
> > things (which is the same snobbishness as tends to scorn PHP,
> etc.) .. :)
>
> What happens when you grow and start to need some of those (I would argue
> basic) features such as views and triggers? One of the major complaints
> about MySQL is that they don't follow recognized standards and make a lot
> of their own proprietary extensions to their products. Disliking that and
> the lack of features is not snobbery, it's expecting a product calling
> itself a RDBMS to act like a RDBMS.
>
> You should also realize that MySQL is now only "free" for certain defined
> circumstances. It is run by a single company, which (naturally) wants to
> make money. As opposed to PostgreSQL, which is still (and should
> always be)
> a completely volunteer effort, BSD-licensed and open-source.
>
> > At any rate, in my environment I would say that MySQL was a
> pretty decent
> > fit: there're more people here who understand it, and there's a greater
> > potential base of people to come and hack away on it.
>
> > I'm not in any way trying to incite any argument here; just noting that
> > mysql is generally fine for the tasks I'm working on.. and I think it's
> > generally better from a development standpoint to work with
> something you
> > broadly understand rather than learning something else because it's
> > "better".
>
> Kind of like Windows and Linux, huh? <grin>
>
> - --
> Greg Sabino Mullane greg at turnstep.com
> PGP Key: 0x14964AC8 200406151947
>
> -----BEGIN PGP SIGNATURE-----
>
> iD8DBQFAz4rrvJuQZxSWSsgRAjaZAJwOhc10rKfDZPpBM2Z/fyS2lOMzywCeLIfj
> V0KBL937108PGxpxVGsolKE=
> =CPdj
> -----END PGP SIGNATURE-----
>
>
>
> _______________________________________________
> Ale mailing list
> Ale at ale.org
> http://www.ale.org/mailman/listinfo/ale
>