They mean very little.
More on that after nothing that this is part of T-SQL Tuesday, and you can read the original invitation by clicking on the T-SQL Tuesday 165 invitation or the following images. I almost always forget that this is coming and today is no different. But I wanted to chime in here.
By “very little”, I don’t mean that if you take a job as a DBA, you will likely be repurposed to wash dishes for the CEO’s birthday party. What I mean is that many of the definitions of a DBA and other database professionals have a lot of overlap in their definitions.
For example, as I looked around for formal definitions, I found a few interesting ones:
A database administrator, or DBA, is responsible for maintaining, securing, and operating databases and also ensures that data is correctly stored and retrieved.
This is the start of a good definition. But that definition is very, very wide. In fact, later in the same page, it lists different types of DBAs, which include system, database architects, analysts, modelers, application, task-oriented…
Craig S Mullins on TechTarget said:
A database administrator (DBA) is the information technician responsible for directing and performing all activities related to maintaining a successful database environment. A DBA makes sure an organization’s databases and related applications operate functionally and efficiently.
I like this description, and reading the entire article, you can see a very optimistic definition of what DBAs do.
When adopting a new DBMS, the DBA is responsible for designing, implementing and maintaining the database system. Often, that includes installing the DBMS and setting up the IT infrastructure to allow applications to access databases.
Of course, if this were true, so many DBA types wouldn’t spend so much energy complaining about how developers make their own databases and, too often, how our database servers are running on hardware more realistically fit for a file server. If more of us had proper database server hardware, the move to the cloud database would have happened less quickly. Still, we surrendered to get the hardware we begged for.
So, what of a title like Database Reliability Engineer? Gitlab had this to say about their use of the term:
Database Reliability Engineers (DBRE) are responsible for keeping database systems that support all user-facing services (most notably GitLab.com) and many other GitLab production systems running smoothly 24/7/365.
Digging into the definition, though, it sounds more like what a DBA really did in my world. Maintained the server, made sure it didn’t crash (and if it did that you could get it back up and running as fast as possible), and provided support for teams to make sure they wrote decent code:
Provide database expertise to engineering teams (for example through reviews of database migrations, queries and performance optimizations).
Of course, telling the engineering teams that their queries are not great is always a fun use of an afternoon.
Before coming to Redgate, my title was Data Architect for the past 15 or so years.
Coursera.org says a data architect is:
IT professionals who leverage their computer science and design skills to review and analyze the data infrastructure of an organization, plan future databases, and implement solutions to store and manage data for organizations and their users.
I mean, I did some of that, especially designing most of the new databases for the organization. But if I am honest, most of my career was spent doing that last thing. “Implement solutions.” This, I am pretty sure, translates to “writing database and ETL code.” In their first bullet point for defining the tasks, it states: “Translating business requirements into databases, data warehouses, and data streams.“
In my experience (which was not on a vast number of teams, admittedly), once you start doing something practical on any regular basis, it is hard to do a lot of the higher-level planning kinds of tasks that don’t move current processes forward. Think of any task you do now that wasn’t part of your original job title, and how you acquired it. Same thing.
So many titles, so very similar
In the T-SQL Tuesday host blog, there is a list of titles, DBA, Database Engineer, Database Reliability Engineer, Data Architect, Database Architect, Data Warehouse Architect, Data Warehouse Engineer, that all could mean kind of the same thing, depending on just how large of an organization you work with and what they think it means. If you work for a company that actually has one of each, the distinctions would likely be noticeable. You will also be in a very huge organization!
But even in SQL Kitty’s entry (AKA Josephine Bush, newly minted Microsoft MVP!) if you read the list presented there is so much overlap in her definitions, just like the one’s I have quoted.
Quick Aside: On my drive to and from SQL Saturday Baton Rouge the other day, I listened to the Primary Phase of the Hitchhiker’s Guide to the Galaxy Radio Series. Why I mention this will become apparent if you have listened to or read the book. If not, I will simply warn you in advance that dingo’s kidneys are not at all a pleasant thing.
While my personal experience on teams was not widespread, I have met and talked to a lot of people about what they do over the years, and most titles that people have are a load of dingo’s kidneys. In general, most titles are largely concerned with the movement of small green pieces of paper, which is odd because the pieces of paper don’t have as much to do with the database operations as things like normalization and testing. Titles are very often picked to position an employee with an associated salary.
One Distinctive Data Title
Really the one data-oriented title that has come out in recent years that really stands out as something different has been Data Scientist. To me, this is a pure coding and math-based profession, doing the kind of analysis that most data professionals only dream about as they are mucking around in the data trying to find out why Zaphod’s Gargleblaster was 2.35 Alturian dollars instead of 2.33 (ah, rounding issues). When the database systems crashes, all of the other folks with data in their title will be involved because they work below the surface of the database and infrastructure.
Techopedia defined a data scientist as:
A data scientist is an individual, organization, or application that performs statistical analysis, data mining, and retrieval processes on a large amount of data to identify trends, figures and other relevant information.
Skipping past that “or application” part that sounds ominously like SkyNet, the focus is on working with the data and using math to find real information from it. When I first heard about the concept of a data scientist, I was really interested. Then I realized you probably needed to really understand statistical analysis… and I don’t.
Conclusion
If you are applying for a job with any of these titles… look at what they want you to actually do. Twice. Then ask. There is a chance that what Company X means by Database Administrator and what someone else at Company X means by the same term. Branch out into other positions, and the Database Reliability Engineer could be simply that, making sure the database systems are reliable.
Just remember, if your full-time job is handling the reliability of any system, one of two things is true. The system is a mess. You won’t end up actually doing that full-time if you are good at it.
The post T-SQL Tuesday #165 – My Experience with Database Job Titles appeared first on Simple Talk.
from Simple Talk https://ift.tt/2XdZPGy
via
No comments:
Post a Comment