Please enable javascript to view this site properly.

Database Design

The cornerstone of a fast, maintainable and future-proofed system is a well-designed database.

The more a database reflects the real-life information, the better the applications that use it can reflect the real-life processes that act upon it.

Data analysis

Spending time analysing business data, its qualities, limits and how it inter-relates is crucial to designing a quality database.

Space utilisation

While disk space itself isn't much of a limiting factor these days, efficient use of the space a database occupies pays big dividends in both performance and ....multi-userness....

While database systems have become increasingly clever about carrying out their internal housekeeping, intelligently organising the structure of tables allows the database engine to more efficiently manage itself, reducing the need for reorganisation and tidying. This both improves performance and greatly reduces the impact to availability that can result from badly organised data.

Use-specific optimisation

Optimising a database for the specific uses it will be put to is also crucial for performance.

Some systems spend most of their time reading information from the database and little time adding or altering it, such as a document retrieval system. Some are almost entirely in the business of adding bulk data, and only reading it back periodically or occasionally to generate reports or provide extracts for other systems. Some applications constantly read, alter and add data with no predictable pattern.

Optimising the storage strategy, indexing and numerous other factors depending on use-cases can make the difference between an application that screams along and a sluggish thing that users justifiably blame a lack pof productivity on.


Any well-planned system will expand, requiring new business information to be stored and related to the existing data. Looking ahead at possible......

Data integrity

The worst thing an application can do is lose data, just as bad is losing the reletionshiop between items of data. To take the most simple case, it's no good knowing you have 1,000 customers and 10,000 orders if each order can't be mapped to the customer that placed it.

While an application will obviously be written with the express intent of keeping the data and relationships intact, bugs are a reality even with the most comprehensive testing regiman. A well-tooled database simply will not allow an application to leave the data in an invalid state; in the example above, the database should refuse to detach the order from the customer however doggedly the application tries to do so.

Add stuff about....