Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 


 
     
Recent Posts
   
Popular Topics
Home   
Search
    Members    Calendar    Who's On

Home » SQL Server 2005 » Administering » Developers as sysadmins / no DBA / a trend?
Add to briefcase
19 posts, Page 2 of 2
««12

Developers as sysadmins / no DBA / a trend? Expand / Collapse
Rate Topic
Display Mode
Topic Options
Author
Message
Indianrock
Posted Friday, February 08, 2008 5:55 AM
Mr or Mrs. 500

Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500

Group: General Forum Members
Last Login: Today @ 5:25 AM
Points: 564, Visits: 1,457
My point about SAS70 is that your customers want to know their data is safe with you and that you aren't adding people to roles like sysadmin without great care. Rotating developers into production support and giving them sysadmin while they are in production support just seems risky to me. The argument is that developers have the business knowledge to know how to work with what in our case is a very complex schema. The solution in my mind is to have more "permanent" production support staff, who are essentially long-term DBAs and include them in development meetings so they understand business rules and the table relationships etc.

In our case there never was a DBA involved so the database was created by Visio and is very highly normalized. It will be interesting to see how it scales.


Post #453170
matt stockham
Posted Friday, February 08, 2008 7:57 AM
Right there with Babe

Right there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with Babe

Group: General Forum Members
Last Login: Thursday, March 14, 2013 10:22 AM
Points: 750, Visits: 2,937
My point about SAS70 is that your customers want to know their data is safe with you and that you aren't adding people to roles like sysadmin without great care. Rotating developers into production support and giving them sysadmin while they are in production support just seems risky to me.


Absolutely, however SAS70 isn't exactly a certification of competence to do the job - so it doesn't matter if the developer has the ability to do DBA tasks (perhaps they can just follow documented procedures when issues arise?), just that they have a true need to be given that access (obviously someone needs to provide support). As long as the number of people given the rights is kept to a minimum and other procedures followed such as removing someone that rolls off the support team, then it may not be a big deal. Having said that, separation of duties is going to come into the picture at some point - are there encrypted fields in the app that a dev knows how to decrypt, can they figure out another users id and password, are code reviews in place to ensure they don't add in a back door entry method etc. Issues like this can possibly be addressed through very strict formal processes but I doubt your auditors would be entirely happy with it.
Post #453256
Steve Jones - SSC Editor
Posted Friday, February 08, 2008 8:19 AM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: Administrators
Last Login: Today @ 9:00 AM
Points: 31,410, Visits: 13,728
Developers can make fine admins, they just usually don't. It comes down to human nature and it's because they're likely to make changes or fix things on the fly, with eternal optimism, and not necessarily follow production rules to ensure a stable system.

If you minimize rights, and can enforce your production rules, then this would be ok. The big thing here might be that a better auditing system would need to be in place to ensure that rules were being followed and short-cuts for expediency's sake, weren't being taken.






Follow me on Twitter: @way0utwest

Forum Etiquette: How to post data/code on a forum to get the best help
Post #453273
Indianrock
Posted Friday, February 08, 2008 8:20 AM
Mr or Mrs. 500

Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500

Group: General Forum Members
Last Login: Today @ 5:25 AM
Points: 564, Visits: 1,457
SAS70 has different levels of audit. This year ours was ramped up a bit and they did ask me who the sysadmins were ( at the instant anyway ) . Yes, the prod support developer is removed from sysadmin when he/she goes back to full-time programming, but there aren't really controls on who can add who when to sysadmin. To reiterate my concern, I don't like the rotation idea. Prod support ( which here is daily problem fixes, updates, reports -- NOT admin tasks such as monitoring log shipping ) should be handled by folks who plan to do that for a long time and have a PRODUCTION mind set.

It may all evolve from 1) technical management who aren't very technical, so they hire some people and turn over development of a whole new product to new employees and 2) they either don't know enough to get an experienced DBA or just don't want to pay for one.

A group of developers/data architects may not be at all interested in bringing in a DBA who is going to try and control them in any way.


Post #453274
Loner
Posted Friday, February 08, 2008 8:28 AM
SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Friday, May 17, 2013 7:05 AM
Points: 2,726, Visits: 2,925
Please read K.Brain Kelley's blog. He is a developer/DBA.

