Organisations are typically arranged around an institutional memory. Increasingly, this is one or more databases. Unfortunately, database design is poorly understood and errors in design propagate to every piece of software which depends upon the database.

As an example, a book catalogue typically uses ISBN as the primary index key. ISBN is typically used with its own base 11 checksum (or is used within "Bookland" bar-codes with its own base 10 checksum). Poor choice of index key may result in one or other checksum being redundantly incorporated into the primary key. In the worst case, a database may be significantly bloated by the redundant use of a text representation. This is for the ISBNs which end with X. Unfortunately, this is not a hypothetical example and it demonstrates that something a simple as a product code may have grossly wrong representation within a database.

In another example, a major courier is very good with numbering nouns but is exceptionally poor with numbering verbs. Parcels are specified as a composite of franchisee, client, consignment and parcel. Employees and trucks are similarly numbered. However, routes, loads and cages of parcels to the same destination are not numbered or handled graciously. This has resulted in operational inefficiencies such that the courier incredulously swapped headquarters with another courier company. At the larger headquarters, trucks with parcels headed to one franchisee are entirely emptied, the parcels are placed on conveyor belts, manually sorted (with significant errors) and then re-loaded onto other trucks. The mis-directed parcels cause permanent loss of customers. This expensive, daily farce occurs due to poor database design.

At scale, good database design allows significant operational savings to the extent that it may be possible to run a larger business from smaller premises. At smaller scale, we aim to save you at least £200,000 within the first 90 days at the very reasonable consulting rate of £1800 per day.