June 3, 2014 at 9:58 pm
Comments posted to this topic are about the item DBA is too large a concept
June 4, 2014 at 2:27 am
Good point.
Back in the days of SQL Server 6.5 certification was 2 exams. Administration and Develeopment.
Since then SQL Server itself has expanded to encompass SSAS, SSRS, SSIS, Column stores, File streams, Hadoop etc. I'd argue that it would be extremely challenging for any individual to be an expert in all areas of the product and that it is quite possible to be a DBA and focus on a particular subset of the functionality.
I'd also argue that the uses to which SQL Server is put requires specialist knowledge for those uses. OLTP is very different from data warehousing.
I think it is possible to have two (or more) DBAs who have complementary skills whose principal similarity is the mindset and ethos of a DBA.
June 4, 2014 at 5:12 am
My organization contractually divides DBA support into two initial groups: System DBAs and Application DBAs. The rough delineation is at the user database.
Setup, backups, maintenance, and logins are in the hands of System DBAs while dB user creation and all inner workings of a dB and its code are cared for by the App DBAs. An SDBA doesn't need to be deeply versed in the application; an ADBA needn't worry about the care and feeding of the instance. Each team is able to focus on the services they provide without constantly changing hats.
On both teams there are specialists who are more versed in given areas but there is also overlap/cross-team duties between the two. Having insight into the other group helps all DBAs grow without having to unduly be masters of everything.
This works for us as RDBMS systems are large, multifaceted, wonderful beasts and DBAs gravitate to areas that interest them.
June 4, 2014 at 5:51 am
[RANT] It is not the label (DBA) that is the problem. It is the people using the label. DBA - "DataBase Administrator". Definition "Administrator": some one who manages. It does not define someone who constructs, or builds the inner workings. Those are "Developers". If you are stuck on a term, then champion "DBD". DataBase Developer. [/RANT]
Sorry. You touched a nerve. We need more precise communication, not less precise communication. I am tired of carrying around all these translation tables so that when people say something (which they often don't understand) I can decipher what they mean. [Here I am speaking in general, not about Felipe's comments]
[EDITED to fix word usage]
<><
Livin' down on the cube farm. Left, left, then a right.
June 4, 2014 at 6:12 am
DBA used to be a pretty simple concept - administration only; not developing, reporting, etc.
The title is independent of platform. The title became almost meaningless because of the mix of technologies now encompassed by DBA. I think what happened is that people adopted DBA as their title because there was money and prestige in it. It is more beneficial to call yourself a DBA instead of a report writer.
Tom
June 4, 2014 at 6:33 am
Good point. It is not just the people "looking in" that caused the confusion.
<><
Livin' down on the cube farm. Left, left, then a right.
June 4, 2014 at 7:47 am
Tobar (6/4/2014)
...then champion "DBD". DataBase Developer...
This is a very interesting topic to me. I started out my IS career as a developer and eventually moved into database work. Although my title says DBA, I am a "DBD" and have been for a while. My group was even jokingly called DBDs at my last job. So I'm all for DBD recognition.
Hakim Ali
www.sqlzen.com
June 4, 2014 at 8:19 am
hakim.ali (6/4/2014)
Tobar (6/4/2014)
...then champion "DBD". DataBase Developer...This is a very interesting topic to me. I started out my IS career as a developer and eventually moved into database work. Although my title says DBA, I am a "DBD" and have been for a while. My group was even jokingly called DBDs at my last job. So I'm all for DBD recognition.
I also consider myself principally a data architect/developer, and have always balked at the title 'DBA' -- to me that meant administering, just like the title says. However management in our company never really could grok the concepts, and just went with dba for my team. I'm in complete agreement with the editorial. SQL Server (Oracle, etc etc) have become so complex that the old job titles no longer work.
June 4, 2014 at 8:25 am
I think 'Database Administrator' has to be one of the most inaccurate, misleading and un-sexy job titles you could have. As others pointed out, the tasks we do each day have expanded dramatically over the years however our moniker is mired in 1965. Personally, I think Database Engineer is preferable or perhaps Database Administrator needs apply to those tasks we did 20 or 30 years ago? I would prefer a career path like: DBA (traditional maintenance and optimization), Database Developer (mostly T-SQL work, SSRS report writing, and SSAS development) and Database Engineer (enterprise data modeling, systems integration, large scale ETL). I'm sure I'm missing a number of tasks here, but my contention is that it's a career path and not just a job. I'd also argue that PASS ought to behave like the American Medical Association in this regard and issue a resolution...well maybe. It might help.
What about recruitment? Engineering sounds more appealing than administering, but that's just me. More options can be translated as more opportunity to the new initiates. I want the job title to have a little bit of the shine it deserves so that talented people will be more inclined to look at it. It's an important job.
June 4, 2014 at 8:58 am
I agree with you, Felipe, that the term DBA today tends to cover too wide a spectrum. Too many skills that either one would have at best some acquaintance with, or only focused more about a half dozen topics to specialize in. But at least in your description I have a hard time understanding the difference between a DBA-Development/Designer and what I've always considered myself to be a programmer analyst with SQL development/design expertise. If you're advocating for something else, I'm sorry but I missed it.
Kindest Regards, Rod Connect with me on LinkedIn.
June 4, 2014 at 11:58 am
hakim.ali (6/4/2014)
Tobar (6/4/2014)
...then champion "DBD". DataBase Developer...This is a very interesting topic to me. I started out my IS career as a developer and eventually moved into database work. Although my title says DBA, I am a "DBD" and have been for a while. My group was even jokingly called DBDs at my last job. So I'm all for DBD recognition.
So, if you are a DBD, does that mean you are also versed in OO languages?
I see many headhunters looking for a DBA with a principle skillset of OO development. To me that isn't a DBA and that isn't a DBD. That would be a .Net or Java or <insert OO here> developer. Somehow, being a DBA now has evolved into platespin, OO language, linux and the whole gambit of IT.
Jason...AKA CirqueDeSQLeil
_______________________________________________
I have given a name to my pain...MCM SQL Server, MVP
SQL RNNR
Posting Performance Based Questions - Gail Shaw[/url]
Learn Extended Events
June 4, 2014 at 3:28 pm
I don’t think you will get any arguments from anyone on this point. I have worked in database longer than most (30+ years) starting out on the mainframe. Back when I started, you were pretty much just a disk/storage administrator, performance tuner, code reviewer, and person to restore a database that failed. Sometimes a DBA got involved with design, but Third Normal Form database design was not yet prevalent. The career path to a DBA job was primarily from programming. If you found a hot-shot programmer that wanted more challenge, then you brought him/her in.
Since that time, Unix (open source) came into the database world with Oracle, Informix, and DB2. Most larger shops required the DBA to support these as well. If you were lucky, you could bail out on the earlier mainframe hierarchical database, but you were still required to support DB2 as it was relational. In the last 15 years, SQL Server has grown exponentially. As a result, I found myself supporting databases on the mainframe, Unix, and SQL Server.
Along with knowing three very different operating systems and differences in physical database design requirements to accommodate the differences across three different database platforms, there was an enormous growth in Business Intelligence databases. Now the Third Normal Form design had to include Star Schema design. Then there came the data warehouse appliances – proprietary boxes like Greenplum (now part of EMC) and Netezza (now part of IBM). They had their own nuances.
Availability requirements have increased. No longer do we use the word “24x7” as it means different things to different people. If your business demands “continuous availability” then that is what you give to them along with the duplication that is needed to make it work.
Corporate security/audit requirements have put new constraints on DBAs. In many shops today, no longer can a DBA troubleshoot a problem by taking a copy of the production database and putting it on a non-production platform. New procedures had to be worked out (and are continuing to be worked out) to ensure that corporate data is protected while not totally hamstringing the DBAs and developers.
So yes, things have changed, regardless of the DBMS you started with. No one can be good at all this. All they can do is react in the best way they know how – and it usually is suboptimal. I know because in my previous company that is the way it worked. Going forward, the Cloud won’t change anything for the better either. All it will be is another new platform to support.
Am I cynical? No so much anymore since I left the craziness of my previous employer. The best advice I can offer is to not get too comfortable where you are employed. You might want to make a change.
Viewing 12 posts - 1 through 11 (of 11 total)
You must be logged in to reply to this topic. Login to reply