Regularly, I get the question about how to move content between databases when the databases become “too large” - whatever that size happens to be.
My response is that the data movement story in this version of SharePoint is not very good. You can use smigrate.exe to move sites from one database (think site collection too....) to another, but the permissions don't move with it with smigrate.exe. So, you can use stsadm.exe to move site collections from one database to another, but it is my experience and understanding that the restore process using the command line forces you to create a new content database into which the site collection will be restored. Others may be able to help me understand this more fully since it is really a WSS thing and not a portal thing.
SQL DBAs need to be ready for the database tsunami that is coming with increased use of SharePoint. You will be managing many databases with increasing size, so please ensure that your upper limits are realistic in light of current technology. One thing I'd love to see are posts/responses from SQL DBAs on what their upper limits are for databases in SQL.
Finally, the way to ensure databases don't grow beyond a certain size is to limit the number of sites and employ site collection quotas. By using these two elements together, you can ensure your content databases don't grow beyond a pre-determined size.
Bill English
Mindsharp