Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

mysql viability (was: shells and bells)

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

> 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
News, articles, and resources for web professionals and developers:

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

BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!

Boston Linux & Unix /