Problems with modern database design

Number of tables

The sheer number of tables required is staggering. Each entity type requires a table, more to hold many to many relationships, lookup tables, system data and caches.

Each table requires feeds and/or screens to add data, more code to add integrity rules, more code to report on the data and then more to search the data. A huge amount of code and more code means more errors.

Time

It takes a long time and skilled resources to get a system into place. This costs money and frustrates end users. The requirement has likely changed by the time the system is ready.

Change

It gets worse when you concider the changing environment a database is supposed to model. Traditional relational database applications are difficult to alter once in place. If the system uses raw SQL embedded in the application code then any change becomes a nightmare.

The simplest soloution is to try and squeeze new functionality into existing structures but this leads to a slow rotting of the database design over time. The original developers may have understood the data in every table but they will move on and their replacements won't want to make any changes in the system they inherit.

Data is not equal

It costs time and money to provide easy access to data so the only certain aspects of the data get nice screens and search facilities. Other data might get accessed by less featured screens or perhaps only through SQL. This lack of consistancy is frustrating to end users.

Data isolation

Even if all the above is dealt with then the data in the database is still isolated from other data on other heterogeneous systems - can you easily combine the data in an Oracle database with the data held in a Sybase database. The potential synergy of all the data held within a company is lost if there is no way of collectively accessing the data.

The solution

get rid of all the code!

Index   Close