mysql viability (was: shells and bells)

[niall at kst.com (Niall Kavanagh)]

On Thu, 4 May 2000, Ron Peterson wrote:

> 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.
>

In that case, postgreSQL is clearly a better choice for you.
 
> > 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.
> 

It's also ridiculous. So is treating every operation as if it were a
transaction.

> 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.
>  

Not handling and speed are two different things. You can always go faster.
It's easier with mySQL IF you can accept it's drawbacks. (which obviously
I can in certain circumstance, and you cannot <g>)

> > You are entirely missing my point. Completely. Utterly.
> 
> I get your point, I just disagree with it.
> 

No problems there! ;)

> 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.
>

"They're working on it". The mySQL developer DO downplay the importance of
it, in fact the documentation suggests it is good for "database diagrams"
and little else. Something I also disagree with.
 
> 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.
>

Of course they are! Just not all the time. ;)
 
> 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.
> 

I hope one day you'll say the same of mysql. Like I said, they're working
on a lot of stuff, table-level transaction support included. I'm not sure
where they stand on row locking etc. But if folks are interested I'll ask
and report back to the group.

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

Name the time and place. Today is certainly a Corona day! Anyone who
hasn't been outside yet, turn off your computer and get some sun!

--
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).