Multiple content databases and Project Sites

Question

Hi,
I am in the process of migrating our Project 2007 PWA + Project Workspaces data to Project 2010.  Our PWA site and the Project Workspaces are in a single content DB (2007) and I am trying to work out what I should do when I migrate it.  Our content
DB is about 150GB which I believe is around the maximum that it should be.
I am unsure about a couple of things.
1. In SharePoint, you can assign multiple content DBs to a single web application, but each Site Collection will only live in a single content DB.  Given that all of the Project Sites are actually just sub-sites of a single Site Collection I cannot see
a way to ever split them up into multiple content DBs.  Am I missing something?
2. There is another post in this forum talking about whether to split PWA and Project Sites into different content DBs (and therefore Site Collections) with Project 2010 or not.  Even though I have read it I am still unclear as to whether or not I should
do this and what the actual pros and cons are.
Thanks in advance for the replies.
Cheers,
David

Answer 1

All,
The requester wants more than 1 Site Collection for Project Sites and he wants more than 1 content database for each site collection. Neither of which apparently SharePoint can do. However,
for large numbers of Projects and associated Project Sites this will almost certainly be a necessity.
The Suggestion was that the PWA site collection and Project Sites site collection could be different and hence on different databases (even web apps). Fine. But not helpful, really, since that
only gets us to two site collections.  One very small and one that will potentially grow very large, too large.
What appears to also have been suggested was to create a separate site collection for very large project sites.
While this approach could work, it is administration intense and is bound to have issues related to PWA navigation, etc...and certainly not part of the Project Server 2010 PWA automatic Site
Creation methodology.  It also is after the fact and not really scalable.  it would be possibe, but tricky to do this after the fact - moving it from one site collection to another - and then reset the URL in PWA Server Settings,
could be done.
I would suggest something similar, but a bit more pragmatic...Thanks Bruce!
Create 1 new Site Collection for Project Sites (same web app) in a new content DB - use script.
Setup PWA to provision all new Project Sites to that new site collection.  Maintains automatic site provisioning.
Monitor
the size of the DB, when it reaches a reasonable limit (? 50GB ?) - repeat this process, create another site collection in a new DB - but
change the PWA provisioning settings to have all new sites go to the new (next) site collection.  Existing sites will still be found (keep the site collections in the same web app for continuity) and can have content added (I guess up
to a point - monitor).  Repeat as needed.
Another way I can conceive of is to create a fixed set of a small number of site collections (in the same web app) and manage the Project Site creation manually selecting which
project site goes against which site collection. Division along some logical boundary such as Departments makes sense. But other divisions may be used. This could scale by simply adding more site collections at each department (HR-2), should any given department's
DB grow too big. Then all the logically related Project Sites will hang off the site collection selected and be part of that database for that site collection for that "department" let's say.
just a variation of the above solution.  Monitoring the DB size is key in both cases.
There may of course be caveats to any approach other than OOTB and all in 1 site collection, around navigation, web parts, solution starters, etc...some of which are addressed elsewhere. Of
course, this is admin intensive but retains automatic provisioning for new sites. I believe it would work and meet the requirements for smaller DB's and multiple Site collections for PWA Project Sites and scale to thousands of project sites.
Thanks,
Eric S.
Eric S.