Unstructured data is fine for small sites, but when you have a site that is growing, it is worth investing some time in structuring your data. Structuring data is all about separating the storage of information from its display.
There are lots of advantages in using structured data. Some will be immediately apparent as you create the site, whilst others will come in to play later on in the lifecycle of the site – as you need to make changes, and find they are easier than you might have expected.
neatComponents removes the need for you to have specialist database knowledge or experience - but you do need to know something about how best to handle data to get the best out of the system. We recommend reading a very basic guide to introduce you to the concepts as painlessly as possible, such as:
Access for Dummies
nC doesn't actually use MS Access but if you are new to the whole database 'thing' the first few chapters of this guide will help you get your head around the best way to think about your website's structure. Remember: nC will be handling all the difficult stuff for you. There is no code to write or debug - no programming to do.
Before delving in to the detail, let's take a simple case study to illustrate the difference between unstructured and structured data techniques:
Case Study
The requirement is for a site that lists plants in a garden.
The unstructured method is quite straightforward: there is a page, into which the plant names are entered, one per line. In fact, since there are quite a lot of plants, they are entered on several pages: one for shrubs, one for trees, etc.
The structured method separates out the display of the information from its storage. The information is stored in one place, then queried and displayed elsewhere on the site. So, to store the information, there is a Form filled in for each plant, with fields for its Common name, Type (tree, shrub, etc), Latin name, and further fields for Flower color, Month of flowering, Hardiness zone. Not all plants need have information in all the fields.
Initially, we can display the information in exactly the same way as for the unstructured site, with one page for trees, and one for shrubs. Indeed, from the perspective of a visitor to the site, they would not been able to tell which method was used.
However, our gardener has the immediate benefit that they can edit the details easier, using a user-friendly form rather than having to open a large page just to make a minor change.
The structured method also helps out in getting the display just right: it's likely the list will be wanted in alphabetical order, and the system can take care of that automatically. And if the list is rather long, it can divide up the list into several sub-pages, and provide 'paging' between them (eg "Showing page 1 of 5") without you having to create extra pages or do anything.
In fact, that's just the start of what you can do: for you might want to provide a search function to allow visitors to find a particular plant, or plants matching certain criteria: (Blue flowers in May). Again, the system can work with your structured data to add this functionality in a matter of moments: showing a search form with fields specific to your data, and then showing a summary of results, which can link through to detailed information.
Since the display is managed separately from the data being stored, when you want to change the styling used, you can make a single change and have it affect all the items (say, changing the font used for the plant name), whereas with unstructured data you would have had to manually edit each plant on each page – tedious.
And likewise, if the data changes (adding a new plant), you don't need to worry about it being displayed in exactly the right place, in the right fonts. In fact, the whole structure could change (say, the addition of a new field for plant height) and your existing work, plant details and all, are kept, and the new details displayed where you want them (just as soon as you get round to filling in the height details for the existing plant records).
The example above barely scratches the surface of the benefits of using structured data in your sites. Here are some others:
- Allowing some users to modify the data, but not to affect the display fonts etc
- Managing the validity of data by providing input choices rather than just free-text input
- Allowing content approval flows to approve data that has been entered before displaying it on the site
- Emailing people to inform them of new content
- Showing the same information in different places – and keeping it all synchronised
- Providing search tools to allow users to find information quickly
When you extend your site structure to include more than one Table, you can link them together to provide automatic cross-referencing of the information contained within them, which can provide major efficiencies as you leverage your data for display in many different places.
It is always worth considering how your site may grow over time: what may seem a simple site right now may become much larger over the months, so you may want to invest some time designing it using structured data right from the start. And it doesn't matter if the structure changes over time - the system will work with you to make modifications to the structure without you loosing the work and data already entered.
In neatComponents there is a concept of data flowing from its initial input into the site, being stored, queried, and displayed. Read more
