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.
No comments:
Post a Comment