mysql viability (was: shells and bells)

[niall at kst.com (Niall Kavanagh)]

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

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