I've always considered myself a developer and a LOWER(DBA). I may have recovered perhaps one database and that was just a sandbox, nothing production worthy. I've built out instances for development and testing and I've installed the software a few hundred times, at least. I've done DBA-like duties, but I just don't think of myself that way. I'm a power developer maybe? Whatevs.
I'm sure it would be nearly impossible to come up with One True Definition of The DBA ™. So I won't.
I've read that Tom Kyte does not consider himself a DBA, but I'm not sure most people know that. From Mr. Kyte himself:
At the same conference, I asked Cary Millsap the same question:
I read Cary for years and always assumed he was a DBA. I mean, have you read his papers? Have you read Optimizing Oracle Performance? Performance? That's what DBAs do (or so I used to think)!
It was only after working with him at #kscope11 on the Building Better Software track that I learned otherwise.
Perhaps I'll make this a standard interview question in the future...
Semi-related discussions:
1. Application Developers vs. Database Developers
2. Application Developers vs. Database Developers: Part II
7 comments:
The pair of them are so far in the DBA closet they are practically in Narnia. I'm guessing in a few years they will both out themselves as DBAs. It will cause a big media storm for five minutes then nobody will care. :)
Seriously though, there are lots of performance consultants that are not really DBAs and not really developers, but sit somewhere in between.
I've always considered myself a DBA/Developer, although Tom is convinced I'm just a lowly DBA. :)
Cheers
Tim...
@tim
When I make it over to your side of the pond I will ask you the same question, or perhaps it'll be at OOW this year.
It doesn't surprise me (anymore). I think when I first started out I really made a distinction between the two roles, now, not so much.
First, I find this my favorite topic of yours. How you present it in the light it deserves. I have always told you that I always believed you can't be a great DBA without being at least a good developer *and* vice versa.
Second, I already own creating Triple Fake Trademarks™ on the Internets. Where's my due? ;)
@Michael
here here.
As to stealing Triple Fake Trademarks ™, I created BFE back in high school, I haven't seen a dime.
How about some discussion on the Apps DBA and the Database(?) DBA. How do you differentiate?
@Danny
I told you I wasn't going there. :)
Generally speaking, I think there are two classifications of DBAs, the operational person who keeps the lights on and then the other person, who deals more with architecture, future planning, etc, etc. Of course like the DBA/Developer thingy, you have the Operational/Architectural types as well.
I think the Apps DBA is a subset of DBA, but someone may disagree. Actually, maybe they are more the blended Operational/Architectural types given the support of a incredibly complex eco-system? I don't know.
To get a more practical picture I suggest we first enhance our view and then transfer the whole picture into something more tangible?
For the first step, I add the application into the wording (beside the database). My reason to add the application is based on the basic function (let's call them (business) requirements). A naked database rarely delivers these.
Now there are 3 (active) phases in the lifetime of an application:
* Design
* Development
* Operation
They may somehow overlap and interfere, but that's not my point.
The last phase - decommission - is more passive and not so important for me at the moment.
Now - for the practical picture - I switch to a house.
Every house should fulfill some requirements.
In the Design phase an architect describes how these requirements should be met in the specific incarnation. The architect knows a lot about standards, probably statics, general do's and dont's and hopefully also remembers things needed even not specified explicitly. (e.g. never forget toilets or stairways).
During the building of the house, totally different people turn the architects description into a real building. Many details they implement on their own based on their education and experience, but sometimes it make sense to ask the architect if it's a feature or vagueness. (in general, floors should be level, but sometimes a small gradient is needed).
After the building is finished, someone has to run it. there is the defined role of a janitor.
There are many repeating tasks, like cleaning the floor or opening/closing the building every morning/night.
There are other small fixes like changing a bulb or a clogged pipe. Every janitor has his own skills. But they are limited. Rarely they will add a stairway to a building.
After so many words let's come back to software:
Where do you see a developer? Or an administrator?
And in which phases does DBAs support the target meet the requirements?
For me, I'm a janitor most of the time.
Sometimes I can assist an architect with some skills he is not supposed to have.
Rarely I get into contact with developers: If the floor is plane or not, I can't change. But I'll clean it :-)
Post a Comment