WordPress 2.0 is better than ever (NewsForge)

# Not really SQL
my $rv = $dbh->do(q{
-- posted_time and article_id have DEFAULT values filled in automatically.
INSERT INTO posts (poster_id, article_text, parent_article_id) values (?, ?, ?)
}, {}, $poster_id, $article_text, $parent_article_id);

with

# Not really Perl
# You need to implement your own sequences, or generate UID's
while (1) {
open(ID, "<article-seq") or die;
last if flock(ID, LOCK_EX|LOCK_NB);
flock(ID, LOCK_EX);
}
my $id = <ID> or die; ++$id;
my $id_fh = IO::AtomicFile->open("article-seq.new", "w");
print $id_fh $id or die;
$id_fh->close() or die;
close(ID) or die;
# Create new article in a text file.
# Don't forget to clean up all the leftover ..TMP files if your
# system or process crashes, or the disk fills up while posting.
my $art_fh = IO::AtomicFile->open("articles/$id.txt", "w");
# And of course you'll have to parse this stuff too
print $art_fh "Article: $id\n" or die;
print $art_fh "Posted: " . time(). "\n" or die;
print $art_fh "Poster: $poster_id\n" or die;
print $art_fh "Parent: $parent_id\n" or die;
print $art_fh "\n$article_text" or die;
$art_fh->close() or die;
# And update all those indexes
link("articles/$id.txt", "posters/$poster_id/$id.txt");
link("articles/$parent_id.txt", "parent_articles/$id.txt");

Now suppose you wanted to send email whenever someone replies to someone else's posting. In SQL, you could add a trigger or rule, a message queue table, and a daemon which sends the email messages, so the example above doesn't change. In the filesystem implementation you'd be adding some more links, state tracking, and cleanup to the above, in addition to the extra code you'd have to add to do the actual work of sending emails.

A better analogy is Windows Versus Linux. Linux is created with an emphasis on engineering - good design, based on experience and review of previous designs - to get it right.

Windows is based on great marketing, capturing mindshare etc. and being just about good enough. It was home grown, and failed to make sure of a legacy of previous software developments - the "good enough to ship" method just stores up problems further down the line when the inadequacies of the design and engineering come to light.

It's solid marketing with a "that'll do" product, versus solid engineering, leveraging the collected wisdom and experience of the community.

All credit to MySQL for grabbing mindshare - but I prefer the engineering approach of the proper relational databases - building on the experience and good practice developed over the past.

Of course, if MySQL is "good enough" and you are only interested in the short term advantage, then use it by all means.