I normally don't spend a lot of time thinking about WSS content databases, but a recent engagement changed all of that.
The client has a configuration that - while probably not common - is not absolutely crazy either.
Basically, they have a Virtual Server, and have multiple site collections underneath it, one for each project. To simplify backups, they have decided to have a separate Content Database for each site collection.
No problem - STSADM includes the CreateSiteInNewDB command. This will add a new content database to our virtual server, and set up our new site collection within it. Done and dusted.
But then the client peeked inside their WSS configuration database and noticed that some site collections were using the wrong database. So Project D was in Database E, and Project E was in Database F. This is not good, because they use SQL Server for their backup and restores. So when then think they are restoring Project E, they are actually rolling back Project D.
How did this happen? After some investigation, it turns out that the STSADM Restore command doesn't really care which of the virtual server's content databases it restores to. You can't force it to use a particular database. So although Project D may be in Database D prior to your restore, SharePoint, in it's infinite wisdom may decide to put it into Database E after the restore.
Microsoft reckon that this is "by design", but it definitely sounds like a flaw in logic to me. We are planning to get around this issue by manipulating the Databases table before and after the restore. Basically we will update the SiteCount values to contain the SiteCountLimit value prior to the restore, and then set them back again afterwards. This should ensure that SharePoint can only use the existing content database for a restore.
