Yes, it was just a matter of time before I was bitten by the NoSQL bug. What's curious is that I've been a long-time SQL proponent (for my young age) and I think I've managed to grok it over the years. However, the more I deal with relational data in tightly constrained schemas, the more ornery this model seems to be. Just the other day I was dealing with some entity relationships in our project. It's fairly basic and important stuff, like Users that have Roles that have Rights, etc. Thanks to the constraints, adding a few users and roles for the testers turned into an all day chore. Once I had finished with it, I handed it off to another guy who would update the whole entity model along with my data. This caused problems with yet more constraints to other entities. In the end, the whole thing needed to be scrapped as too complex, and the test data never got updated.
I've always just accepted the inherent incompatibility between relational databases and object-oriented languages. Now that I've seen another way of doing it I must admit that I'm rather hooked on a "hash in the sky" so to speak. Why does the data store need to care about every minutia in my data types and properties? It would be one thing if I routinely used a fixed number of strictly typed properties in all my objects, but I don't. I usually have at least some optional properties many of which are intentionally ambiguously typed. Given that, why would I choose a data layer that ties me down so drastically?
No comments:
Post a Comment