Yeah, this is actually a great example of why it's important that if you're developing an application, you need to do some of its database work, and if you're d

Yeah, this is actually a great example of why it's important that if you're developing an application, you need to do some of its database work, and if you're developing a database, you need to get into the application and write code that accesses the database. If you're a hobby programmer and do full-stack stuff on your own to make your dreams real, you organically stabilize on a pretty-reasonable balance between database-side accommodation and application-side accommodation. Since you have to feel the full impact of the tradeoffs made, you select the most efficient, reasonable tradeoff available in the large-scale sense. When you introduce a hard separation between data-side and app-side responsibilities, it's just human nature to get that complexity off of your plate and onto theirs. This competition to put the burden on the other group burns bright and causes massive resentment between DBA and dev. Unify the roles and watch this disappear. Psycho DBAs who insist on fifth normal form everywhere will gain an appreciation for data locality and consider trivial bloat in table size an acceptable tradeoff, because it will make their application-side code tasks much more tolerable. Self-important developers who treat the DBA like their personal data lackeys will gain an appreciation for good data organization and reporting facilities, because it will make their database-side management and reporting tasks much easier. Database and application are too tightly coupled to ever successfully divorce the areas of responsibility. You just end up with people at each others' throats all the time. Merging the responsibilities (and thus the incentives) is the only way you'll get these two groups to adopt a unified perspective.