mysql viability (was: shells and bells)

[gimli at offcenter.org (Mark Donnelly)]

Quoting various people:

> Linux doesn't have a restrictive license.  MySQL
> does.

Umm, not completely accurate.  The latest and greatest 
is under their own license, but they do release 
previous versions (something like two versions back) 
under the GPL whenever they release their new versions. 
 So, older versions of MySQL are under the exact same 
restrictive license that Linux is.

Ah, the net just started working again.  The current 
GPL version of MySQL is 3.20.32a / 3.22

> Fortunately, in this case, it's unecessary to
> sacrifice features.

Actually, to me, moving to PostGres would sacrrifice 
features that I like.  The speed and size have already 
been mentioned, but I just don't accept your rebuttal 
of them (see below).

> > Throwing hardware at problems is an inelagent
> > solution at best.

Cheers!  Although, as I think the original poster 
agreed, when the time is appropriate, using suboptimal 
hardware is less elegant.

> Ripping every component off your car except the 
> engine, frame, and tires so you can go real fast in a
> straight line is inelegant.

Not so; I think it's very elegant.  Having grown up in 
the midwest, where you have no life if you have no car, 
I have been ecstatic to be in Boston, where they have 
this wonderful system ... known as the "T".  I think 
that the subways (which are little more than wheels, 
frame, engine, and brakes) are wonderful.  Anyone who 
doesn't think that being able to do a limited task very 
well should feel free to start driving me from Malden 
to the south side of Chinatown every morning!  ;)

> Hardware is cheap.  And fast.  If your (PostgreSQL)
> database is so huge that a mid-range server couldn't
> handle it, either (1) you are working on a
> significant enough project that you can afford
> more resources, or (2) you are doing something
> completely bonkers.

OK, this is the part that I just won't accept.  
Hardware today is fast.  You might even consider it 
cheap.  But, just because you happen to have a 
well-enough paying job that you can spare $3000 every 
year and a half (you did say a mid-range server), don't 
fiat that everyone else will, and therefore should run 
your favorite software.  

Yes, if this is a corporate project, then I can 
convince them to spend a piddly $3000 for a server.  I 
can probably get them up to the $15,000 for a pretty 
good server.  But, say I'm doing a personal project 
that I want to have a database for.  In my particular 
situation, that means using my P90 with 32MB of RAM.  
Yes, with PostGres, that's bonkers.  With MySQL, it's 
entirely feasable, even if it won't scale past a few 
dozen users.

It comes down to the right tool for the job.  For some 
jobs, MySQL is the right tool.  For some jobs, PostGres 
is the right tool.  For some jobs, Oracle is the right 
tool.  And, for some jobs, Berkeley DB is the right 
tool.  Just like the subway is the right tool for me to 
get to work in the morning, rather than a car.  Just 
like Linux might be the right tool for you, rather than 
NT.  Just like FreeBSD might be the right tool for you, 
rather than OpenBSD.  

> However, transaction support is not
> the only missing feature. 

Remember that, depending upon your perspective, 
"missing feature" can pretty well directly translate 
when looking at the other product into "added bloat."  
For instance, vi is missing Clippy, the paperclip.  (at 
least until ViGOR came out, that is... ;)

> Referential integrity constraints, for example, are
> lacking.  (As I mentioned in a previous post, this is
> new to PostgreSQL 7.0).  This is not an insignificant
> feature.  Without it, you have to do a lot of
> programming to validate data. 

Oh, really?  Tell me, what data do you have to 
validate?  How often will you let your users type in 
that they have address ID 98129532021?  Or that they 
are dealing with event ID 12389792?  You don't.  You 
let them select their address from the list of 
addresses they have already typed in, or you let them 
type a new one in.  Boom.  You (and anyone else you 
have granted direct SQL access to) are now the only 
people who can screw up referential integrity.

> SQL subselect are
> often the _only_ way to perform certain queries.  

Actually, having used MySQL - and parts of the 
unmentionable database -  and been forced to get around 
it, I disagree.  I would wager that you could probably 
get yourself down to at most 20% of your queries that 
*require* subselects.  Probably less.  Yeah, subselects 
make it easier to program.  Then again, so does Visual 
Basic.  (Which is also a good tool for the right job.  
For instance, it makes a good e-mail virus :)

> PostgreSQL has the potential to chop Larry Ellison
> down a notch. MySQL's not even close.  If that's not
> worthwhile, I don't know what is.

Umm, how about creating the best solution to whatever 
problem you have at hand?  

--Mark Donnelly
-
Subcription/unsubscription/info requests: send e-mail with
"subscribe", "unsubscribe", or "info" on the first line of the
message body to discuss-request at blu.org (Subject line is ignored).