Use Service Broker whenever you need asynchronous processing. See http://technet.microsoft.com/en-us/library/ms345113.aspx for examples.

It is a good practice to have a clustered key for each table. Kimberly Tripp offers all the explanations you need on her blog on sqlskills.com.

You can find additional advice here:

http://support.microsoft.com/kb/873235

Can you keep the backups elsewhere?

See http://sqlskills.com/blogs/kimberly/2005/06/25/8StepsToBetterTransactionLogThroughput.aspx

Step 8 may help you...check the log file fragmentation.

Does your backup / restore plan include log backups?

Grant, that's true, things can easily go "crazy" in this situation...SQL 2005 is great, however this does not extempt anybody from carefully planning ahead...

However even if the applications share a SQL 2005 database you can still obtain some separation by placing the tables that are not common in different schemas.

For SQL 2005:

Go to SQL Server Agent, find the job corresponding to your maintenance plan, right click the job, choose "Properties" and go to the "Notifications" tab. Here you can...

Happy birthday, Steve...

I'll be 41 in a few weeks. I'm not feeling old - not yet :).

That’s what I want for my birthday:

- good news for my business - ...

Indeed I/O can be a problem, even if everithing is captued, see also

http://sqlcat.com/technicalnotes/archive/2008/02/01/precision-performance-for-microsoft-sql-server-using-rml-utilities-9-0.aspx

I agree with Christian & Ric Sierra - great question, but the option to choose depends on other circumstances (i.e. indexes, isolation level, how much performance you need.....)

See http://msdn.microsoft.com/en-us/library/ms177596.aspx

See http://msdn.microsoft.com/en-us/library/ms143359(SQL.90).aspx

What about gathering the client info in text files and afterward importing the data in SQL Server?