Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase «««1234»»

The Ratio Expand / Collapse
Author
Message
Posted Friday, October 4, 2013 10:55 AM
Grasshopper

GrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopper

Group: General Forum Members
Last Login: Friday, November 8, 2013 1:05 PM
Points: 10, Visits: 43
The relationship to developers is an interesting one, my experience has been in vendor software shops and IT departments.

In the vendor development shop (mostly application maintenance vs. new product development) there was typically one DBA per team (19 teams) unless it was under 4 developers, that dba relied on the internal technical support desk for the IT administration and tier 2+ DBA support. The internal technical support team also had DA for pure database and schema design. This was a effective and very efficient model, the teams felt 'held up' but the schemas and performance were excellent, very important when those structures are heading out to clients.

In the IT shops the ratio has been much lower because your business needs to have at least 1 (if you're the only developer/tech resource in a production IT shop then you're a DBA first). Currently we primarily outsource development so every external developer is a DBA and running in a similar mode to the general comments in this thread. From inside our walls I'm the DA and we have an in-house DBA to handle our database requirements (operations, tuning, backup and recovery) so our internal ratio is 1:2

IMHO a ratio of over 1:10 is likely not considering the DBA responsibilities that are being assumed by some of the development staff. If those developers are designing and implementing schema, backing up or restoring databases then you have a good portion of a DBA FTE floating around there - be careful, in my experience most developers don't get data.
Post #1501689
Posted Friday, October 4, 2013 11:15 AM


SSC Journeyman

SSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC Journeyman

Group: General Forum Members
Last Login: Wednesday, June 4, 2014 1:20 PM
Points: 80, Visits: 116
I am currently the only Architect/DBA, supporting 6 full time developers. We will also contract 1-3 developers here and there for focused work, so the ratio ranges from 1:6 to 1:9. But, I also have several analysts that can use direct access to the databases and could potentially write a painful query...
Post #1501701
Posted Friday, October 4, 2013 12:58 PM
SSC-Addicted

SSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-Addicted

Group: General Forum Members
Last Login: Friday, June 13, 2014 12:40 PM
Points: 461, Visits: 753
My experience isn't one you want to use.. GRIN

As a consultant, I worked on teams that were typically pretty small, no more than 5-10 people. Not once did we have a DBA involved. These were SQL Server projects. We were involved in development work.

We also did work for an engineering firm that used Filenet. They had Oracle DBAs, but we did not provide that experience at all. Our team was typically 1-2 people.

I also worked for two development firms. In one of them we had 6 developers, all of whom did their own DBA work, but it was with a DBase style database. The other was a SQL Server database, with one Cobol developer, three VB developers, and one QA member. Again, no DBA, but one developer "owned' that responsibility. He was clearly qualified to play that role.

In my current role development is not done internally. We purchase software. We have no official DBAs, but one who "supports" Oracle, and then I support approximately 40 separate SQL Server production database instances. There is a slightly smaller count of test systems. My role is an Analyst, though, so technically speaking, we have no real DBA.

I have to think that either I have had a lot of bad luck in positions, or hopefully, I have been able to play multiple roles well enough that the choice has been made to save the money. Either way, I truly hope my experience is unusual, but I fear it is not.


Dave
Post #1501738
Posted Friday, October 4, 2013 1:00 PM
SSC-Addicted

SSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-Addicted

Group: General Forum Members
Last Login: Friday, June 13, 2014 12:40 PM
Points: 461, Visits: 753
louie1487 78804 (10/4/2013)
I'm a developer that asked for my own server instance. Since I have sysadmin rights to it, I guess I am my own dba. Lol. 1:1?


The correct ratio would be something like these.

0.5:.05
0.6:0.4
0.7:0.3

1:1 implies there is one of you, and another distinct individual as a DBA.


Dave
Post #1501739
Posted Friday, October 4, 2013 4:14 PM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Today @ 1:46 PM
Points: 5,173, Visits: 2,786
dtinney (10/4/2013)
...be careful, in my experience most developers don't get data.


I agree. Even as a developer. Having said that, my participation here perhaps sets me apart from the worst of the crowd


Gaz

-- Stop your grinnin' and drop your linen...they're everywhere!!!
Post #1501783
Posted Friday, October 4, 2013 4:57 PM
Grasshopper

GrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopper

Group: General Forum Members
Last Login: Thursday, July 10, 2014 12:42 PM
Points: 19, Visits: 105
There are so many variables, I don't know how you could qualify a "good" ratio of Developers to DBAs. DBA can mean a lot of different things. If you have a few small (<10GB) databases in a small shop with not much change happening, then a decent "jack of all trades" can usually cover the jobs of DBA and developer as well as server admin.

I think you have to base the number of DBAs on the number of servers/databases/sizes that you have. Once you get past 100GB of data in the databases, you really need a dedicated DBA, unless you have 1 large database that you don't change much. Of course, if you have a dozen servers with a dozen 1-2GB databases on them, that requires more time to manage. I think that SQL Server out-of-the-box works great until your databases grow to over 10GB. That seems to be a good general benchmark of when you start seeing performance issues that you just can't keep throwing hardware at to make it work better.

