SQL Server insert/Update/Delete and Select performance/deadlock suggestions

Question

I am faced with a task, where I have to design a web application in .net framework. In this application users will only (99% of the time) have readonly access as they will just see data ( SELECT ).

However the backend database is going to be the beast where every minute there will be records updated / inserted / deleted. The projection is that at very minimum there will be about 10 million records added to system in a year, in less than 5 tables collectively.

Question/Request 1 :

As these updates/inserts will happen very frequently (every minute or 2 the latest) I was hoping to get some tips so that when some rows are being changed a select query may not cause a thread deadlock or vice-versa.

Question/Request 2 :

My calculated guess is that in normal situations, only few hundred records will be inserted every minute 24/7 (and updated / deleted based on some conditions). If I write a C# tool which will get data from any number of sources (xml, csv or direct from some tables from a remote db, a configuration file or registry setting will dictate which format the data is being imported from) and then do the insert / update / deleted, will this be fast enough and/or will cause deadlock issues?

I hope my questions are elaborate enough... Please let me know if this is all vague...

Thanks in advance

Answer 1

I will answer first your question #2: According with the scenario you've described, it will be fast enough. But remember to issue direct sql commands to the database. I personally have a very, very, similar scenario and the application runs without any problem, but when a scheduled job executes multiples inserts/deletes with a tool (like nhibernate) deadlocks do occurs. So, again, if prossible, execute direct sql statements.

Question #1: You can use "SELECT WITH NOLOCK".

For example:

SELECT * FROM table_sales WITH (NOLOCK)

It avoids blocks on database. But you have to remember that you might be reading an outdated info (once again, in the scenario you've described probably it will not be a problem).

You can also try "READ COMMITTED SNAPSHOT", it was supported since the 2005 version, but for this example I will keep it simple. Search a little about it to decide wich one may be the best choice for you.