The Evolving DBA

  • Comments posted to this topic are about the item The Evolving DBA

  • Strongly agree - while there are talented individuals in most organisations that can pick up SQL quite quickly I still think most companies and often departments need a role that concentrates on the maintenance and control of their database and hiring someone with a specific focus on SQL and databases is wiser than ever and that role should have a decent status and have recognition from management.

    Those that realise this will I believe thrive those that don't will struggle. I am doing consultancy at the moment which is effectively acting as a temporary DBA. A specific role will not be created after my departure so I am trying hard to make everything really fool proof and document everything but I worry that I will get a call in a couple of years along the lines of database is not working and we are not sure where the backups are can you help?

    And I think using GIT to store standard database structures is something I am aiming to tackle when I get a chance. I do have version control on most of my things but it is a personal implementation which I am conscious is opaque to others.

     

     

     

     

    • This reply was modified 4 years, 9 months ago by  Dalkeith.
    • This reply was modified 4 years, 9 months ago by  Dalkeith.

    cloudydatablog.net

  • The increase in complexity of the database environments easily keeps pace with any tools created that purport the remove the need for a DBA. Perhaps the tools do address what a DBA did 10 years' ago? As a developer, I have become familiar with a range of DBA work over the years and could probably do the job as it was 10 years ago but not today. It the environment in which database work takes place that has changed most radically and I cannot see the demise of the DBA any time soon.

  • I find that a lot of specialisms get taken for granted.  It's really easy to set something up and get it running.  The true test is when something breaks or you find yourself in a disaster recovery scenario.  It doesn't matter if it is database, network, infrastructure.  Each discipline has its specialist knowledge.

    I see the breadth of what data has to offer as an opportunity but I feel strongly that failure to perceive that there is more to "legacy" disciplines than meets the eye as a major threat and weakness.

    While on the subject of "legacy", it is a term that gets thrown around a lot and in a pejorative context.  Things seem to become "legacy" very quickly, almost too quickly.  To me legacy code is stuff that people are too scared to change because it is too complex and too poorly understood.  If code has got to that state in under 2 years then someone is doing something seriously wrong.  Declaring recent stuff legacy is saying that continuous improvement isn't going to work for you.

  • I've been saying this for years. Take CosmosDB. No DBA needed. However, there is an HA/DR aspect to it. There is the need for performance tuning. There is a need for data recovery. There is a need for system maintenance. Does all that sound like DBA work? That's because it is. So, there may come a point in time when no one has the title DBA, but the work is still going to be there.

    "The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
    - Theodore Roosevelt

    Author of:
    SQL Server Execution Plans
    SQL Server Query Performance Tuning

  • Online trading didn't kill financial advisers, prefab construction didn't kill architects, TV dinners didn't kill professional chefs, blogging didn't kill journalism, NoSQL didn't kill SQL, and DaaS won't kill DBAs.

    "Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho

  • Eric M Russell wrote:

    Online trading didn't kill financial advisers, prefab construction didn't kill architects, TV dinners didn't kill professional chefs, blogging didn't kill journalism, NoSQL didn't kill SQL, and DaaS won't kill DBAs.

    You sure about that journalism thing?

    "The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
    - Theodore Roosevelt

    Author of:
    SQL Server Execution Plans
    SQL Server Query Performance Tuning

  • I don't think there are fewer (nor are there more) journalists today than there were 20 years ago. Bloggers are not real journalists, but they do make their living by linking to and adding commentary to actual news stories written by professional journalists. Regardless of how saturated the market becomes with cookie cutters, there will always be a demand for real: journalists, chefs, musicians, etc. What DaaS means to me is that the more repetitive and time consuming (ie: the boring or 2am stuff) tasks get offloaded elsewhere, and the DBA can focus more on architecture and development.

    "Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho

  • Sorry. That was meant as a joke. Apologies.

    "The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
    - Theodore Roosevelt

    Author of:
    SQL Server Execution Plans
    SQL Server Query Performance Tuning

  • Eric M Russell wrote:

    Online trading didn't kill financial advisers, prefab construction didn't kill architects, TV dinners didn't kill professional chefs, blogging didn't kill journalism, NoSQL didn't kill SQL, and DaaS won't kill DBAs.

    Totally agreed.  Doom'n'gloom has been predicted for both RDBMSs and DBAs for as long as I can remember.  Yes, there have been some changes but even the position of true System DBAs has done nothing but get stronger.   There role has changed a bit over time but there continues to be an increasing need for System, Application, and Hybrid (system and application) DBAs and even Database Developers.  Even the birth of "the cloud", machine learning, and supposed AI has formed new needs and opportunities for the position.

    Heh... it's like when they said that electronic scientific calculators would kill the need for Mathematicians and PCs would kill the need for Accountants.  NOT!! 😀

    Ironically, I think that it IS actually good that people think that technology and bright shiny new stuff (that frequently comes and goes as quickly as it came) will kill RDBMSs and the position of DBA.  It helps us stay razor sharp in everything we do.

    --Jeff Moden


    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

    Change is inevitable... Change for the better is not.


    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)

  • Eric M Russell wrote:

    What DaaS means to me is that the more repetitive and time consuming (ie: the boring or 2am stuff) tasks get offloaded elsewhere, and the DBA can focus more on architecture and development.

    Exactly!

    --Jeff Moden


    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

    Change is inevitable... Change for the better is not.


    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)

  • I don't know if there are more or less journalists, but there are certainly less traditional journalist jobs that existed for a few generations. That job evolved, and some people evolved with it, some didn't. Certainly within an organization there is a lot of evolution for a newspaper staff or magazine staff.

    I think that's the key here. It isn't that DBAs go away, or at least as Grant mentioned, the DBA tasks don't go away. They move. Some to a machine, some to whatever title the person gets that handles these things.

    However, for you, and perhaps for your org, the job certainly evolves. If you are unwilling to do so, you might find yourself unemployed. Even if you evolve, you might need to leave your org and go elsewhere. While that doesn't matter much for all of us as a niche industry, it matters very much to individuals.

     

  • I'm not a DBA. I have been officially a DBA and before that I started as a developer who had to be the DBA because no-one else would. Recently I've been a BI Developer (lots of SSIS) and have done a part of the DBA role for our on premises SQL servers, which pleases the official DBAs as they can get on with other tasks and servers and just do the patching and backups on ours without having to worry about index tuning and suchlike. Now the role is changing again as we move to AWS data lake and I'm officially a Data Engineer. But some of what I do will still be parts of the traditional DBA role, even though the databases are virtual, since the data still has to be validated, stored, accessed and Athena queries tuned.

    Same but different. New names for old skills. Just be willing to learn new things.

  • I love this post. It reminds me of a post I wrote in 2017 on this subject called Does Automation Kill the DBA "Store". This post is motivating me to do a recap.

  • This week a friend and colleague was fuming over a lengthy meeting where they were trying to tell someone that the answer provided by CoPilot was wrong.  I've had situations where I have asked an LLM a specific question and it very confidently gave me an answer.  The answer was manifestly wrong.  No matter how I asked the question the answers provided were not working examples.

    Early on in my career a senior IT manager said of a meeting of managers, "Because they got where they are with BS they assume that I did too and therefore they don't place much stock in what I am saying".  LLMs and automation won't take away the need for DBAs.  It is a different problem to get decision makers believe in that need when they want to swing an axe.

    At some point in your career you will make a decision as to where on the spectrum of generalist to specialist you wish to be.  A niche skill can be extremely lucrative but the risk is that niche can cease almost overnight.

    Although I am not a DBA anymore I find that the skills I picked up as a DBA remain useful in other disciplines.  I know of DBAs who have been successful as reliability engineers.  The mindsets of the two disciplines are compatible.

    I've also known DBAs who specialised in data modelling who have become excellent infrastructure as code engineers.  Applying a data driven approach to generating infrastructure leads far simpler and more compact code, albeit at the expense of more complicated data structures.

    I'm coming to the end of my career and every day brings a new feeling of Deja Vu.

Viewing 15 posts - 1 through 15 (of 19 total)

You must be logged in to reply to this topic. Login to reply