Sharepoint Forum

Ask Question   UnAnswered
Home » Forum » Sharepoint       RSS Feeds

Limited number of subsites in a site collection

  Asked By: Madhu    Date: May 12    Category: Sharepoint    Views: 4131

Are there any limit on subsites in a site collection on wss v3?



6 Answers Found

Answer #1    Answered By: Lynsey Carver     Answered On: May 12

See technet.microsoft.com/en-us/library/cc262787.aspx

The guidelines for maintaining acceptable performance are a maximum of 2000
subsites per site, and 250,000 sites per site  collection.

Answer #2    Answered By: Richard Allen     Answered On: May 12

I see we will have a problem with number  of subsites  when time passes. Think
subsites exceeds 2000 over a year. Maybe around 2-3000 subsites. Solution could
be to archive a subsite structure for each year to a yearly sitecollection
archive for each year.

There is a lot of metadata information from lists and document libraries i need
to pull out of these subsites. Seems to me there is no good sharepoint API to do
that.. Maybe the solution would be to use sql server as a help on quicker
pulling of the data? Any thoughts on this?

Answer #3    Answered By: Ian Davis     Answered On: May 12

There is a number  of 3-rd part tools which can move sites (with subsites). You
could look at ControlPoint from Axceler.

Answer #4    Answered By: Jagjit Hui     Answered On: May 12

To the original poster, remember you can have 250,000 sites in a site
collection, as long as you structure them so that no more than about 2000 are
under any parent. So, if you are provisioning them programmatically, you could
create (say) a new sub-site each month off the root and create all new sites
that month as sub-sub-sites off that sub-site.

If you keep the sites in one site  collection, you can use the SharePoint query
API. However, performance could become an issue, and it will become awkward to
use if you archive sites into multiple site collections.

Another possibility is to use the SharePoint search index. You would need to
ensure the search indexer is crawling the content, and configure the metadata as
managed properties. You can then use the API to query the search index instead
of the original data, which is much faster.

A third possibility is to build a custom database for searching, and have custom
components to populate it with the metadata from SharePoint.

A fourth possibility is not recommended and not supported: directly querying the
SharePoint data in SQL Server. Even a read-only query can cause performance
issues for the farm, and Microsoft don't publish the schema so it is subject to
change without notice.

Without knowing more details, I would suggest the second option, using the
SharePoint search engine.

Answer #5    Answered By: Alexia Mccarty     Answered On: May 12

Tx for your possibility proposals. I see i should also give som more information
on this.

We a have static site  structure in wss  with kind of
Customer->Supplier->PurchaseOrder structure. Customer sites will below 10, the
supplier sites below 100 and the purchase order sites should be below 2000 each
year. So a kind of archive function like moving purchase orders to another site
or site collection  dependent of the structure could be the way to go. Maybe
downloading the sites on disk as files could be possible?

Forgot to mention earlier we use wss v3, so the search engine is unfortunately
limited. I mean crawling metadata as managed properties is not supported in wss,
only in moss.

So i am exploring SPSiteDataQuery at the moment(struggling getting data i
want..) Alternative option would be enumerate through spweb.webs.names array
with linq queries to filter supplier/purchase orders subsites  and then go
through lists with metadata for each of the subsites filtered to get information
i want. I am afraid the performance will be too slow. Have to admit i am
disappointed on how sharepoint API expose information from database... I think
solution will end up with managing extra helper tables in sql server to search
faster in the structure.

Answer #6    Answered By: Laquita Mcgowan     Answered On: May 12

Even with WSS, you could use Search Server Express to get MOSS-like search
features such as managed properties. However, I think maintaining your own SQL
indexes sounds like it will be the best approach.

If you keep the purchase orders in a sub-site per year, you will avoid any
immediate requirement to archive, although you will still need to at some point
for general performance and database size reasons.

Didn't find what you were looking for? Find more on Limited number of subsites in a site collection Or get search suggestion and latest updates.