In my experience, people who use DBs at least an SSMS level fall into several categories (and often they overlap) and they are:

• People who design DBs;

• People who are responsible for the running, maintenance and security of DBs;

• People who are responsible for the running, maintenance and security of the server and OS;

• People who implement business logic and create/further/alter the interface between the DB and the application server;

• People who make reports or generate information from the data in the DB;

In the first decade of the new millennium of Systems Architect rose up and has taken over the first of these. The position of reports writer took over the last of these and I have also seen the Sysadmins take charge of the DB security as well.

And finally, in the last five years, with the development of devops, the developers have come to believe that they should do everything.

I, personally, am of the opinion that DBAs should have a say in everything to do with the DB and I believe in consultation [1]. I don't make any changes to the NT-server without first consulting the sysadmins. I don't assign read-login-rights without first consulting the product owner. No-one gets write-login-rights unless I am ordered to assign them. If I can optimise an SP, I will let the developer in question know.

[1] One of the developers thinks that he does too: since he knows that I hate any EF with a compexity of more than one join, he offered me a choice. He has to re-work the history of a widget and normally it involves an INSERT and an UPDATE. It had been done before with SPs. Not now, for they are old-fashioned, he said. Instead, the options he presented me with were:

a. TRIGGER based on an INSERT-statement in EF;

b. VIEW which determines the current state of the widget based on all of the entries in the change table;

c. Everything done in application server and changes written to the tables in question;

I chose d. SP — updated from the current version.

Apologies for the usual rant about developers.