At the bottom of your field configuration when you create a new field you have the option to set where in your database you want information that is entered using that field to be stored.
Default storage options
SEBLOD works alongside the Joomla Core Object tables in order to store content. The Joomla Core Objects include Article, Category, User, User Group. When you create a new content type, a new table is created in the database called #__cck_store_form_*content_type_name*. All of your custom fields with default storage are added as columns to this #__cck_store_form table.
When you create a new content item using a custom content type, an entry is made in the associated content object table which then references the appropriate cck_store_form table. Any information entered in to custom fields will be stored in the associated database column of the #__cck_store_form_table. So, for example, if you create a custom content type (called "News") based on the Article Content Object, and you enter a new content item, a new entry will be added to the "#__content" table (which is the Joomla core table for storing Article Object information), and this entry will reference a new entry that will be created in the cck_store_form_news table.
This behaviour is the default behaviour when you create a field within a Content Type using the + button. By default the field is locked exclusively to that content type since the #__cck_store_form table that is created is related exclusively to that content type. However, if you click the "lock" icon - or create your field in the Field Manager - these default settings will be overridden to store your field information in the Joomla Core Object table that relates to your content type. This means that the field can be used in multiple different content types since they all share the Joomla Core Object table in common.
Storage format
The storage format (see image above) determines how the information that is entered in your field is stored in the database.
- Standard storage formatting will store the exact value that is entered in the field directly in the database
- Custom storage formatting will add some SEBLOD-specific tags around the information and store it in the database. This storage formatting is used particularly for Field_X and Group_X storage.
- JSON storage formatting will convert the entered information in to JSON format and store it in the database.
- None - no information will be stored in the database. Useful, for example, on contact forms that trigger an email and you don't want to store the contact form content in the database.
Content Object
The Content Object (see image above) determines which Joomla Core Object table will be used to create the content entry. This can be Article (#__content table), Category (#__categories table), User (#__users table), User Groups (#__usergoups table). As mentioned above, when using default storage options the entry in this Core Object Table will then reference an entry in the #__cck_store_form_content_type_name table which is created when you make your content type.
Database Column
This option determines the column that your field's information will be stored. By default, this field will be populated with the field_name and become a new column in the associate #__cck_store_form table in the database after the field is saved - so you can usually keep this blank. However, if you want your field to store information in an existing field you can click the "«" which will give you a list of existing database table columns to choose from.
Alter
Clicking this checkbox will reveal the additional storage options: Data Type and Add Column To Table.
Data Type
The data type setting lets you chose the storage structure/formatting in the database. This setting will often change by default depending on the type of field you are adding. For example, for a Text field, this is usually Varchar(255). For a Numeric field, it is Int(11). For a Textarea field it is Text. Changing this structure can be useful if you are trying to optimise database storage, particularly when you have a large form with many fields.
Add Column To Table
By changing this option to "Add column to table", an additional column will be added to the associate Joomla Core Object table for your content type, instead of adding it as a new column on the #__cck_store_form_content_type_name table which it usually does by default. If you use this option to Add column to table, your field will be available for use in other content types, not just the one your create it in. In other words, your field will not be "locked" to a single content type.
Let's play!
The best way to understand storage is to see it in action. Let's take a look at a few examples:
We've created a new Content Type called "My Content" (based on the Article Content Object). We've just added the default "Article Title (art_title)" field in the Admin Form View.
Text field with 'Standard' format
Now, we'll create a new text field called "Color" with the default storage. This means the storage will be Standard > Article > color.
Since we have created this field as "locked" in the Admin Form View, the new field is added to the database as a new column in the #__cck_store_form_my_content table.
After everything's saved, we create a new content item :
After we click "save", let's look and see what has happened in the database:
The value of the 'Color' field has correctly been stored in the 'color' column of the content type table (#__cck_store_form_my_content).
Field X field with "Custom" storage
Now we will add a field X field based on the Color field we created previously. As a requirement, Field X fields need custom storage in order to separate the values stored in each instance of the field. So, we set the format as 'Custom' and the column name as 'colors' (instead of 'introtext'). Custom formatting will wrap each stored value in some Custom CCK tags which SEBLOD uses to render the content properly in the front end. This will create a new column in the #__cck_store_form_my_content table for the Field X entries.
We create a new content item (we've removed the single 'Color' from the form as we now want to use the field X field) :
After we click save, let's see what's happened in the database:
A new column 'colors' has been created in the content type table and the different values of the field X have been stored using the Custom format.
Another 'Field X' field...but in the intro text column
Let's add another 'Field X' field but let's keep the 'intro text' column for it:
We create a new content item:
And after it's saved, what happened in the database?
You can see the different values of the "Other colors" field X field have been stored in the 'intro text' column of the '#__content' table (Article Object table - #__content). You'll also notice that the "Other colors" are not the only values stored in this column. The "::cck::7::/cck::" tag at the beginning provides the link to the associated entry in the #__cck_store_form_my_content table.
Reminder: As 'introtext' is an existing column of the article object table (#__content), no matter the status of the lock, the #__content table will be used to store the field value.
A text field using the 'Free' object storage
The "Free" storage means that you can store your field value in any column of any table of your database. This is useful if you need maximum control over where your content is stored.
Requirements: You need at least to have an 'ID' column in your table for SEBLOD to link the field with the content.
Let's add a text field:
With this configuration, the 'your_comment' column will be added to the existing '#__color_comments' table. The format of the field is 'Standard', so the text value will be stored "as it is".
The new content item:
What happened in the database?
The 'Your comment' field value has been stored in the right column in the specified table.
Conclusion
Depending on the combination of the lock icon status, the format and object you choose for your field, you can achieve various and complex database structures for your content types depending on your needs.
Keep in mind how you'll have to process these field values within your searches and/or the way they're going to be accessed by the different templates on your website; 1 column per field (i.e. the "Standard" format) value is perfect for searches, Field X and Group X fields require the "Custom" format and params are better to be stored in JSON format.