Sharepoint Forum

Ask Question   UnAnswered
Home » Forum » Sharepoint       RSS Feeds

Content Database Options

  Asked By: Raymond    Date: Mar 29    Category: Sharepoint    Views: 1592

We are going to be installing a portal with 3 top-level sites. These 3 sites will end up being extremely large sites with many documents and workspaces. I'm most concerned with running out of disk space in the future especially if people start using versioning.

As I understand it, a top-level site is created in one content database and all of it's subsites and documents are stored there as well. So in the future if my disk begins to fill up, is there anyway to break up this content database into separate ones? Or would I just have to move the database files to a new larger disk?

The other question, is if there is a way to assign a top-level site to be created in a particular database?

Ideally in my world I'd like 4 separate content databases - 1 for the portal stuff (mysites, etc.) and the 3 top-level sites would have their own content databases.



1 Answer Found

Answer #1    Answered By: Jake Harvey     Answered On: Mar 29

Using SharePoint Central Administration to create a Windows SharePoint
Services Top-Level site  (let's call it an Extra-portal Site Collection)
allows the creator to choose what database  the content  will live in.
Creating a Windows SharePoint Services Top-Level Site (embedded Site
Collection) from a SharePoint portal  Server will automatically reside in the
portal's database.

In fact, I think there are _at least_ four very compelling reasons to
primarily create Extra-portal Site Collections:
1. DATABASE INDEPENDENCE: Extra-portal Site Collections can live in a
separate database. This can be very useful for backup and recovery,
transaction isolation, geographical distributed sites  close to their users
but still indexed by the Enterprise Portal, database server scalability,
2. URL INDEPENDENCE: The creator can choose to use the same domain as the
portal plus a chosen wildcard included virtual directory or choose a unique
URL or both, include a separate  SSL URL or not, etc.
3. SECURITY INDEPENDENCE: Extra-portal Site Collections can optionally be
run under a unique virtual directory (IIS Web Site independence) and
therefore use a different Application Pool Identity than the portal or not.
Running under a different security content could prove to be very useful.
All Virtual Server configuration can also be done independent of the portal.
4. ANONYMOUS ACCESS: The first step to setting up anonymous access is to
enable it in IIS. If you are using embedded Site Collections then you must
enable anonymous access for the entire Portal and all other embedded Site
Collections. If you are using Extra-portal Site Collections you can turn it
on for some and leave it off for others.

The only cons to creating Extra-portal Site Collections that I am aware of
1. NO AUTO-SEARCH SETUP: Search does not automatically index Extra-portal
Site Collection content as portal content. A separate content source must be
created for each Extra-portal Site Collection provisioned. That may not be
all bad because Search isn't indexing any content that it isn't explicitly
configured to index. Lots of stuff  can creep into Windows SharePoint
Services Sites that the enterprise may not want to index.

Portal Listing to Extra-portal Site Collections can be created  and they, in
turn, can link "Up to" the portal.

I typically recommend that people  use Windows SharePoint Services for
everything unless SharePoint Portal Server is absolutely mandated. What
follows is my thumbnail list of reasons that I think compel people to use
SharePoint Portal Server listed more or less in the order that people seem
to rank them:
-Enterprise Search (vs. Site search)
-My Site
-Areas can be hierarchically moved around whereas WSS Sites are fixed
-Areas can have Web Parts that reflect an Audience
-Areas can be set to expire at a given date (and other metadata)
-Multiple Areas can display the same content
-Listings (super links with metadata like expire date)
-Some unique Web Parts (Links for You, News for You, Sites I've Created,
-Areas generate dynamic Top and Left nav base on Area hierarchy (most
people don't like this "feature") vs. the WSS Quick Launch bar (it too is
limited in usefulness)
-Topic assistant

Basically, people would go to their SharePoint portal for the same reason
that they go to an Internet search engine, not to find information on the
portal but to locate information that the portal can point them to.:
1. To search for content that they aren't sure where to find 2. To browse
for content that they aren't sure where to find

I like to say, people don't typically go to Google to see what Google
contains, people go to Google to find other sites to visit that contain what
they are looking for. Google is just the doorway to information, not the

STYLE INDEPENDENCE (more relevant on why to use a Site over an Area): Sites
can be templated, styled, and can generally adopt to any look and feel that
a company desires. SharePoint Portal Server and Areas cannot or at least not
nearly as easily. There isn't anything that FrontPage can't do with a Site
but FrontPage has real trouble with Areas (at least in V2). WSS Site and
List templates typically share the same Site Definition making them
relatively easy to share, each Area has its own Site Definition and
therefore makes sharing solutions difficult.

Didn't find what you were looking for? Find more on Content Database Options Or get search suggestion and latest updates.