I am running a very old db2 database on an IBM iSeries system and am looking to redesign the entire applications in Java and the database in the latest DB2 version.

The current DB is divided into tons of header and detail tables. I have seen recent publications where it seems that the practice now is NOT to split you data into header or details tables.

I just want to do a sanity check to see if that is actually the bet way to go on a new design. Any feedback appreciated.

Thanks

Personally, I prefer to use header and detail tables. I have not seen these recent publications, so I do not know their justification for denormalization. To me, normalization just makes sense. It will take up less space. It can be faster, especially when you just need the data in the header table. It also help prevent data corruption when "header" data on denormalized tables is changed on one row but not others. Then there is when you have to change "header" data, you then have to change it on all rows in the denormalized table instead of just one row in a normalized header table.

HTH

Andy

You need to give an example of what you mean.

What do you mean by "header and detail tables" I am not familiar with these terms in the context of database design.

They are used in User Interface context: like header is a 'person', and detail contains zero, one or more of his 'known addresses', past or present.

In a database environment this header-detail concept is one a one-to-one basis translated in two tables: one for the PERSON and one for the ADDRESS. An address in the ADDRESS table will contain a refecence to the record of person 'John' in the PERSON table. This is called a parent-child relationship: the child record (ADDRESS) has a references to the parent record (PERSON).

Is this what you meant ? If it is, leave it as it is. You will get yourself into mayor trouble if you would change it. It is called "normalisation". I guess you know what it is, but if you don't, read a book or take a course about database design, it is not complicated, but it is a basic skill you need to have if you want to do anything serious on a database.

What you may have read is that in data warehouses, for ease of use and reasons of speed, all this information is denormalised into one big table. It is usefull if you want to make reports, based on this, but it is not meant to be used to add/alter/delete data like in a production environment.