>also people are terrible at modeling data in a relational way. While true, I don't think this is quite fair. Not all of our clients/employers are huge entities

>also people are terrible at modeling data in a relational way. While true, I don't think this is quite fair. Not all of our clients/employers are huge entities with business processes and data requirements that are stable for decades. Many, if not most of the projects that come across the desk of an IT developer are temporary projects with indefinite scope. One of my current projects is modelling a rather complex set of intertwined business processes. Part of the problem is just getting the client to explain their existing processes completely. Another part of the problem is that the processes are always changing. As soon as I think I finally have all the data models figured out, there's one more tweak. I am not great at data modelling or SQL, but tweaking a dozen 50 line joins on a daily basis is not happy fun time for anyone. At some point the specced data model, the model as implemented, and the conceptual model that's in my head get out of sync in some mysterious way, the plot is lost and it all turns to shit. On top of this I'm also trying to manage an object model that sorta maybe corresponds to the data model. In cases where the spec changes frequently, the higher cognitive load of maintaining a decent relational model is simply not worth it.