May 12, 2002 at 7:50 pm
They call me a Database Analyst, but really my role is more of a programmer flavored with a hint of DBA...
I've done a lot of VB coding, SQL coding, and even a little bit of ASP. I'm also the defacto DBA regarding backups, data transfers, imports, tuning and design. A month ago, I developed some scripts in REXX running inside a terminal program to grab data off a client's *nix machines... I do at least a little bit of anything that has a technical element here.
I'm the only person in the company with any significant experience regarding SQL Server, DBA or programming, and one of two of us that can do development period. I wind up doing part time DBA stuff, and the rest of the time developing. Oh, I also do tech support for a couple other users when they need access to the data (almost everyone here uses Access and Excel).
We don't have any real separation of roles... the other dev does some of his own SQL coding, at least simple procedures, but no one has 'Final Say' over whether or not something goes live; most of the time, something is pushed live when management says it has to go... and no, we have no QA department. If he or I make a mistake, it winds up on the web. Ick.
I think it should be the role of the DBAs to protect the integrity of the databases, document changes to the schema and tune idexes and procedures. I think it's the developers' job to design programs and implement them to meet the clients' needs(I definately see someone that develops SQL procedures to be a full-blooded developer). I think both camps should have a couple of 'ambassadors' to keep things moving along and to diagnose problems. I also see the DBA role as one of a part-time developer to build tools to make the other developers lives easier and more effective, and to build stored procedures that might go beyond an application developer's knowledge of SQL. Oh, and can't forget the role of mentor to any developer or user that wants to make everyone's job easier by learning something about SQL. 🙂
Matthew Galbraith
May 14, 2002 at 4:03 am
I think its better that a DBA is also a Developer because the way the logic is implemented (u should have heard about dbdebunk.com). I myself is responsible for Database development (and anything wrong that may create performance or DB realted issues due to my code). Even programmers who are doing DB development should know about DB they are developing for so decreasing the pressure on DBA.
Kashif.
May 16, 2002 at 8:09 am
Having a developer background as a DBA has many benefits. I'd say the biggest benefit is it allows you to keep the big picture in perspective.
But coming from a shop where I was the only person knowledgeable in SQL to a company where a high percentage of the staff is familiar with SQL and several members are quite experienced can be a challenge. The more experienced members tend to view the DBA as a figure head and will at times not follow the rules that only the DBA moves objects in QA and production. The line between DBA and Developers gets blurred. The current security structure permits this to happen but I'm working on changing this.
Neil
May 16, 2002 at 12:31 pm
Well everyone here has a valid point, thou being a DBA you should always know how to properly write TSQL, and also at least understand what is being done on the front end that accesses the database and what would be the best way to optimise both.
There are times when VB developers come to me and say I need to get this data in one shot. I look at what it involves on the server, for example how many joins I will have for some report or how much aggreagations will be performed and how many rows will be returned, what would be my concurency issues. For example should
"insurance software" retrieve agency names on load or get them when needed, how many agencies there are couple of hundred or thousands. It is very beneficial to DBA to be involved in this to be able fine tune the server and not allow to let someone ask you to write a procedure that has o go recursivle through a table and retrieve data when it can be lazy fetched.
So you might be able to put a fine line in the duties of DBA and developer, but DBA should know what and why he is doing.
Also I think DBA should fine tune what he needs in the test or QA db, before it ever gets to production.
June 13, 2002 at 11:23 am
I would add to someone who wrote "I`m in the unlucky position of being Analyst/Programmer/SQL DBA/Datawarehouse Analyst/Reporting Architect all in one" the following: "also AS400 and NT sysAdmin/helpdesk/"business-oriented" data guru..."
and I agree "It`s never boring!!" and the day should have more hours !! 🙂
June 20, 2002 at 3:48 am
quote:
I`m in the unlucky position of being Analyst/Programmer/SQL DBA/Datawarehouse Analyst/Reporting Architect all in one. It`s never boring though!!
Add in eiStream Workflow, systems architect, project manager, internal technical consultant and general gopher, and the only idiot who answers the phone at 6am, and that covers my working life quite nicely.
Never boring. Never have time to be bored. And yet, somehow I have time to come here...
Thomas Rushton
blog: https://thelonedba.wordpress.com
June 23, 2002 at 11:17 pm
I'm a molecular biologist who designs laboratory automation to run diagnostic assays in biohazard environments all over Europe. I maintain and repair the robotics equipment/Program data collection terminals, robotics, SQL 2000, and the VB front-end. I'm also the SysAdmin/Desktop support for our company. Sometimes when I schedule an interdepartmental meeting, I'm the only one there... and if one more person complains to me that they can't access their email, everyone is getting a type writer and fax to work on. :'>
JM
P.S. I really appreciate having such a knowledgeable group/forum to help me with the rough spots.
June 24, 2002 at 3:32 am
In my experience the ideal is to have a realy good dba acting as gate keeper to the production systems, and a really good developer has gatekeeper from development to test.
It's not often that you find a dba who has all the development issues sewn up, so the reality is often very grey.
June 24, 2002 at 5:14 am
I am in the somewhat dubious position of moving myself from Developer to DBA as we've recently introducts SQL Server 2000 as our main backbone and the company relies on it's data.
My problem is that we have a development team that have, up until now, been able to dive directly into production data to affect repairs to data and code, put code live the moment it has been designed, etc.
We've had some disasters along the lines which have shut the company down for sometimes up to half a day whilst we try and dig ourselves out.
I'm trying to enforce the rule that onthe the DBA can roll changes onto the production server after they have been vetted and optimised, but it's a hard battle. Even though the developers only have enough time to develop the code and not to test it as thoroughly as it should, they still want to set it live, and are willing to kick up enough of a stink to make my life hell from them and from above!
One of my main concerns is also for security. We have a lot of very sensitive data, and we've had at least one unscrupulous developer in the past that could have taken advantage of it, so my concern is that even though I trust the developers we have, who can say what they might do given enough of a grudge. (Me - paranoid - never!)
I finally gave in a while back to allow the developers access to the production server only to be greeted with a scream a couple of days later as one of them ran an update without transaction blocks and without a filter. Only very fast reactions saved having to restore the database!!
However, we have to set up accountability for botches like this, and I'm pretty much setting myself up as the scapegoat for it. If the company loses half a days work, someone has to be held to blame, and as I'm responsible for the databases, I don't want to be shouted down for something that was out of my control.
So, whether they like it or not, they can do what they want to the development server, but the responsibilty for the production server has to fall on my shoulders, whether I want it or not.
---------------------------------------
It is by caffeine alone I set my mind in motion.
It is by the Beans of Java that thoughts acquire speed,
the hands acquire shaking, the shaking becomes a warning.
It is by caffeine alone I set my mind in motion.
June 24, 2002 at 1:10 pm
I see the DBA as the Database system administrator. The DBA is responsible for the health of the system and all of the databases that reside on it. A DBA is part gatekeeper, a code reviewer and system analyst. The DBA is responsible for review of error logs at both the sql and operating system level. The DBA also reviews and makes recommendations on additional system usage. ie adding additional databases based on performance review or space availability. The DBA insures that the databases have been backed up and that the files have been written to tape or stored off line. Generally the DBA performs tasks that fall outside of the roles of a developer or are at a level that require system administration. This includes system upgrades, patches and virus protection.
I see a developer as a programmer. Someone who is responsible for the code within an application. A developer is someone who is working on new applications or revisions to existing ones. In my world developers have full access to a development system where they develop the code and structure as needed. This code when ready moves to a test environment for quality assurance and further integration. A developer and a DBA work together to resolve any issues.
Depending on the complexity of the environment the developer and DBA maybe the same person. However the more complex the environment the more likely these duties will be separated. Monitoring 65 sql servers on a regular basis is daunting. Don't get me wrong developing code for a complex application can be just as complex.
I've worked as a developer for a short period of time and have been a DBA for the past 24 months. I typically create code that assists me in the maintenance and review of all of the databases I've also used code to track down problems and monitor database growth and system performance. I've worked with some developers that scare me by opening a connection to a database within a loop and I've also worked with developers who clearly know more than I do.
dwojdac
June 27, 2002 at 5:49 am
First of all I think that for most people it would be hard to do both jobs, as each job requires considerable time. In theory the results of this most likely are slower response time to the problem from the DBA and a slower development of applications by the developer.
As a developer I must say that we have a good DBA in our company, we always find a solution, but for him to go through all my queries is virtually impossible. Imagine three applications with each about 300 SP's and with each 50 tables that were developed in the last year, it becomes clear that it would be to expensive (in man hours) to have a DBA do full time checking of the SQL code (that most of the time is extremely complex in normalised tables).
The way I see it is that BOTH the DBA and the developer are responsible for the performance. I first build my projects on my local desktop (basic P4, nothing fancy), if there are parts of the system where I think I can improve performance by indexes or rewriting queries I give it a try. Analyse the execution plan and either continue or restore a backup (in case it was slower). After I'm satisfied with the result on my desktop I transfer it to the server. Most of the times the response times on the server are way better, so there is not much need to try and improve even further by the DBA (which is always possible, but sometimes not economically interesting).
In the end I think that in some cases the DBA may have more experience than the developer in writing complex SQL code and some times vita versa. But they should always have good communication lines and advise each other things.
After one year of SQL at college (didn't do much with SQL there compared to what I do now), reading through Robert Viera's Professional SQL Server 2000 Programming and three complete DB applications I'd like to think that a developer can produce very high performance and solid database solutions without much help from a DBA. But then keeping the server up, the backups scheduling and the technical side of the server is not my thing... that is clearly more for the DBA.
Edited by - Navaros on 06/27/2002 05:55:50 AM
June 28, 2002 at 10:42 pm
As a DBA/Developer, I have noticed that programmers tend to come up with data structures that are application specific, don't reflect business objects, and are therefore not generic enough to be reusable. I find that the business really benefits when flexible structures are implemented becuase less recoding needs to be accomplished when v2.0 rolls around or when management needs a report that spans applications. The downside is that the structures can be intimidating to the programmer without shielding the complexity through views, UDFs, types, and SPs.
Viewing 12 posts - 16 through 26 (of 26 total)
You must be logged in to reply to this topic. Login to reply