Every .NET Developer Should Know Their Database Well Enough

I know the discussion on this page will likely devolve into a technical discussion of minutiae, but the point of the article is dead on. As a .NET programmer, I know a lot about databases - Oracle, SQL Server, MySQL, RavenDB, Couch and so on. I would never consider myself a DBA, and in fact, I always felt that I should understand databases a lot more.<p>One thing I've discovered over the years is that most .NET programmers - even seasoned ones with good programming knowledge - don't know squat about databases. In fact, I believe that's why so many programmers jump to something like Linq or NoSql, not because they think it's the best choice for the job, but rather because they simply don't understand databases.<p>It's my opinion that if you can't do most of your data manipulation in your data layer, and you really understand SQL (which is, quite frankly, cake compared to any other programming language except HTML), you are missing a huge chunk of knowledge that you really should have.

Article assumes that a .NET developer will only be connecting to a MS SQL Sever database and not a third-party database like Oracle, Postgres or SQLite... Other than that it's not a bad article except the number one problem I see among developers that don't understand SQL Server is how and when to use indexes.

Surely every <i>programmer</i> should know their database well enough?<p>Or even "Surely every X should know their Y well enough".

I think the same goes for a DBA too (unless very specialized and handling TB's). Having basic C# knowledge helps a DBA and with CLR based programming, it is recommended too.

Especially if they are using an ORM ironically.<p>If you consider NHibernate, a lot of time working with it is spent optimising criteria queries to ensure that the IO and CPU on the DB server are not spanked to death and that the loading strategy keeps the read count down.