QuickStart: Deciding what Data Goes Where

One of the biggest factors in a successful Sitecore implementation is determining where data is stored.

These storage locations can be grouped into four types:

a) Sitecore Content Tree
b) Local Data Sources
c) Enterprise Data Sources
d) External Data Sources

The initial tendancy is to place everything in the content tree especially if you are not working with Enterprise Data Sources or External Data Sources.


What To Store In The Content Tree
---------------------------------

The Sitecore Content Tree is a good place to store data that is easily placed in a hierarchy of 1 to 1 or 1 to many item relationships.
It is NOT good at storing data that is tightly related to many other items.  It is also not as great a storing large volumes of direct children unless you take

advantage of such modules as Item Buckets.

The key question to ask when considering placing content in the content tree or media library is:

* Is this content only used by Sitecore or is it used by another application such as CRM, SAP, Sharepoint or some other system?
If this content is only used by sitecore in most cases this data should live in the Sitecore Content Tree, or Media Library.
There are some exceptions such as User Management/Security which may be only used by Sitecore but does not make sense to be in the content tree or media

library.  User Management is discussed in another Blog Article.

* Does this content need to be editable by content editors or is the data edited in external systems or only by users of the website?
If content editors will not be editing this content then the additional overhead would not necessarily be worth it and you are probably better served storing
it in the external system, additional SQL Server database tables, or in another data source.

* Other than for reporting, is this data read by any other website components?
If the data is only being collected by sitecore and then displayed in a report or used by the rules engine, you don't really need to store it in the content

tree.  Storing it in an external table would allow data to be queried more easily for reports or dumped to external reporting applications.

Here are some examples of data to store in the Content Tree:


* Page Hierarchy: By this I mean the website root node and all the pages used to build your navigation.  It makes sense to store this as it helps
  structure your content.

* Static Page Content: This is content related directly to a page.  It may be as simple as a title and a description and whether it is included in sub navigation.

* Resource Strings: These are all the field labels, static descriptions, help messages that are straight text with no formatting.

* General Site Settings: These are settings either related to the entire sitecore instance or per site. These are specifically setting that need to be edited by the

end user.  These settings are instance-wide and do not change often then you would want to place these in the .config files.
 
* Media Items such as images, PDF, Word Documents, PowerPoints, etc should be stored in the media library.

* Semi-static lookup lists.  This includes country lists, departments, regions, currencies, etc.

* Generic content items:  These are content items that will be updated, possibly need approval and then get published.  They can be shared across many pages.
An example would be a an article.  It may exist in an article page, but also be featured on a front page, or in a content rotator.  This single piece of

content would have all the information in one place and be referenced on the multiple pages.


Some examples of what NOT To Store in The Content Tree
------------------------------------------------------

* User Information such as logins, roles etc.

* Reporting Data and Logs are best stored in a local data source as this data will be written once and then reported on.  End users will NOT be editing this data.

* Product lists, e-commerce purchase transactions.



In an external database directly accessed via the Sitecore Web Application (three-tiered of course).  This would also include any imports and extracts
c) Cloud/external data sources (eg. via web services, Sitecore Connectors, etc)