Where data can be represented by one long list of records, it can be often be represented in a database by a single database table.

But a truer picture of the real world involves "normalising" data, and breaking it up into several tables. This increases complexity but can make management easier.

The argument for "normalisation" goes like this: let's imagine you have a database of used cars for sale. You might be tempted to enter the year of manufacture, the manufacturer, model, colour, condition and price all as text fields on each database record. What then happens when you want to search for cars with a particular brand? or a car with a certain colour that is newer than a certain year? 

This problem is very hard to solve if you have one table of all-text records; but you need to normalise your data: separate years, manufacturers, models, even colours and conditions into separate tables. This makes the data cleaner, easier to maintain, and is essential for making user-friendly search interfaces.

Space doesn't permit me to go much further into relational database design here. But it suffices to say that it's generally worth putting a little thought into the design of the online database before plunging in for the quickest implementation. The requirement should be discussed with a database designer, and an accurate model of the data should be developed.

Our team built the International Camellia Register for the ICS.

This has a back-end administration area in which over 20,000 species of camellia flowers are managed,  many with images.

The visitor interface has a simple, fast search, with the ability to filter results. A user can click through a result to see the full information.

The full view pages are also merged into the site's sitemap.xml file, so that the  results can be easily found on search engines, and sites like Google Images.