September 13, 2008 at 3:54 pm
We follow CMM and COBIT standards in all of software development and also creation of schemas and other database objects.
I know that I can bring down an entire production server with 4-5 lines of code and that is why we not only do test on development server but we goes through a developer peer review QA process and then the DBA reviews all of the tables, views, SP and UDF objects. And if most DBA's are programmer, I would love then to review the code too.
September 13, 2008 at 4:19 pm
Actually, there's a bit of confusion about what a "DBA" actually is...
There are "Systems" DBA's who may come close to not knowing how to write any code other those associated with maintenance tasks. Others may know more about the code, but their primary expertise centers around the server, it's settings, and it's hardware. These folks typically are Ninja's at setting up and tuning hardware and the server software, but not necessarily. Good ones monitor server performance and code performance... if a piece of code takes to long, a good Systems DBA can isolate it and alert someone to fix it.
There are "Application" DBA's who are really SQL Developers on steriods and got to be that way because of thousands and thousands of hours of practice and actual code as well as course attendance and experimentation. Typically, they also know a little bit about being a Systems DBA, but not necesarily. Their real forte' is writing super fast, highly scalable SQL, regardless of the hardware, and knowing how it interfaces with the GUI world even though they may not be able to write GUI code. These are the type of people who can rewrite a job that normally takes 24 hours to run and make it do twice the work in a run time of only 15 minutes and the job will never fail. Depending on their calling, they may also be experts at "add ons" such as SSIS and Reporting Services and, even if they aren't, can easily help other Developers in those areas after just a few minutes of study.
Then there are the "Hybrid" DBA's who have one foot in each world above.
Obviously, the levels for each of the 3 types vary from POS to Ninja.
So, when you talk about "career path", the question must include, "for which DBA position"?
You might want to consider a 4th position for DBA's... they're not normally considered to be "DBA's" but have gained extreme favor in many companies. These folks actually have 5 feet... they live not only in the world of Systems and Application DBA's, they also live in the user community as a type of "Systems Analyst" that can easily sit with users, figure out what the user needs from what the user says (s)he wants, setup new database(s) to do it, find all the necessary sources of data to populate it with and write the code to import it, sit shoulder to shoulder with GUI Developers to help them figure out what's needed, write a good amount of the SQL while mentoring other SQL Developers in their tasks, and make management like it all including the schedule. They'd probably need some help setting up a SAN and doing all the required network connections, but they wouldn't need much help on anything else. They probably would NOT be responsible for the security/logins for the system, but they would be absolutely aware of the requirements and, possibly, would be instrumental in defining those requirements. Typically, these folks work very closely with all those people... the Systems DBA's, Application DBA's, User, GUI Develolpers, and Management.
I just call 'em "Jack of all trades, Master of many". 😀
--Jeff Moden
Change is inevitable... Change for the better is not.
September 13, 2008 at 4:44 pm
Hey, Bob Bridges! You still there? Has any of this helped?
--Jeff Moden
Change is inevitable... Change for the better is not.
September 13, 2008 at 6:38 pm
Some of us have lifes outside of SQL Jeff, maybe he went to bed :hehe:.
September 13, 2008 at 6:49 pm
Ninja's_RGR'us (9/13/2008)
Some of us have lifes outside of SQL Jeff, maybe he went to bed :hehe:.
Heh. Highly overrated if you ask me. 🙂
[font="Times New Roman"]-- RBarryYoung[/font], [font="Times New Roman"] (302)375-0451[/font] blog: MovingSQL.com, Twitter: @RBarryYoung[font="Arial Black"]
Proactive Performance Solutions, Inc. [/font][font="Verdana"] "Performance is our middle name."[/font]
September 13, 2008 at 8:45 pm
Jeff Moden (9/13/2008)
Hey, Bob Bridges! You still there? Has any of this helped?
Yes Jeff, I'm still here... just watching to see how it progresses. If I am reading the posts correctly, it seems that what we currently practice is in line with a lot of other shops (at least of the majority of the folks who have weighed in on this thread.) Most of our developers don't have a problem with our current practice, only a couple of the newer guys. One guy in particular, this really gets under his craw.
We'll be reviewing our policies soon so see if any tweaks are in order.
I appreciate all of the input (and will be watching to see if anyone else puts their 2 cents in...)
Bob
September 13, 2008 at 8:53 pm
I am one of the new System Analyst guys who is challenging the status quo. I would end my participation in this delightful forum by quoting a football analogy: DBA are the defense and the Software developers/System Analyst are the offense of a football team and I have not heard of any football team where the defense tell the offense how to do their job and be successful.
September 13, 2008 at 9:43 pm
Heh... good analogy... unless you don't realize that you're on the same team.
You guys need to sit down and hammer out your differences, not so that anyone wins but the company. Stop thinking football and analogies and start thinking about what's the best way to support the company that pays you to think, not fight amongst yourselves. It's not a two team shop!
--Jeff Moden
Change is inevitable... Change for the better is not.
September 13, 2008 at 10:08 pm
rian67 ,
Here is what I'd say. The development server needs to be controlled, and supported to fulfill the requirements of the development team. This does not mean that they should necessarily have full, and total access to do to whatever they want. If you are working on a development project you want to know that the changes and updates to the system are not causing problems with other developers.
From what I have been able to surmise from this thread is that there may be a need for individual development systems, sandboxs, for developers to initially work with on various projects. This is when the Developer Edition of SQL Server really comes in handy. Each developer can have a totally isolated environment on their own desktop systems that would allow them to have greater control over what they are doing. Moving changes from there to the development server would then have a process where by the DBA's can verify the changes and potential problems that may be encountered so that those issues can be properly mitigated.
Personally, I don't want developers goinginto the development system and making changes that could affect other developers negatively. There should be some controls and restrictions in place, even on development systems.
😎
September 14, 2008 at 4:49 am
rian67 (9/12/2008)
I understand being a gate keeper is a tough job. But no one has still being able to answer my main question?Who handles the creation of Integration Packages, Replication Packages, creation of Analysis Cubes in your company if the developers do not have access to the SQL Server in Developement environment? Unless you are telling me that this can be done with dbo access.
Sysadmin rights can be given to a select few, say the system owner and team lead(s). Having said that, I believe that DBAs should familiarize themselves with all technologies in SQL Server - SSIS, SSAS, SSRS, CLR etc. - and not be content with the familiar territory of the db engine alone.
These technologies should not be the purview of developers only.
__________________________________________________________________________________
SQL Server 2016 Columnstore Index Enhancements - System Views for Disk-Based Tables[/url]
Persisting SQL Server Index-Usage Statistics with MERGE[/url]
Turbocharge Your Database Maintenance With Service Broker: Part 2[/url]
September 14, 2008 at 10:16 am
Depends on what type of DBA you have (see previous post). And, again, it doesn't matter if you limit the people on the Dev box or not if you don't have some form of quality checking process in place. If you don't check the code, it's gonna be crap because people always take the path of least resistance.
--Jeff Moden
Change is inevitable... Change for the better is not.
September 14, 2008 at 1:27 pm
Jeff Moden (9/14/2008)
Depends on what type of DBA you have (see previous post). And, again, it doesn't matter if you limit the people on the Dev box or not if you don't have some form of quality checking process in place. If you don't check the code, it's gonna be crap because people always take the path of least resistance.
That there are different types of DBAs out there, there is no question. Given today's economic climate though, one cannot be content staying as system DBA, ie. as someone responsible just for keeping day-to-day operations afloat, ie. having no other development or database design skills at their disposal. The more one knows the more marketable one is. It's a jungle out there, and those most adaptable and most eager to stay on a learning path will be most successful. Besides, looking solely after backups and database availability is so darn boring! 😉
__________________________________________________________________________________
SQL Server 2016 Columnstore Index Enhancements - System Views for Disk-Based Tables[/url]
Persisting SQL Server Index-Usage Statistics with MERGE[/url]
Turbocharge Your Database Maintenance With Service Broker: Part 2[/url]
September 15, 2008 at 5:59 pm
Marios Philippopoulos (9/14/2008)
Jeff Moden (9/14/2008)
Depends on what type of DBA you have (see previous post). And, again, it doesn't matter if you limit the people on the Dev box or not if you don't have some form of quality checking process in place. If you don't check the code, it's gonna be crap because people always take the path of least resistance.That there are different types of DBAs out there, there is no question. Given today's economic climate though, one cannot be content staying as system DBA, ie. as someone responsible just for keeping day-to-day operations afloat, ie. having no other development or database design skills at their disposal. The more one knows the more marketable one is. It's a jungle out there, and those most adaptable and most eager to stay on a learning path will be most successful. Besides, looking solely after backups and database availability is so darn boring! 😉
Agreed. Like I said, take a look a couple of posts back where I describe 4 types of "DBA's".
--Jeff Moden
Change is inevitable... Change for the better is not.
Viewing 13 posts - 31 through 42 (of 42 total)
You must be logged in to reply to this topic. Login to reply