Also, if you are in an industry with compliance issues, you might be at risk if your "DBA" is busy tweaking style-sheets. A lot of people call themselves "DBAs", right up until that dusty box in the corner that the vendor set up starts having issues. As the company grows, so does the databases. A good developer can usually put together a fairly good data model and create some useful indexes, but, eventually, you will have performance issues that will not heal themselves. When was the last time you tried to restore a backup, just to be sure it's working correctly? How long since you last refreshed your dev environment? What about upgrades? What about High Availability? What about security? All that data is kind of useless unless you create some good reports and/or dashboards that you can actually make some business decisions about. Considering a data warehouse?

Of course, then, as the IS department grows, is everyone following the same master plan, if there is one? From what I've seen, you don't always get instant "synergy" when you start adding more cooks to the kitchen. Our IS group of 9 people gets a lot more done than the last group of 60-70 could do because we don't bury ourselves in "process", we don't have anyone on the team that wants to stand in the way of progress because they are scared of what is unknown, and we don't have anyone doing the over-promise/under-deliver stuff. It's nice to be the one-man IS/IT department, but you have to know your own limitations. I think most of us in IS/IT have a bad combination of megalomania and poor estimating skills. It's easy to get cocky when you create an index that improves performance by 1000%, but then you might have another emotion altogether when someone asks you to recover some lost data!
Post #1501788
Posted Friday, October 4, 2013 5:35 PM
SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Today @ 11:53 AM
Points: 2,264, Visits: 1,312
Here and now it is about 1:15 as far as developers to DBA's but that does not include GIS staff who present other challenges unique to their science. In times past it has been both higher ration and lower.

But is not a DBA who writes complex SQL processes, scripts, and procedures a developer as well? Worth a thought!


Not all gray hairs are Dinosaurs!
Post #1501797
Posted Saturday, October 5, 2013 2:39 PM


SSC-Dedicated

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

Group: General Forum Members
Last Login: Today @ 7:07 PM
Points: 36,735, Visits: 31,185
John Mitchell-245523 (10/4/2013)
Two DBAs to about 19 developers. And they insist we handle stuff like backups and restores on development servers for them, "because the DBAs have always done that for us". I said yeah, my mum always used to do my washing, until I grew up and started doing it myself.

John


Heh... you have to trust me on this... You DON'T actually want them to do their own backups.


--Jeff Moden
"RBAR is pronounced "ree-bar" and is a "Modenism" for "Row-By-Agonizing-Row".

First step towards the paradigm shift of writing Set Based code:
Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column."

(play on words) "Just because you CAN do something in T-SQL, doesn't mean you SHOULDN'T." --22 Aug 2013

Helpful Links:
How to post code problems
How to post performance problems
Post #1501862
Posted Saturday, October 5, 2013 2:50 PM


SSC-Dedicated

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

Group: General Forum Members
Last Login: Today @ 7:07 PM
Points: 36,735, Visits: 31,185
1:5 for me not including any end user involvement or "Client Data Architects" or Project Managers or BA's or Managers or anyone from NetOps any offsite consultants or any of the vendors or...

Sometimes I actually get to do DBA stuff. Fortunately, I automated most of the critical stuff including some handy morning "job" reports, my own flavor of automated backups, some disk usage reports, and some "high usage" reports to automatically find troublesome code, etc, etc, a long time ago.


--Jeff Moden
"RBAR is pronounced "ree-bar" and is a "Modenism" for "Row-By-Agonizing-Row".

First step towards the paradigm shift of writing Set Based code:
Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column."

(play on words) "Just because you CAN do something in T-SQL, doesn't mean you SHOULDN'T." --22 Aug 2013

Helpful Links:
How to post code problems
How to post performance problems
Post #1501863
Posted Sunday, October 6, 2013 8:49 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: Today @ 2:16 PM
Points: 586, Visits: 2,830
The last place I worked for that had in house development and hosting was about 1 to 8. It was a strange mix as one system had two developers and one DBA, the other had two DBAs and about 30 developers. But DBA definition is critical in this one.

We had three people who were called DBAs and had DBA in their title but did no monitoring, no tuning, had no backup responsibility. All they did was some TSQL to collect data or fix TSQL application bugs. It drove me nuts as a former DBA and now BA/PM as their code was all spaghetti, did not know how to tune (just add an index!) and I couldn't even get them to do code formatting for readability. But these guys had been around for 15 or more years so all I could tell management is they are in job protection mode. After them making system changes that made everything crawl after adding several new indices that weren't being used (apart from where they added index hints) and one column that had around 15 indices on it I finally got any *new* code they were deploying over to the DBAs I trusted to tweak, tune and standardise.



Post #1501982
« Prev Topic | Next Topic »

Add to briefcase «««1234»»

Permissions Expand / Collapse