December 10, 2011 at 11:13 am
Comments posted to this topic are about the item Does the Role of the DBA Need to Evolve?
Brad M. McGehee
DBA
December 10, 2011 at 1:24 pm
The DBA will continue to be the "plumber" getting the data to the superstars who analyze it. Can you depend on the interpreters of the information to manage the pumps and pipes? I doubt it. They are different tasks.
That said, I watch the data and try to understand its relevance and measure its integrity. I can't meet the consumers of the data halfway otherwise.
It's refreshing when they meet me halfway too, and I reach out to them. But when they don't respond I am not surprised, just disappointed. (Frequently they are disappointed too, eventually.)
December 10, 2011 at 6:35 pm
There's another source of endless information which doesn't seem to be mentioned very often: Twitter has a deal for every Tweet to be archived at the LOC (Library of Congress). That'll easily outweigh the Google 20 Year Usenet Timeline (http://www.google.com/googlegroups/archive_announce_20.html)
December 10, 2011 at 7:10 pm
Yup,
We be plumbers.
But, in medium/small businesses the goal has always been to deliver information, not just data.
I am currently I am working with a large group of superstar analysts. The only issue is that they are superstars at a very narrow body of knowledge.
The end result is that there will always be a need for generalists that can get the job done when it is needed, without highly specialized domain knowledge.
So, IMHO, the editorial is sorta off the mark to begin with. Us SMB DB monkeys have always had to curate data and always have had to deliver usable information.
Brad
Do not forget that overspecialization has usually led to extinction. 😉
December 10, 2011 at 8:09 pm
I worked at a university as a data analyst using statistical software in 1983-- yes, 1983. I struggled to manage data relationships using SPSS. Then I was introduced to Ingres 1.0. Relational database has been my credo and my paycheck since then, with statistical software and Excel in supporting roles. Even though the Ingres database server crashed too frequently and it was my job as DBA to recover from crashes and work to prevent them, I was recognized as knowledgeable about data as well as database server. I taught relational database design and index design for Computer Associates in the mid-1990s.
I work on short term contracts, mostly fixing SQL Server problems created by application developers who may be good application programmers, but not database programmers. Microsoft created a monster by presenting SQL Server as a room in the Visual Studio rather than supporting the role of the DBA as separate from the role of application developer. True, the programming built into SQL Server eliminated the need for a dedicated DBA to manage the database server and databases, but what role understands the data relationships? Typically, application developers do not recognize or respect many-to-many relations-- for instance. A data-oriented DBA is a much better database designer than is the combination of a business analyst working with an business-intelligence-challenged application developer.
Companies that hire me typically expect that I will make a fix to how SQL Server DBMS works on Windows and their hardware -- "tuning." Typically, they don't welcome a demonstration that performance can be improved dramatically by teaching database programming to their application developers. (Really now, do you think it's more likely SQL Server and Windows fit together badly or that your application is not using SQL Server optimally? How many programmer analysts does Microsoft employ, and how many big applications has your lead developer delivered?) Object-oriented programming ("data is dead but must be persisted when not being viewed through this application") and security-mandated separation of development from production have pretty much succeeded in persuading IT managers that data is owned by applications and the database is just a box.
>>Will the DBA role evolve naturally from being a "caretaker of data", to "interpreter of data"?
I would like the DBA role to RETURN to include "interpreter of data."
_________________
"Look, those sheep have been shorn."
data analyst replies, "On the sides that we can see.."
December 11, 2011 at 9:23 am
From the article:
Will the DBA role evolve naturally from being a "caretaker of data", to "interpreter of data", for the good of society?
I believe that anyone who doesn't already think so, has missed the proverbial boat. 🙂
--Jeff Moden
Change is inevitable... Change for the better is not.
December 12, 2011 at 12:26 am
katesl (12/10/2011)
I worked at a university as a data analyst using statistical software in 1983-- yes, 1983. I struggled to manage data relationships using SPSS. Then I was introduced to Ingres 1.0. Relational database has been my credo and my paycheck since then, with statistical software and Excel in supporting roles. Even though the Ingres database server crashed too frequently and it was my job as DBA to recover from crashes and work to prevent them, I was recognized as knowledgeable about data as well as database server. I taught relational database design and index design for Computer Associates in the mid-1990s.I work on short term contracts, mostly fixing SQL Server problems created by application developers who may be good application programmers, but not database programmers. Microsoft created a monster by presenting SQL Server as a room in the Visual Studio rather than supporting the role of the DBA as separate from the role of application developer. True, the programming built into SQL Server eliminated the need for a dedicated DBA to manage the database server and databases, but what role understands the data relationships? Typically, application developers do not recognize or respect many-to-many relations-- for instance. A data-oriented DBA is a much better database designer than is the combination of a business analyst working with an business-intelligence-challenged application developer.
Companies that hire me typically expect that I will make a fix to how SQL Server DBMS works on Windows and their hardware -- "tuning." Typically, they don't welcome a demonstration that performance can be improved dramatically by teaching database programming to their application developers. (Really now, do you think it's more likely SQL Server and Windows fit together badly or that your application is not using SQL Server optimally? How many programmer analysts does Microsoft employ, and how many big applications has your lead developer delivered?) Object-oriented programming ("data is dead but must be persisted when not being viewed through this application") and security-mandated separation of development from production have pretty much succeeded in persuading IT managers that data is owned by applications and the database is just a box.
>>Will the DBA role evolve naturally from being a "caretaker of data", to "interpreter of data"?
I would like the DBA role to RETURN to include "interpreter of data."
Great post, I agree with this.
/@devandreas
December 12, 2011 at 7:23 am
Jeff Moden (12/11/2011)
From the article:
Will the DBA role evolve naturally from being a "caretaker of data", to "interpreter of data", for the good of society?I believe that anyone who doesn't already think so, has missed the proverbial boat. 🙂
Wherefore, good sir? I think each role has so much importance that to combine the two might dilute the results. Making sure that such large volumes of data are available, backed up, up to date and consistent seems as important in the future as it is today (only becoming more so as you deal with more and more data). On the other hand, a true understanding of the data without having to worry about where and when it is stored is required to make business decisions, and time taken to do both of those things takes away from the value of whichever one is your primary goal.
I would think it similar to a fighter jet; you want your pilot to be rested and ready to fly the damn thing, not worry about upkeep, that's the mechanic's job. Both highly specialized, both vital, not a crossover position.
---------------------------------------------------------
How best to post your question[/url]
How to post performance problems[/url]
Tally Table:What it is and how it replaces a loop[/url]
"stewsterl 80804 (10/16/2009)I guess when you stop and try to understand the solution provided you not only learn, but save yourself some headaches when you need to make any slight changes."
December 12, 2011 at 7:54 am
I agree with the split. DBA = admins the database, Management = analyzes data and makes+implements decisions based on it, Analyst = support for management when specialized knowledge/skills are needed to turn data into information.
Conflating the functions is a mistake. We don't have managers (generally) who are expected to maintain the air conditioner for their office, so why expect them to admin a database or server? And we don't expect the HVAC engineer to analyze the company, the markets, the government, et al, and make decisions about the business.
I've been in both positions (DBA and management; I haven't done HVAC work in over a decade), and they require complex and different skillsets and knowledge. Managers are the ones who have to analyze data and turn it into information that can be used for planning (or reacting, depending on the urgency). Sometimes (often) they need help on that from people who are trained in areas like statistics, but that's the role of a researcher, not a DBA (DB Admin, not DB Analyst).
Those are people who deal with determining correlation vs causation, et al. It's mainly stats, scientific methodology, etc. Again, they don't need to know how to design a good database (relational or cubes or whatever), they need to know how to spot relations in complex data. "Customers who buy toothpaste also often buy dental floss" has a probable causal relationship to interest in personal hygiene, vs "Customers who buy diapers also often buy beer", which turned out to be a correlation with no real causal relationship (real-life data mining scenario). That's not something based on classical DBA skills, like normalization, SARGability, b-tree indexing, et al, or DR, backups, log shipping, replication, et al, depending on which version of DBA you mean.
Specialists cost more, but have the opportunity to be better at what they do. I view that as a positive thing.
- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread
"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
December 12, 2011 at 9:21 am
There's a real difference between the DBA and DA roles. And the DA role which Brad McGehee suggests seem to live at the junction of IT and many of the social sciences - the latter not being something with which today's DA (much less DBA) is usually familiar.
In our shop - part of a public agency - most of the analytics and data mining is actually conducted by the GIS staff. We are fortunate to have a tried, true, and trusty DBA who excels at providing the data to GIS - and it seems likely these roles will remain unchanged here into the foreseeable future.
Yours truly,
Hari Seldon
=)
December 12, 2011 at 9:44 am
My editorial got edited after I wrote it, and one important part of the message I was trying to get across apparently got deleted. In the original draft of my editorial, I was making the assumption that over a long period of time, 50, 100, 500 years, that the role of DBA administrator would probably go away as software could very possibly take over such tasks. So my question "Will the DBA role evolve naturally from being a "caretaker of data", to "interpreter of data", for the good of society?" is not asking about now, or the next few years, but about the future. The goal of the editorial was to be "whimsical" and "thought-provoking", but that part of the editorial got edited out.
Brad M. McGehee
DBA
December 12, 2011 at 10:42 am
The function of calculating storage space for the data and making sure it's backed up-- and that restore works!-- is a crucial function-- but one that is very easy to perform with the SQL Server toolset. It isn't a fulltime job, and in my case combines very naturally with database design, query planning and index "design." In the Ingres days, there were fine points of index design to master; now it's simply "which index should be the clustered index?" plus "is the read benefit of this index worth the write cost?"-- leaving more time for investigation/validation of data relationships.
The general point that job functions may be too broad (pilot has to be rested) or too narrow (overspecialized out of existence) calls for analysis of WHICH job functions should be combined. I think the combining of user interface design with database design is a mistake, and of course object-oriented programmers disagree with me. I was an entry-level statistician before I became a database programmer/DBA, and I saw some wild misconceptions from PhD statisticians who did know how to analyze data relationships but weren't familiar with the database design and thus didn't know what was in their data. For instance-- assumption that the table named "employees" held records for all employees when a look at the database diagram might have raised the question "what's in the table employees_former_contract?" And, without a DBA familiar with the business use of the data, there is no sanity check on database size. I've worked with DBA/network administrators quite proud of their facility in managing large and growing data volumes; then I look at the database and see that 90 percent of it is redundant and whitespace.
_________________
"Look, those sheep have been shorn."
data analyst replies, "On the sides that we can see.."
December 12, 2011 at 10:43 am
Sarbanes-Oxley (SOX) does require separation of responsibilities. Application developers are not allowed to "fix" production data. I can't disagree with this.
But I never forget the quote
Stamp's Statistical Probability The government [is] extremely fond of amassing great quantities of statistics. These are raised to the nth degree, the cube roots are extracted, and the results are arranged into elaborate and impressive displays. What must be kept ever in mind, however, is that in every case, the figures are first put down by a village watchman, and he puts down anything he damn well pleases.
(Attributed to Sir Josiah Stamp, 1840-1941, H.M. collector of inland revenue.
As DBA, I do validity checks as far back to the source as I can on data I protect, and I am always interested in analyzing the data I am protecting. I was a data analyst, not a programmer, before I was a DBA. And I am a good DBA, with a good understanding of how much time any database operation (and human operation) should require. I "get" the SQL Server DBMS. Some programmers know all the trees and don't get the forest.
_________________
"Look, those sheep have been shorn."
data analyst replies, "On the sides that we can see.."
December 12, 2011 at 10:47 am
I hesitate to have DBA's interpret data. Particularly data in fields such as medical and finance. I have a difficult enough time understanding how to store, manipulate, backup data, and report against data. One can't be all things to all people.
There is also the need for separation of responsibilities. It is a bad idea to have the data caretakers also be the data interpreters. I think it would be bad, and maybe against the law, to have the same person perform both roles in a financial institution.
December 12, 2011 at 10:50 am
bradmcgehee@hotmail.com (12/12/2011)
My editorial got edited after I wrote it, and one important part of the message I was trying to get across apparently got deleted. In the original draft of my editorial, I was making the assumption that over a long period of time, 50, 100, 500 years, that the role of DBA administrator would probably go away as software could very possibly take over such tasks. So my question "Will the DBA role evolve naturally from being a "caretaker of data", to "interpreter of data", for the good of society?" is not asking about now, or the next few years, but about the future. The goal of the editorial was to be "whimsical" and "thought-provoking", but that part of the editorial got edited out.
I can't figure out what I'm doing next week much less think 500 years hence. :hehe:
500 years from now all of the roles filled today will be different or non-existent.
Viewing 15 posts - 1 through 15 (of 36 total)
You must be logged in to reply to this topic. Login to reply