The system provides an extremely flexible solution for you data structures. This document explores some of the choices available, and the issues that you need to consider.

A simple list

The simplest solution is to have a single Form, called, say, 'Product', in which each product is described one per record.

This works well for very small numbers of products

Introducing categories

Where there are more products, you will want to introduce categorisation. You provide a separate Form, called, say 'Category', and then provide a Record Link field on the Product form to allow you to place each product in a category.

You then create an interface that allows the visitor to browse through the categories, seeing lists of products, and then open a page on the particular product.

Multiple category membership

If you have products which can be in several categories at the same time, you can use a Multi-Record Link field, to allow relationships to be described.

You have the option of placing this field in the Category form, or in the Product form. This choice will depend on how you envisage the catalog being managed, but will have no effect of the final functionality or appearance.

Product options

In some cases you need to offer options (size, color, etc) for a given product. The main issue to consider here is whether the options are in effect creating a collection of separate (albeit similar) products, or whether you want to consider it simply as a single product.

Factors which will need to be considered (and would lead towards you treating each option as a separate product) include:

• Price variation between options
• The need for individual stock control of options
• A non-complete options matrix (ie, if various sizes and colors are offered, when not all colors are available in all sizes)

These factors should be considered not only for the current site's needs, but also whether they might become requirements in future.

The outcome may be that what the site owner considers to be a product is in reality more like a category, with the options forming the true products within it.

Minimising administration

In many scenarios, all the information needed for the e-commerce system to be able to add an item to the cart is described within the Product form (with other forms, providing categorisation, simply being used to guide the visitor to the correct product page)

However, if say all products with a category will always have the same price as each other, then it would be sensible to move the Price field into the Category form, and then use a Query join to make the Price field available to the Sale View. This technique can be used with any aspect – not just the price – where aspects will always be in common.

Do be aware that whilst this will save time for the site administrator, it will impose a restriction on future flexibility for them, so this should be clearly understood and documented.