[marktangotango]

I've seen one team of devs in particular do a really nice job with their sql database, but more often than not dev teams trash their schema and databases, if they're using sql at all. They create rdbs that are not normalized, don't have foreign key constraints, too many indexes (index on every column to get this dashboard query to perform! I've seen this a sad number of times).

Yeah sure sys admins and dbas aren't critical, but if an organization values what they can do, they can multiply the productivity and effectiveness of the app and product teams.

Specifically, features are faster to implement because the schema is not jacked, the app is responsive and stable because the data is normalizesd and indexed for the access patterns, data is consistent. Customers are happy.

Similar for the network/server side for sys admins.

[mgkimsal]

No doubt there's a potential for abuse, and there's middle grounds to be had. I've also caught hell from a PM for a project being 'late', even though I had 0 control over actually getting DB changes in, because the DBA was a) on vacation, then B) sick, then C) backed up on other work. But apparently, it was my team's fault that the project relying on a SQL database was not launched "on time" (a deadline I had no hand in making, nor did I agree to either).

The policy of "only DBA can make any changes to anything, and all schema changes have to be discussed, reviewed, vetted and approved by DBA" has benefits, in some situations, but also problems.

I had a DBA question why I needed pagination. "No one has ever asked for it before, and never needed it, and I think you're building your application wrong if you need that". After a few weeks of contentious meetings, we got hand-rolled stored procedures for each specific table/query, but they also took days to get to us.

But, hey, you know... at least the tables were normalized and we had "proper" indexes. We just took weeks to get done what should have taken a few hours to prototype (because, during the time we were building the tool, the team we were building it for ended up buying some third party service because we were taking so long).

We've all got war stories of incompetence on all sides (dba, dev, pm, whatever). This is why I advocate "middle ground". I trust a DBA who's actually done a bit of raw coding in their life. I trust a developer who understands the basics of SQL and DB workings (again, 'basics' are fine). I trust the estimates of a PM who is engaged with the team on a regular basis. I trust the views of a business analyst more if they actually show up to meetings and listen to the parties involved.