As another poster mentioned, data lives on while applications come and go. This is a truism that has shown itself time and time again, in organization after org

As another poster mentioned, data lives on while applications come and go. This is a truism that has shown itself time and time again, in organization after organization. The data should be architected for its own consistency, usability (and re-usability), and robustness. Of course for very complex needs the data will intrinsically become incredibly complex, which is why you should be using decent design tools to organize and document at a higher level. Applications are layered on top (often many applications), and often there will be an impedance mismatch. However what I hear a lot from the NoSQL camp is essentially that by hiding the complexity away into unbounded documents, the problem doesn't exist. That is, pardon the bluntness, unbelievably naive. Try to model one of those ERP systems and seriously -- have fun. There's no big surprise that most of the success stories of NoSQL have been examples of intense simplicity scaled to large heights. Not every problem is so simple. Few problems are so simple. To your orginal comment -- while SQL is not the most elegant language, I like it enough. I love relational database design, however, as there is a purity and elegance in it that is very rewarding. In many ways it's like programming in assembly, and while it might not be for everyone, for some of us it's deeply enjoyable.