Best practises note that you should not exceed 100GB per content database. What happens if you have an organisation (large global) that has more than that amount of data and they would like to make use of the aggregation (CQWP) functionality to build content relevant dashboards? **With the understanding that aggregation is difficult when there are multiple site collections. Is search the only route that can be followed or should you bypass the best practise of content and store more than 100GB in 1 content database (1 site collection)? Alternatively, should one look into a technology such as StoragePoint to limit the content stored in the actual DB, thus taking advantage of the aggregation ability with 1 site collection?http://technicallead.wordpress.com/

This is always a hotly debated topic in the SharePoint world. The RECOMMENDATIONS that are best practices are there for good reason. Data backups on the SQL backend and storage becomes harder and harder, the more the database size grows. No dashboard is ever going to rollup 100 GB worth of data or anywhere near that. The question that the SharePoint Architect should be asking is why the data can NOT be broken into more site collections. There is surely some kind of attribute or denominator that can be used to break content down into multiple site collections. If the content is being kept together simply because of aggregation reasons, then I would consider the use of the Data View Web Part and it's ability to rollup content from anywhere. You could have a couple of those on a single page, each rolling up content from a given site collection. As a result, your databases are smaller and more manageable but you still have the rollup information displayed on a single page. Start here: http://www.endusersharepoint.com/2009/11/13/how-to-create-a-sharepoint-data-view-web-part-%E2%80%9Crollup%E2%80%9D-screencast/ I trust that answers your question... Thanks C http://www.cjvandyk.com/blog