mysql viability (was: shells and bells)

[rpeterson at yellowbank.com (Ron Peterson)]

Niall Kavanagh wrote:
> 
> On Thu, 4 May 2000, Ron Peterson wrote:
> 
> > Linux doesn't have a restrictive license.  MySQL does.
> >
> 
> I'm not arguing that point. Nowhere in my previous post do you see any
> mention of license. I'm arguing features and technology.

Well, I'm probably beating a dead horse then, but this is not an
insignificant issue.  I'd settle for a fraction of the functionality
from an unrestricted program, as long as it did what I needed it to do. 
Fortunately, in this case, it's unecessary to sacrifice features.

> Faster is better. If my operation takes 1 second to display a web page,
> and I can make it take .1 seconds without buying new hardware I'll do it.
> Throwing hardware at problems is an inelagent solution at best.

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

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.
 
> You are entirely missing my point. Completely. Utterly.

I get your point, I just disagree with it.

> If it slows it
> down to the point where you have the same performance, obviously you
> should take the easier route. Not all operations require transactions.
> mySQL is optimized for this. If this meets your needs and you're
> interested in high performance, use it. If not, use something else. I am
> not advocating mysql's use for everything, merely pointing out that it is
> a viable option under some circumstances, and that lack of built-in
> transaction support does not make it a "card file".

I didn't call MySQL a "card file".  However, transaction support is not
the only missing feature.  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.  SQL subselect are
often the _only_ way to perform certain queries.  Having more than one
process access a database matters a lot, particularly for web based
applications.  If all you care about is read performance, you're not
really creating much of an _application_, so much as, umm, a card file.

> The point is postgreSQL's features are sometimes neccessary, sometimes
> not.
> 
> If you absolutely require the features on every operation, use postgreSQL.
> 
> if you require the features on most operations, use postgreSQL.
> 
> If you require the features on a few operations, use mySQL and add a
> LITTLE extra code. It's not rocket science.
> 
> If you do not require the features on any operations, use mySQL.

I agree with all of this.  I just think that unless you're doing
something very simple, or building a drag racer, PostgreSQL's features
_are_ important.

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.

BTW, I'd also be interested in beer...  ;-)

> --
> Niall Kavanagh, niall at kst.com
> News, articles, and resources for web professionals and developers:
> http://www.kst.com
-
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).