I'd make the point that being a DBA is a mindset as much as a set of technical skills.

Is the need for the mindset getting any less? I'd argue the need is increasing.

A lot of the up and coming database systems claim to be self-managing and require 1/2 a DBA per week to look after them. That is unmitigated rubbish. I'm looking at the amount of time that one or two of these have required to get them up and running and to keep them up and running and frankly they have been resource black holes.

Yes they will evolve to a more stable position but I still don't see them being self managing.

Sqlserver 7.0. Was it then that the feature was introduced to configure automatic index generation?

Nice feature in the RIGHT hands, but Microsoft either forgot to mention it or emphasise it

So some heavily hit tables ended up with a large number of indexes, which was great for read performance but when you wanted to add records as well, everything slowed, because of locking.

Hey, you saved a DBA salary and got a slow database! Fair exchange?

When everyone else says something is not their responsibility, it becomes the DBA's. When there is no DBA, people feel the difference when something goes wrong but hey think of the money you saved not the money the disaster has cost the company. Got to get your priorities right

Even if the majority of production DBS tasks can be automated etc. there will always be the rest (including problem diagnosis which cannot be fully automated). I bet the number of instances managed per DBA has increased in a similar, but I bet not parallel, curve to the increase in the number of overall instances. Additionally, there is more to a RDBMS then there was before so the skill set is ever expanding.

Also, due to the combination of improved usability, increased workloads and reduced training I bet that some DBAs now have a quality gatekeeper role added to their duties as they share the load with less able colleagues. (My guess is that the like ofJefff andGaill can provide some great examples here. I, for one, am looking forward to Jeff Morden's forthcoming book "Interviewees: How do they manage to get out of bed?" )

As long as there are developers (without DBA mind-set) creating databases out there, and I see it almost every day, there will be the need for DBAs.

I fill both roles but managers within the companies that I've worked for prefer to hand the whole job to a "lead" SQL developer. This normally ends up with a single database file with no backup strategy, missing referential integrity, throw everything in the dbo schema and very little consideration for security.

A recent case saw me presenting an architecture that included multiple schemas to a manager who immediately replied that it would be too complicated to manage security. When I mentioned database roles he stated that it would be too complicated for the developers to get their heads around.

Some time later I was called in to clean up the integrity and security of the design they made up themselves and it cost more than if they'd used a more "proper" architecture. I ended up having to redesign their database to my original design and creating views as an "interface".

The more these "DBA-less" scenarios are touted, the more managers will think they don't need DBAs when, actually, we're the first person they need.

sqlservercentral 26319 (1/29/2014)...When I mentioned database roles he stated that it would be too complicated for the developers to get their heads around....

Sounds like they have ended up with a good DBA and inadequate developers. Or at least a poor impression of the developers. I don't mean to be funny but schemas are easy to understand in principle as is the concept of database roles. Any developer worth their salt would quickly pick up how they can be combined for authentication purposes (if they didn't already know).

I have a background in both SQL adn Oracle and I must say the Oracle DBA's have felt this pain much more over the years. Their setup was far more labor intensive leaving less time for the DBA to focus on providing service to customers.

"So perhaps the role of the DBA isn’t necessarily dead, it’s just moved to its new home at the datastore-as-a-service provider. "

We have been working under that model for years, long before visualization. Developers are free to build objects in development and new projects can start up in minutes on existing systems. Do they make mistakes? Absolutely, and then they call an experienced DBA for assistance.

Possibly the most important skill for a DBA is the command of T-SQL and their ability to test, debug, and optimize performances of db designs and SQL code. My experience taught me that developers typically do not possess the best skills and understanding of this. While it is true that getting a db system out of the box and up and running can be accomplished without a DBA. From there on, it depends on how good you want your system to be. Goes back to the earlier discussions of how good is good enough.