Is this really the version you are looking for? Kentico Xperience 12 Service Pack Documentation is no longer updated. Use the switcher in the header to choose your product version.
Kentico offers multiple ways to store and organize your website's content. This page describes each approach in detail and lists their advantages and disadvantages.
You can store content:
As pages – using a hierarchical structure visualized as the content tree of the Pages application.
In module classes – suitable for storing large amounts of data and custom module related data.
In custom tables – suitable for storing large amounts of data in a flat structure.
In media libraries – suitable for storing large files, not exclusively of media character, such as videos, high resolution images or packaged files.
Use pages as a content storage when you need:
Pages are stored in a content tree. On Portal Engine sites, the content tree also defines the navigation and site map of the website.
On MVC sites, the content tree holds the page data, and the structure and navigation of the website is defined by the code of the MVC live site application.
Note: The limitations largely depend on the overall configuration of the system.
When you plan on storing and creating a large number of pages, consider structuring the content tree into smaller segments. This can help you avoid reaching the recommended limit of 1000 child pages under a single page. For example, articles can be structured based on the day they were created on.
If you plan on segmenting an even larger amount of content, you can structure the content tree even further. However, note that the 'Alias path' for each item in the content tree cannot exceed 450 characters in length. See limitations of using pages for storing content for more information.
Note: While this helps you structure content so that you do not exceed the recommended 1000 child pages limitation, the total number of pages in the system will increase. Consider the recommended maximum number of pages in the system as well.
Optimizing performance for very large Portal Engine sites
See Optimizing performance of Portal Engine sites for information on how to resolve issues with website performance. One approach for reducing the amount of pages stored in the content tree is setting up archival for outdated pages.
While all items in the content tree of the Pages application are pages, there are several kinds of pages that you can distinguish. The options depend on the development model that you use to build your website.
On MVC sites, the following general types of pages are available:
If you need help when deciding between page builder and structured pages, visit Choosing the format of page content to learn how to choose the more suitable approach.
On Portal Engine sites, the following general types of pages are available:
The following table compares both approaches to content storage on Portal Engine sites:
Editable regions | Form tab | |
|---|---|---|
Content structure | Simple content structure. | Complex content structures, typed data, such as text, date-time, numbers, etc. |
Validation | Only basic validation rules for minimum and maximum length. | Complex validation rules, including regular expressions and custom form controls with custom validation code. |
Display | The content is displayed in the context of the page providing truly WYSIWYG editing. | The content is displayed by controls or web parts using transformations. |
Storage | The content is stored in a single XML document in the page data. | The content is stored in a separate database table. Each field has its own column. The data can be easily modified using SQL queries or API. |
Examples of use | Home page, "Contact Us" page. Generally: pages with simply structured or unstructured content. Editable regions are usually used only in connection with pages of type Page (menu item). | News, product specification, event details, job opening, anything that requires different, more complex fields for its content. Generally: pages with structured content where you need to separate content from design and keep the content in its original data type. The form-based content is usually used in connection with pages of type News, Product, Article, etc. |
Custom module classes allow you to store large amounts of content without the hierarchy provided by the pages. Use module classes when you need to:
Scenario
One specific scenario in which you can utilize module classes as a content storage is for page archival. That is, storing outdated pages that you don't need to display on the live site anymore. You are still able to access the page data but you don't have to clutter the content tree with unnecessary items.
Limitations of using module classes for storing content
Please be aware of the following limitations when deciding whether to use modules for storing content:
Custom tables allow you to store large amounts of content without the hierarchy provided by pages. Use custom tables when you need to:
Limitations of using custom tables for storing content
Custom tables also pose certain limitations. Consider using custom tables for storing content if you don't need to:
Pages | Module classes | Custom tables | |
|---|---|---|---|
Can hold traditional data types (int, float, ...) | |||
Can hold binary stream data (files) | |||
Can hold one-to-many data (radio buttons, drop-down lists) | |||
Can be used as an E-commerce product | |||
Can be displayed by 'Listings' web parts | |||
Can be displayed by 'Navigation' web parts | |||
Workflow | |||
Versioning | |||
Multilingual content | * | * | |
Hierarchical data structure | |||
Each record has its own URL | ** | ||
Data can be accessed using API | |||
Importable / Exportable | |||
Performance | |||
Recommended for large data sets when using flat data structure | |||
Number of database tables that store the data | 3+ | 1 | 1 |
Recommended for large binary data | |||
Binary data can be stored in file system | |||
*You can translate data using localization macros only.
**You can access custom table records via listing web parts and query string URL parameters.
Media libraries are designed to store large files – not exclusively of media character – such as videos, high-res images or packaged files. You can access media library files without overhead as there is no need to query the database to access them.
Pages | Media libraries | |
|---|---|---|
Recommended for large binary data | ||
Direct access to the data without querying database | ||
Number of database tables that store the data | 3+ | 2 |
Binary data can be stored in file system |