DB Design

The generic design for an information management system is throwing up a number of surprises. The idea is very simple, all data are to be stored in a hand full of tables with a few columns tracking what type of information the record contains.

This gives many advantages in data handling. Back up, storage, transmission, exchange of information become easier and more efficient.

Client applications can have a neat, small API to send data to be stored in the database. Providing rich client experience and applicaion extension possibilities are limitless with this design.

The flip side is the size of the tables (no of rows might become unmanageable) even in a medium sized application. Data access and integrity checks migh bog down the database engine to a crawl.

To cover this point, we are planning to create report tables which will get updated by triggers as the data is filled in into the underlying tables.

Reducing each set of data in a more traditional db design to this schema is a problem to solve and the solution unravels rather beautifully. If we pull up the necessary energy and implement the whole thing fast, we can see how it measures up in real world usage.

We are planning to release it as a open concept.