http://blogs.sqlservercentral.com/brian_kelley/archive/2007/10/29/3075.aspx
Post #453285
jtfromstl
Posted Tuesday, February 09, 2010 12:13 PM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Wednesday, April 25, 2012 8:19 AM
Points: 4, Visits: 53
The TERM DBA is used so loosely these days - no one is even sure what it means anymore.

With 15 years of SQL under my belt (both on the admin and dev/design sides) and 25 years of app dev experience, along with a strong sprinkling of network admin duties - I'm here to tell you it's as simple as this....

Most companies don't know they need a solid DBA - until - they need a solid DBA.

Most companies that figure this out too late suffer many issues before they hit bottom - and with varying degrees of hole depth - could take a long time to dig out.

Most developers are just clueless on good database design, optimization, portability, etc. They can be as good as they want to think they are but nothing replaces experience.
Post #862660
ViYes
Posted Tuesday, February 09, 2010 5:33 PM
SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: Yesterday @ 2:39 PM
Points: 202, Visits: 111
I started off as a DBA almost 15 ago and never wanted to learn Business rules and write a line of development code. I felt at that time to be a DBA was like messenger of the GOD.

Times have changed I did a lot of DBA work and some performance tuning and little of DB Architecture over time. I finally found out that these years to grow with your Organization its good to be a good DBA/DBA_Dev/DBE/and Systems Engineering as many employers want a DBA to fit in the shoes of other engineering and development groups.

Today, I have a lot more skill set to successfully manage a DBA/Engg group and also adhere to company requirements and regulations.

Corner of my heart I still am a DBA(Da Backup Administrator), but I am able to bring a lot more to my management's table need based so I can keep my job.
Post #862833
SQLRNNR
Posted Tuesday, February 09, 2010 5:48 PM


SSCoach

SSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoach

Group: General Forum Members
Last Login: Yesterday @ 1:07 PM
Points: 18,733, Visits: 12,332
jtfromstl (2/9/2010)
...
Most companies don't know they need a solid DBA - until - they need a solid DBA.

...


I would take that a step further. Many companies don't know they need a solid DBA - until they get one and see the difference it makes. Trying to have one person wear all of the Database hats is very difficult. A Database team is really what is best in many scenarios.


Jason AKA CirqueDeSQLeil
I have given a name to my pain...
MCM SQL Server 2008

SQL RNNR

Posting Performance Based Questions - Gail Shaw
Posting Data Etiquette - Jeff Moden
Hidden RBAR - Jeff Moden
VLFs and the Tran Log - Kimberly Tripp
Post #862840
Fal
Posted Wednesday, February 10, 2010 7:11 PM


Mr or Mrs. 500

Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500

Group: General Forum Members
Last Login: Wednesday, April 03, 2013 10:05 PM
Points: 584, Visits: 1,571
There's so much that has an impact in answering a query about "dev's as DBA's" that there really is no straight answer. I've found that companies need to grow large enough to warrant a DBA, and that many dev's can do a reasonable job of DBA work in the interim (though unfortunately, the reverse is not always true.)

In my career I started off as a developer and made a conscious decision to follow a database-specific path. At one role after I just started I "met the team" of developers and explained my career history. One developer was bewildered that I would turn my back on VB and pursue databases. To them, this was akin to Anakin Skywalker turning to the Dark Side. (As Yoda might say, "Is that set-based logic I sense in you?") But therein lies, for me, a very important distinction in mindset. For a developer a DBMS can be reduced to a fancy flat file. Tables are just a form of TXT file, and SQL Server is just an Excel document with indexed worksheets.

As for support, I'm not sure I'd agree with rotating DBA work. The fact that it's rotating suggests to me that no one really wants to do it, and if they don't want to do it then what sort of a job are they doing?



S.
Post #863760
« Prev Topic | Next Topic »

Add to briefcase
19 posts, Page 2 of 2
««12

Permissions Expand / Collapse

 
 
Copyright © 2002-2013 Simple Talk Publishing. All Rights Reserved. Privacy Policy. Terms of Use. Report Abuse.