Many DBAs just don't "get" database architecture: you will find DBAs (and DBA consultants) asserting that having any NULLable columns is always a bad thing, you should make them not null and define a default for the cases that would otherwise be null; asserting that you should declare FOREIGN KEY constraints just to provide documentation, but keep them unchecked - don't actually let the RDBMS enforce then because it wrecks performance; asserting that CHECK constraints are a bad thing because they amount to having business logic in the database; asserting that FOREIGN KEY constraints are a bad thing because they amount to business logic in the database; asserting that update and delete cascadeing on FK constraints are pure anti-relational heresy; asserting that non-atomic columns are OK because you can easily split them on the fly as and when you need to; asserting that INSTEAD OF triggers should never be used because they are unreliable; asserting that it is essential to begin table names with tbl, column names with col, view names with vw, and so on; and promoting all sorts of other utter nonsense. I've even known DBAs who claimed that it was no part of their job to tune queries or determine what indexes should exist to improve perfornace or get rid of indexes which were wasting space and crippling performance, because those were all developer tasks.

In fact until I came across SQLServerCentral and discovered that its contributors included a number of clearly competent people who called themselves DBAs I had an extremely jaundiced view of people who used that title, because every single one I had ever had contact with had been an arrogant (and therefor uneducatable) and utterly incompetent idiot. And many others had similar experiences - and many developers learnt to ignore their DBA consultants because over the years they had discovered that not ignoring resulted in their ending up with systems that never actually worked.