Completely agree with the points made about security David, it's usually what you don't know about that the latest hack will take advantage of. Recognising that, whilst at the same time testing and applying the latest patches as they become available keeps you from becoming complacent and alert to the risk.

Security issues aside, I've experience running SQL Server 7 & 2000 against IIS and have found that the two most definitely DO compete for memory even on relatively lightly loaded systems. I'm sure it's possible to get a good compromise between the two on a system with plenty of RAM, although personally I don't like limiting the memory that SQL Server can allocate to itself, especially if it is being used in a changing environment and hosting more than just one database, as memory requirements can grow and cause problems you didn't expect when first tuning for optimal memory needs. In a sentence, IIS and SQL Server don't make good bedmates. You can spend more time sorting out the issues than buying a new server.

The other practical problem I've found is that third party vendors like to release patches to their (web based) software on a regular basis, and some of these require server re-boots to initialise IIS components. Obviously this is hardly ideal if the database server is hosted on the same box, serving up data to more than a single set of users using different apps, as the outage will take down all of the apps., not just the one that needs patching.

However, for hosting internal development sites or a single non-profit making site, with a single database, I would imagine the cost implications will almost always outweight the resiliance arguments. Just hosting SQL Server is expensive, without putting it on a separate box.

Edited by - jonreade on 06/23/2003 03:20:56 AM