SQL dba vs SQL Developer: Wha tis the 'intersect'?
Can a competant/seasoned developer, generally, be able to cope with the Admin duties of a DBA, on a small curve?
What about a knowledeable DBA who may try to cope up as developer? How realistic is it?
Any experiences? Thanks
What about a knowledeable DBA who may try to cope up as developer? How realistic is it?
Any experiences? Thanks
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
<<now - you need to know everything what developer knows, and much more: people call it database administration (see posts above): sql server, Windows, networking, etc...>>
Yep. Just as a side note and food for thought...
Many years ago I used to work with good database analysts and developpers who were aware of all consequences of undeducated database programming. My job at that time was ideal: no regular on calls, good/performant applications, my job was mainly about maintaining scalability. Now database analyst and true database developpers are almost an extinct profession.
It is only when we start considering that the two database jobs should not respect the same fundamentals that an artificial rift occurs between the two professions, hurting both professions.
IMHO/
Yep. Just as a side note and food for thought...
Many years ago I used to work with good database analysts and developpers who were aware of all consequences of undeducated database programming. My job at that time was ideal: no regular on calls, good/performant applications, my job was mainly about maintaining scalability. Now database analyst and true database developpers are almost an extinct profession.
It is only when we start considering that the two database jobs should not respect the same fundamentals that an artificial rift occurs between the two professions, hurting both professions.
IMHO/
<<What about a knowledeable DBA who may try to cope up as developer? How realistic is it?>>
An educated database practionner should be able to be totally interchangeable in both professions.
An educated database practionner should be able to be totally interchangeable in both professions.
>> An educated database practionner should be able to be totally interchangeable in both professions.
To achieve this, that person should be a developer first knowing all concepts and then can be an administrator.
To achieve this, that person should be a developer first knowing all concepts and then can be an administrator.
<<To achieve this, that person should be a developer first knowing all concepts and then can be an administrator.>>
Well if you ask me I don't believe that it is simply a matter of *who came first* debate.
One could argue, that there is *no way*, one could make proper development if he has not tasted the *joys* of seeing database systems fall appart in production as a dba (and had to fix them). Knowing how the database system behave in production will make you a better developper, I guarantee that.
*Database Concepts* are a vague term which is why I prefer to refer to a proper *fundamental* education in database management. Reading books to understand relational model form people like CJ Date are the only way that a database practitionner can understand what is truly happening, and independently from specific situations, contexts and assigned roles.
Well if you ask me I don't believe that it is simply a matter of *who came first* debate.
One could argue, that there is *no way*, one could make proper development if he has not tasted the *joys* of seeing database systems fall appart in production as a dba (and had to fix them). Knowing how the database system behave in production will make you a better developper, I guarantee that.
*Database Concepts* are a vague term which is why I prefer to refer to a proper *fundamental* education in database management. Reading books to understand relational model form people like CJ Date are the only way that a database practitionner can understand what is truly happening, and independently from specific situations, contexts and assigned roles.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
<<The truth is more like a Programmer gets involved with SQL development without the appreciation and knowledge of database structures, so creates convenient data repositories more so than well designed databases.>>
Very true. I like the term used for that by CJ Date for what you are refering to: *data bags* vs *databases*.
In any case, the distinction between the skillset required for the two roles is a mistake itself.
Could we consider that a developer can actually do a good job while ignoring the current conditions on which his code will actually be running ? No. Developpers who totally ignore economical aspect of their code are doomed to be poor developpers (in any language).
Inversely, can we consider that a DBA can actually well protect better his system if he is no involved at some point in helping development on the SQL part? No. DBA who do not treat potential threats in a proactive way remain poor DBAs.
Best regards...
Very true. I like the term used for that by CJ Date for what you are refering to: *data bags* vs *databases*.
In any case, the distinction between the skillset required for the two roles is a mistake itself.
Could we consider that a developer can actually do a good job while ignoring the current conditions on which his code will actually be running ? No. Developpers who totally ignore economical aspect of their code are doomed to be poor developpers (in any language).
Inversely, can we consider that a DBA can actually well protect better his system if he is no involved at some point in helping development on the SQL part? No. DBA who do not treat potential threats in a proactive way remain poor DBAs.
Best regards...
Love the "data bags" haven't heard that before...
The expertise of the (app) developer is not overly different to the SQL roles, in so much as, the better ones do have an understanding. I would go an extra step and say that "knowledge" of the better developer equally applies to any computing environment such as network (comms), security, hardware (resource) utilisation etc.
However in the bigger development groups, it is likely that they are less exposed, or, don't have that responsibility. I have most definitely seen developers that really do not have any interest in database nuances, other than "tell me where I get it from".
One thing for sure is the more you actually have to perform a specific role, then the better you get at doing that job, so long as you a prepared to learn. So, fro someone to pick up elements of DBA, if they are thrust into that role then they will get better at the role, the more they do and the more they learn. It might not be enough to say "I am a bonafide DBA", but it is a starting point. If they cannot then they possibly are not the best developer either.
So the only real answer I can give is it really depends on the individuals ability to learn. Some are clearly better than others. That is most likely to show in their current role - regardless of that role.
The propensity to learn more likely translates to an evolution towards the DBA role (on a small curve) rather than from the DBA becoming a developer. It is a question of evolution, experience and theoretical seniority. We also need to be mindful that in the SQL world it is a relatively new recognition of the need for a dedicated or purpose built DBA and so, for a lot of DBA's, it is most likely that they have evolved from a development role of some description anyway.
But these are all very broad generalities. What is the background for this question ?
The expertise of the (app) developer is not overly different to the SQL roles, in so much as, the better ones do have an understanding. I would go an extra step and say that "knowledge" of the better developer equally applies to any computing environment such as network (comms), security, hardware (resource) utilisation etc.
However in the bigger development groups, it is likely that they are less exposed, or, don't have that responsibility. I have most definitely seen developers that really do not have any interest in database nuances, other than "tell me where I get it from".
One thing for sure is the more you actually have to perform a specific role, then the better you get at doing that job, so long as you a prepared to learn. So, fro someone to pick up elements of DBA, if they are thrust into that role then they will get better at the role, the more they do and the more they learn. It might not be enough to say "I am a bonafide DBA", but it is a starting point. If they cannot then they possibly are not the best developer either.
So the only real answer I can give is it really depends on the individuals ability to learn. Some are clearly better than others. That is most likely to show in their current role - regardless of that role.
The propensity to learn more likely translates to an evolution towards the DBA role (on a small curve) rather than from the DBA becoming a developer. It is a question of evolution, experience and theoretical seniority. We also need to be mindful that in the SQL world it is a relatively new recognition of the need for a dedicated or purpose built DBA and so, for a lot of DBA's, it is most likely that they have evolved from a development role of some description anyway.
But these are all very broad generalities. What is the background for this question ?
<<I would go an extra step and say that "knowledge" of the better developer equally applies to any computing environment such as network (comms), security, hardware (resource) utilisation etc.>>
Yes.
<<other than "tell me where I get it from".>>
LOL. ;)) I particularly like the *silence* that follows the DBA's response.
<<One thing for sure is the more you actually have to perform a specific role, then the better you get at doing that job, so long as you a prepared to learn. >>
I'd argue it depends what you learn. An old friend of mine used to say *there is a significant difference between 20 years of experience and 20 time 1 year*. He also said *Experience and Intellectual Agility can replace fundamental knowledge only in a limited fashion*. After 35 years in the database industry, he finally gave up, considering it a lost cause.
<<But these are all very broad generalities. What is the background for this question ?>>
I do believe that this discussion will give a broader picture to the questionner to help him make a decision.
Anyway, it's interesting, once in a blue moon, to have the opportunity to exchange on important issues such as the one the questionner has raised.
Thanks.
Yes.
<<other than "tell me where I get it from".>>
LOL. ;)) I particularly like the *silence* that follows the DBA's response.
<<One thing for sure is the more you actually have to perform a specific role, then the better you get at doing that job, so long as you a prepared to learn. >>
I'd argue it depends what you learn. An old friend of mine used to say *there is a significant difference between 20 years of experience and 20 time 1 year*. He also said *Experience and Intellectual Agility can replace fundamental knowledge only in a limited fashion*. After 35 years in the database industry, he finally gave up, considering it a lost cause.
<<But these are all very broad generalities. What is the background for this question ?>>
I do believe that this discussion will give a broader picture to the questionner to help him make a decision.
Anyway, it's interesting, once in a blue moon, to have the opportunity to exchange on important issues such as the one the questionner has raised.
Thanks.
Not sure whether I should post a *laughing* because of your comments, or, *crying* because it is unfortunately often the case.
It also depends on the definition of DBA - anyone can learn to build a maintenance plan, make sure backups happen, add new users etc. For some, they don't need too much more - especially if using good quality third party packages with their own databases (and no, we will not get started on that one - there are tons of third party packages that do not do the right thing with a database). So, for a small shop, with very few requirements of the database, then it becomes relatively easy. But then I would argue those tasks alone do not make a DBA.
It also depends on the definition of DBA - anyone can learn to build a maintenance plan, make sure backups happen, add new users etc. For some, they don't need too much more - especially if using good quality third party packages with their own databases (and no, we will not get started on that one - there are tons of third party packages that do not do the right thing with a database). So, for a small shop, with very few requirements of the database, then it becomes relatively easy. But then I would argue those tasks alone do not make a DBA.
<<Not sure whether I should post a *laughing* because of your comments, or, *crying* because it is unfortunately often the case.>>
At some point, humor is the only sane response to absurdity.
Check out the site below...
http://www.dbdebunk.com/laughcry.html
http://www.dbdebunk.com/content2006.html
Regards
At some point, humor is the only sane response to absurdity.
Check out the site below...
http://www.dbdebunk.com/laughcry.html
http://www.dbdebunk.com/content2006.html
Regards
Interesting to see our own dportas feature in a few of those discussions :)
<<Interesting to see our own dportas feature in a few of those discussions :)>>
Yes. Fabian PASCAL work in dbdebunk and his books was a beacon of reason for a lot of *thinking* practitionners.
Regards..
Yes. Fabian PASCAL work in dbdebunk and his books was a beacon of reason for a lot of *thinking* practitionners.
Regards..
http://sql-server-performance.com/Community/forums/p/21365/122039.aspx
And a Developer can also be expected in some cases to be aware of all these aspects which would help them code better.