26 Oct 2008
A “database”, or more properly RDBMS, is a very useful tool; the programmer gets a lot of advanced data manipulation and interoperability in one handy, well-supported, and speedy package. Certainly, there are problems for which a database is well-suited. This particular not-a-blog isn’t one.
It’s definitely possible to store all content in a database – countless CMSes and blog engines the world over serve up sites pretty similar to this one, and almost all do use a database. However, there are several problems for the content author (i.e. me).
For one, web-based editors suck; some seem to suck a bit less than others, and It’s All Text! manages to make editing in Firefox almost bearable, but just pointing your favourite editor at a file is still a lot smoother.
And there is a large array of terribly useful tools for flat files available, whlie very few SQL-backed systems offer an equivalent to even the humble
(Admittedly, non-technical users are unlikely to be familiar with any of those tools, or even with a decent editor.)
Secondly, I consider full and powerful version control to be essential.
Of course, this is possible to implement in SQL, but that’s rather difficult, and even Wikipedia’s implementation doesn’t compare favourably to modern (file-based) systems like
git or even Subversion.
Back when I ran the website and systems of my student association, all data was kept in a Subversion repository.
After a little explanation, everyone was able to use it as a secure FTP that kept people from overwriting each other’s changes – but even that is very useful, and recording a history of changes enabled us to fix some disastrous changes easily.
Thirdly, data migration may be easier. This can be very useful if you have second thoughts about the software you’re using.
Finally, there is something to be said for keeping things simple. A database is a very powerful piece of software – and even if the facade provided by SQL is admirably simple, the software itself is still very complex. And complete, user-friendly CRUD code with semi-decent version control is also necessarily involved. Reading files from the filesystem is pretty straightforward, once you understand how to avoid race conditions in a POSIX filesystem.
For these reasons, this site stores all content in files (in an extended Markdown format).
If I ever add the ability to add comments to pages, I’ll likely store them in PostgreSQL.
And I would certainly be willing to give up the simplicity of storing data in a filesystem if I got something sufficiently desirable in return.
But I don’t foresee voluntarily switching away from file-based tools like