The missing discussion point for me is more fundamental - how and when should I break with my RDBMS data modeling habits? I can't say for sure, but suspect som

The missing discussion point for me is more fundamental - how and when should I break with my RDBMS data modeling habits? I can't say for sure, but suspect some of the headlong rush into denormalized NoSQL stores is motivated by the ease of the data model. I wonder if once you go down that road, if your "program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of" what you get in a decent RDBMS. (Forgive my hijacking of Greenspun) That said, I'm usually working in denormalized models anyway (star schemas in data warehouses for handy-dandy slice/dice/drill), so I'm completely open to different ways of approaching data processing and analysis problems. I actually feel more free with SQL than limited though. What I would really enjoy would be to have the fully expressive power of SQL embedded in a natural feeling way in a higher level language. I'm interested in Q (of KDB) for this reason, have also been baking my brain in prolog to tear down old data model habits, and hacking some in Ruby and Common Lisp for the same reasons. Of course, I'm probably breaking my career in the process, since I've made a habit of getting paid to work on RDBMS walking the line between hardware/software performance tuning. But because of that, I'm also glad to see new approaches to RDBMS storage and innovation in the whole DB space.