So on Elliotte Rusty Harold's recent post
PUT is not UPDATE,
I made a
comment about 'avoiding databases at all costs'.
And I'm sticking to it. Kind of.
A later comment, obviously directed at mine, claims: 'avoiding databases is like avoiding surgery for voodoo'.
And such. Well, that's true. I could hardly have made it through 20+ years at IBM by completely
avoiding databases. I actually cut my teeth as a youngun doing PL/1 programming for CICS using DL/1
databases (SQL was just becoming popular then). And wrote some specialized database code for natural
language grammar parsing. And of course, it's been impossible to do demo-ware for products I've worked
on in the various 'development tools' organizations I've worked with, without having a DB/2 database
in the story, especially since "there's no
such thing as an application that doesn't have a database behind it."
That doesn't mean I have to like it.
Here are my problems with databases/RDBs/SQL:
- Is every data persistance problem best solved with a relational database? I don't think so.
But you don't see too many people using hierarchical databases anymore. GetNextInParent anyone?
Or VSAM. B+ trees. Sure, Berkeley DB carved out a niche, but then of course, Oracle bought them.
Relational. Brainwashing, plain and simple.
- I don't actively follow the SQL standards, besides knowing there are many of them. And yet,
the actual 'standardization' is not terribly great. When I talk to folks who have products
that support some set of databases, and ask them about supporting others, it's
a "Simple Matter Of Programming" to add that support.
Meaning, porting work. It's perfectly fine to differentiate
on quality of service, but why can't that BE the differentiator? Why do I have to port
to other databases?
- SQL. The Language. OMG. It's COBOL. English. But I'm a programmer; please give
me a functional interface! I'm hopeful that the
LINQ project
will help bring some sanity to the space. And I hear that the Jazz plumbing is
using a functional-ish database access layer. Thank You!
- Sometimes files are good enough. And they work great on the web,
behind a web server, because you get all the creamy RESTy cacheability
(ETags, Last-Modified, etc) from the web server. And now it's even easier to lie. Squirrel your
persistance story behind a
FUSE file system,
so you can provide a simple file-based front-end.
So I would be remiss to note that I've decided to NOT use a file-based persistance
story for my
gRESTbook
project, like I had been thinking,
and am using ... gulp ... sqlite3. In the end, even with the general
ugliness I find in databases, they do provide enough value for me to put
up with them. Or, you could say that this is the simplest possible
thing I could get working at the moment. There's room for exploration
of other alternatives later.
I just updated
the project
with the data model and tests for it.
