Planning Your Data Structure

   —   

Data is at the core of every site and deciding on its structure often is the driving factor when architecting a solution. Choosing a model that is open to integration, allows for flexibility, and, above all, is easy to manage is critical for a successful application. Kentico allows data to be structured in a number of ways to fit nearly every project requirement. In this article, I will discuss the different ways data can be stored and managed within an application and provide guidance as to when to use each option.

Overview

Providing solid content management is essential to a CMS. Every site is different and content can vary greatly from one project to the next. For this reason, Kentico has a number of options available for managing your data. These options are Pages, Custom Tables, and Custom Classes. Below, I will break down each option, explain their advantages and limitations, and explain when each option makes the most sense.

The Kentico Documentation has a breakdown of each data storage option here.

Pages

PagesPages are one of the most capable and flexible methods of data storage within Kentico. Based on an underlying SQL table, Page Types are extremely customizable and their content is entered through the Content Application within the Admin area of the site. Each field of the table can be configured to a specific data type and the editing form can leverage built-in validation to ensure the values are correct. Along with the simplest method of management, Page Types can also leverage Workflows, Versioning, Staging, and other advanced content management capabilities, making this an ideal choice for many projects.

Pros

  • Easy to enter content
  • Easy to manage content structure using Content Tree UI
  • Supports Workflows
  • Support Versioning
  • Support Permissions
  • Support complex data structures/types
  • Support binary streams
  • Support multilingual capabilities
  • Support accessing content via API
  • Easy to format data using transformations
  • Importable/Exportable
  • Each element can have a unique URL

Cons

  • Larger data sets may complicate Content Tree structure
  • Loading too many objects into the Content Tree may impact on performance
  • Requires three tables within the database to store the data. This may impact on database sizes and data retrieval

Custom Tables

Custom TablesCustom Tables are a great alternative for flat data within your site. They offer a Portal UI for managing your content, with import and export capabilities. While not as functional as Page Types in regards to Workflow and Versioning, Custom Tables do offer API access, can handle large amounts of data easily, and have the ability to display their content using standard Kentico web parts.

Pros

  • Support large amounts of data without performance implications
  • Support complex data structures / types
  • Support accessing content via API
  • Easy to format data using transformations
  • Importable / Exportable
  • Simplified data storage (1 table)

Cons

  • Do not support Workflow
  • Do not support Versioning
  • Do not support binary streams
  • Multilingual support requires localization macros
  • Content is managed via Portal UI using standard UniGrids (rather than visually in Content Tree)
  • Data is not directly accessible via URL

Custom Classes

Custom ClassesAnother option in data storage is the use of Custom Classes. These repositories can be created in a custom module, or within an existing module.  With a custom class, you can define your structure, much like Page Types and Custom Tables, however, you can easily integrate the data with other repositories within the system.  Additionally, you can use the Generate Code functionality to create a provider for all of your custom functionality when interacting with the data.

Pros

  • Support complex data structures / types
  • Handle large amounts of data
  • Support relating data to other objects / types
  • Support a custom provider for all functionality
  • Simplified data storage (1 table)
  • Support accessing content via API

Cons

  • Require additional configuration / association with a module
  • Exporting data will require specific settings / configurations
  • Content is managed via Portal UI using standard UniGrids (rather than visually in Content Tree)
  • Data is not directly accessible via URL
  • Do not supports Workflow
  • Do not support Versioning

When to choose which option

When to ChooseNow that you have understanding of each option, the next question is when to use each one. The data you are storing and how you want to manage it will largely dictate which option would be best. Typically, Page Types are a good starting point because of all of the functionality they come with. I will often use Custom Tables for “one-off” data that isn’t related to anything else, but still needs to be managed within the system. I will use Custom Classes when I need to manage data related to a specific module or feature. Below are a number of suggestions for storing data for each option.

Pages

  • Standard content
    This refers to any content you want searchable by your users and displayed on the site. All of your standard content pages fit into this category.
  • Product data
    Product data can be entered as a Page and given a unique URL. This improves SEO and allows content to be categorized / managed easily.
  • Blog posts
    Blog posts are a great fit for Pages by allowing editors to enter them easily and arrange them by month.
  • Office locations / Locations
    Any type of content that you want displayed fits well with Pages. Office locations for a Contact page are a great use of this type of content.

Custom Tables

  • Non-content data
    This refers to data you need to manage within your site, but not necessarily display on the live site. Examples of this might be:
    • Office codes for an internal application
    • Employee titles
  • Option values for other types of data
    Often, Pages have multiple fields, with their values being derived from a list of values. Custom tables are great for maintaining these supporting values in a portal-managed environment. Examples of this data may be:
    • Colors for a pre-defined color picker
    • Office types for Office Content Pages
    • Age ranges for a drop down
    • Color selectors
    • Preferred genre selection
  • Any kind of data you want to manage within your site
    This refers to any other types of data you want to store in your site and use Kentico to edit. The Portal UI provides a straight-forward interface for updating the values.

Custom Classes

  • Any data related to a specific module
    This refers to data associated with a particular model. This may be supporting data for the module, or related data. Examples may be:
    • Custom product data
    • Extended User settings
    • Custom Shipping carrier fields

Wrapping Up

Kentico provides a number of ways to store your data, each with their unique pros and cons. Deciding on which option to use will come down to how you want to manage the data. Being able to export the data quickly and easily may be essential for your business and knowing your options is key. Good luck!

Share this article on   LinkedIn

Bryan Soltis

Hello. I am a Technical Evangelist here at Kentico and will be helping the technical community by providing guidance and best practices for all areas of the product. I might also do some karaoke. We'll see how the night goes...

Comments