As a .NET developer, do I need to know Sql Server inside out?

Question

I am a (certified) .NET developer.

I know how to write stored procedures and call them and I know quite a lot about database design (it is taught a lot in schools here and I've done quite a bit of practise and learning) as well as the T-SQL language, but as a .NET developer, do I need to know how to do things like cursors, Sql Server CLR stuff - basically the specific Sql Server specialist tasks like replication, etc?

Bare in mind no job spec I have been given has stated I need to know all of this and in my current job we have a Sql Server DBA who I guess monitors the dbs, makes them, does the replication (if needed), etc.

Thanks

Answer 1

In general, more knowledge is better - it may help you to avoid making design decisions that your DBA will beat you up about later on. In a similar vein, knowing the CLR inside-out might increase the performance of your app in a few cases... but it doesn't make them necessary. Of course, as another answer says you should know database basics such as indexing and normalization, as well as how to profile your queries.

I'd say it's worth having an awareness of these matters - for example it would be worth knowing the situations in which the Sql Server CLR hosting makes sense, so that if you come across that sort of situation you can recognise it and then get to know more details of it. I like "just-in-time" in-depth learning, but with a reasonable idea of roughly what's going on in all the revelant layers of your app.

One important point: do your darndest to build a good relationship with your DBA. It's amazing how much more productive a company can be when the DBAs, sys-admins, developers, testers etc actually talk to each other and regard each other as partners rather than enemies. Apart from anything else, the more you communicate with people outside your own discipline, the more of their knowledge (and perspective) you'll pick up anyway.

Answer 2

It depends on what type of work you want to do, but in general, I'd say no.

Typically, it's better to have a DBA administrate the DB, and understand it inside and out. I'd focus more on learning the .NET framework inside and out - leave the DB side to the DB experts, but know enough to understand the basics so you can communicate your needs well to them.

Answer 3

In my opinion, if you have an SQL Server DBA then probably not.

It won't hurt, however, to know a bit more. Certain aspects end up being very important, such as query optimization for example, especially if you're dealing with large sets of data. Indexes can really boost a system's performance and if you happen to be implementing them then you may have to work closely with you DBA because of their inherent complexity.

Answer 4

If you really work with SQL Server and not just writing desktop standalone apps, you should of course try to get more knowledge of SQL. I disagree that DBA is supposed to undertake all design tasks and you just code server access logic. You should definitely have knowledge of the database design, normalization, cursors, indexes etc. to be able to design a database for a project of a moderate size.

P.S. I'm somewhat surprised to hear such a question. I suppose anyone who cares about what he's doing won't raise that point at all...

Answer 5

Considering your question: One big table or seperate tables to store product reviews of part types? - I think: definitely YES. Your question shows very weak knowledge of database design (no offense please) and I think it is bad. You should know at least basics of the database design, it will be useful for you in common, it will make you a better professional, and it will lead you to better design decisions.

I can recommend you a couple of not bad books on database design (several months ago I decided to improve my database design skills so I took a look at several different books and chose these two):

1) Pro SQL Server 2008 Relational Database Design and Implementation (c) Louis Davidson
2) Relational database design clearly explain (c) Jan Harrington

Good luck!

Answer 6

It may depend on your place of work. We have a DBA working at my company, but in many cases developers would still be creating stored procedures and writing queries. Then we'd have the queries verified and validated by the DBA. If it's something complex that, say, feeds data to one of our mainframe systems, then we'd have our DBA do it to make sure that the query is optimized and performs well, but most importantly because the DBA's generally the one who has the most knowledge about the mainframe. Having said all that, it doesn't hurt to know SQL and T-SQL. More knowledge is always a benefit.

Answer 7

A few things one really should know if you are doing much database work are, IMHO:

1) Sql Server Security model. No, making the application's account db_owner is not a valid resolution to permissions issues.

2) How to script database creation and population. Automating that task makes development go much smoother and deployment a snap.

Answer 8

I think yes. In your next job, there might not be enough IT staff to have a DBA.
That's the case where I work - we never had a DBA, so someone (me!) had to learn the SQL Server stuff as well.

Answer 9

My answer would be that it depends on where you want to be with your development. If you do end-to-end development of front-end all the way to back-end, then it is worth knowing more than the basics of a database as there may be a development environment that developers manage more than a DBA who would normally be more concerned over production systems. On the other hand, if you do solely front-end work where someone else is coding all the back-end plumbing and you never need to open SQL Server Management Studio, then knowing all that SQL stuff isn't as useful.