Hi Cees --
> Agreed. You don't often need those things for a simple web app. In
> fact DBM files are sufficient for lots of web apps (and probably
> faster too). And there is always sqlite, but it won't scale very
> well.
I disagree with you that DBM files are sufficient. Even the simplest
web database needs:
* A standard query interface (e.g., SQL)
* Concurrency protection / Multi-user capability
Given the simplicity of setting up a MySQL database (and it's easy
availability -- even in shared hosting environments), I am constantly
annoyed when I come across an app which insists on using DBMs.
> Agreed on cursors, but I disagree about transactions. You describe
> long lived transactions here, and those aren't very useful on the web.
> But when updating multiple tables at the same time, transactions are
> incredibly handy. Rollbacks are very important for data integrity,
> something that has never been a strength of MySQL. Of course with
> InnoDB tables you can do transactions in MySQL, so that is not really
> a differentiator between the two.
I hear what you're saying, and there is some truth to it. Assuming
you're using MyISAM (non-transactional) tables, it would require table
locking to accomplish something similar to transactions, and in that
case you still wouldn't get rollbacks.
However(!), a lot of this is solved by application architecture. Take
the need for a rollback. I am of the school of thought that the
application should "measure twice, cut once" -- IOW, don't go and try to
do something you shouldn't do. That is the typical case where you'd
need a rollback. For example, if you tried to add a customer who
already existed. If you look at my code in that situation you would see
me first check, THEN insert. As opposed to the rollback model where (I
suppose) you'd insert, wait for an error, and then rollback. (Examples
over-simplified and contrived for obvious reasons.)
> There are <tonnes> of other annoyances with MySQL but I'll only list a
I disagree. I believe there are only "tons". ;-)
> couple that 'really' annoy me:
> - the first timestamp field in any table is always updated on
> every UPDATE
> - 0000-00-00 is a valid date in MySQL
> - 2005-02-30 is a valid date in MySQL
> - insert NULL into a NOT NULL column and MySQL will give it a
> default value
> - overflowing data is truncated instead of returning an error
Some of these I agree with you, others I don't. Perhaps it is because I
wasn't born into the ANSI SQL world, but I do believe it is the job of
the application layer to check data before it blindly goes and inserts
it into the database.
MySQL is very "Perl-ish" in these ways. It is thoroughly DWIM. MySQL
also adheres to the Perl idea of "let the simple things be simple, and
the difficult things be possible." (With PgSQL, it's "in for a dime, in
for a dollar" -- even simple things are relatively complicated.)
Being a Perl fan, you can see why I'm also a MySQL fan.
> > Let's not forget that the "P" in Perl stands for
> "Practical". PgSQL was
> > created as an academic exercise: "Can we write our own
> Oracle?" If I
> > wanted to be "academically correct", I'd be programming in Java. I
> > don't, and I'm not.
>
> Now you are getting silly Jesse. Ad Hominem attacks?
Not at all! I'm not impugning academia. I'm commenting on the fact
that my personal programming preference is practical -- not ivory-tower
perfect ("academically correct", as in "politically correct"). Java is
a language which tries to be "correct" (similar in that way to PgSQL),
and I think it's safe to say that most people on this list who have used
both Java and Perl can rattle off reasons why they prefer the latter.
> after years of stating that 'all those academic features are
> unecesary', they have gone and implemented them anyway in 5.0.
Over the years I have described these two projects as follows:
* MySQL: Bottom-Up.
Always be fast and reliable, and move towards full features.
* PgSQL: Top-Down.
Always be full featured, and move towards speed and reliability.
It has always been the plan for MySQL to build out all the features. It
was only a matter of priority. The only question is who gets there
first, best.
> But, of course you can run huge database on MySQL.
> It takes a bit of work, but it can be done. However, that doesn't
> mean you can't also do the same thing with PostgreSQL.
But who has? What is the equivalent of Sabre (or Google, or Yahoo) for
PgSQL?
At any rate, both databases are pretty close on many counts. What you
get down to is a matter of personal preference. I think that's pretty
much what everybody is saying at this point.
TTYL,
-Jesse-
--
Jesse Erlbaum
The Erlbaum Group
[EMAIL PROTECTED]
Phone: 212-684-6161
Fax: 212-684-6226
---------------------------------------------------------------------
Web Archive: http://www.mail-archive.com/[email protected]/
http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
