Our T-SQL developer just gave his two weeks notice. We have been asked if our team of four developers would like an additional developer.

We are offered to do our own T-SQL / Entitiy Framework development or we could get another dedicated T-SQL developer.

What are the pros and cons with having a dedicated T-SQL developer on the team?

Which would you prefer and why?

  • Your question mixes T-SQL work with EF work. These are 2 different skills. Of course one person could do both, however, they are still 2 different skills. If your team has knowledge and time, you don't need an extra resources.
    – NoChance
    Sep 28, 2012 at 20:30
  • Are you losing someone who would do the operational aspects of database work; backups, deployments, keeping the system up? Or is it someone who only wrote and analyzed T-SQL and the database structures? These are usually not the same person, so curious which you're referring to. Sep 28, 2012 at 20:30

7 Answers 7


If you have at least one person on your team already who can:

  • Use a database profiler to get accurate useful metrics
  • Analyze an execution plan and know how to affect said execution plan
  • Correctly name the tradeoffs between having indexes/not and the effects of adding/removing columns from said index.
  • Define a clustered index
  • Dictate from memory what normalized and denormalized structures are and what the levels of normalization are for.

You might already have another t-sql developer who can keep the team at least in line. My list isn't comprehensive but if those things are there he can probably keep you guys out of trouble.

If you don't have someone on your team who can do those things and your team does have their hands in the database, you need someone who can do those things. Unless you're completely unconcerned with the quality of the database (a valid stance if the system is tiny enough, read: under 15 tables perhaps.)


What sort of application are you working on? Since you've had a database/T-SQL developer on your team previously, I assume that it's reasonably database-centric, but the answer to how the database is actually used by your application has an impact on whether a separate database developer is needed or helpful.

My initial reaction was "you want a T-SQL developer with database development experience on your team", but if the database is little more than a data store (little or no logic in the database layer), then perhaps you could make do without. Same if the database design is simple (meaning that to extract something useful you don't need umpteen million joins across dozens of tables), or if performance and scalability aren't great concerns in your case.

An obvious drawback of a separate database developer is the short-term cost of another developer who won't be contributing directly to the user-visible portions of the software.

Assuming that the application you are working on is reasonably database-centric, once the initial ramp-up period is taken care of, having a developer who can focus on the database aspects of the application can help quite a bit. You get someone who knows the ins and outs of set-based programming, can focus on what amount of data normalization in storage is useful in your particular case, and can hopefully help come up with or further the design of the database to provide good performance now and in the future.

Having an application developer also do database development doesn't necessarily have to be a bad thing, but there is an obvious risk that the developer in question will focus more on the needs on the application side than on what makes a good, scalable database design and then figure out how to expose that to the application layer in a way that provides the application with the data that it needs. This can lead to short-term results and long-term pain when the underlying design turns out to not be scalable. Of course it doesn't have to happen that way, but it's a risk well worth being aware of.

As for communications overhead (and particularly that causing delays), it doesn't have to happen that way. If the other developers on the team know a bit of T-SQL (it's not that hard picking up the basics like how to do selects, updates, joins, etc.), then they can certainly do prototyping in the database layer just to get the data that they need. Before the code goes to production (whatever that means in your environment), the database developer can either sign off on it saying that it's a good enough design, or take the input parameters, desired result and output result set design, and figure out a better way to perform the actual queries.



  • One less team member (less communication overhead)
  • Devs get do database work (yay! devs get to learn more)


  • One less team member (not as many people to do the work)
  • Devs get do database work (even if they don't know it)
  • No dedicated resource to take care of the database infrastructure
  • No one who understands the workings of the database well
  • No one to take care of backups, maintenance and the other "boring" parts of the job
  • No one to warn devs of applications that will cripple the database
  • No one to warn devs of badly written SQL (that works now but will kill performance later)

I think you can figure out where I am going with this.

You need a DBA. These are people who take care that databases are running, running well and to requirements. People who will educate and teach the developers as to best practices and what to avoid.

If you don't get a dedicated DBA, one (or all) of you will have to take up the slack, working on things that are not directly development related.

Though my points are about DBAs (as that's what the title of the question was originally), except for the backups and maintenance points, the rest are valid for a T-SQL developer.

The assumption is that a T-SQL developer is a professional that understands how that database works and best practices etc...

If you use EF and don't have someone who understands how a database works, you can be in problems. If your team is proficient (understands indexing for example and when to apply them appropriately, understands how to optimize a query etc...) then you probably don't need a dedicated T-SQL developer.

  • 1
    He speaks of t-sql developer here, not necessarily a DBA (a for admin not architect). A DBA to maintain backups is obviously necessary but he's not talking about losing one of these, he's speaking of losing something closer to an A for architect DBA, or in his words "t-sql developer" (or at least that's how I read his question..) Sep 28, 2012 at 20:26
  • 1
    @JimmyHoffa - The OP changed DBA to t-sql developer.
    – Oded
    Sep 28, 2012 at 20:27
  • My mistake. Otherwise I agree with your answer, I do think a team who's working on the database needs someone who knows efficient ways to design the structures for their use cases and analyze execution plans/profiles to ensure everythings going smoothly. Sep 28, 2012 at 20:35
  • @JimmyHoffa - I absolutely agree. I have expanded my answer to cover T-SQL developer and when I think one may not be needed.
    – Oded
    Sep 28, 2012 at 20:37

Which would you prefer and why?

It depends on my team skillset and the application. If the team has some SQL background, then they can make do. If the application doesn't have enough SQL work to keep 1 guy busy, then I maybe don't want a dedicated guy. If the SQL work is basic CRUD stuff, then I don't need a specialist for that.

And the opposites are true. If the team is SQL ignorant, or the app is SQL heavy, or the SQL is complex then maybe a specialist is the right way to go.

It's just like any other skillset on the team.


I think that having a dedicated t-sql person on a team that does EF is a luxury, unless her or him also helps out with the .NET side of the project. Most developers in micro-sized teams, such as yours, should be familiar with enough SQL design and tuning principles to bring your project to acceptable levels of performance. The problems that your four developers cannot address should be solvable through Stack Overflow and short-term consultants.


Short Answer: It will depend on the scope of the project and developers skill set.

For example: a Database First approach with EF may need a good T-SQL developer. Because a solid DB design with, indexes, stored procedures and functions might be very useful for targeted performance boost areas within application.

For a code first approach without any usage of complex stored procedures you may probably have NO need for a T-SQL developer.

In addition, if you have in your team a developer who has solid knowledge in DB design, index, query profiling, analysis of execution plan... then you have a right guy in a team to take care of all DB development that you may expect to have.


Short Answer:

That depends on the scope of the project and developers skill set.

Long Answer :

While acquiring such T-SQL or DBA specialists, you and your colleagues have to be trained up in the sense that they must have the mindsets and methodology to handle the SQL

It is because as the development grows for a long time, your SQL and exception-handling cases must increases and be more complicated.

Not the answer you're looking for? Browse other questions tagged or ask your own question.