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:

> 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.
> Why would you use a product with limited functionality, with a limiting
> license, when a better (I like to speak in absolutes) product is
> available without these limitations?

"Better" is based on YOUR needs. Not everyone elses. If I have no need for
transaction support and the license doesn't bother me, mysql is "better".
If I have need for transaction support on every operation mysql is "not
better". If I fall somewhere between the two, then I take stock: Is is
worth my time to code around the lack of transaction support? Do I value
the speed of my non-transactional operations over the ease of my
transactional operations? These are questions you should ask yourself.

> Because it's faster?  So what?  If your database is so huge and popular
> that speed is an issue (it would have to be pretty damn big), I'm sure
> you can afford to scale up your hardware.  Hardware is cheap.

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.

> MySQL doesn't have limitations because you can program around them?  You
> can program around anything.  You could write your own operating system,
> your own compiler, your own database engine, and your own web server. 
> Why would you want to do this, unless you think you can do a better job
> than someone who already has and is willing to share their work?  Tell
> us about MySQL's performance, when you code all the cruft on top that
> you'd need to support the features PostgreSQL has.

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

> Either you say that PostgreSQL's features are unnecessary, which I
> (absolutely) disagree with.  Or you say you can program around MySQL's
> deficiencies.  In which case what's the point?

The point is postgreSQL's features are sometimes neccessary, sometimes

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.

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 /