SQLTeam.com | Weblogs | Forums

Database Design

I usually work with databases that are parent-child relationship (with nested levels). I guess this can be seen as a normalized database. Recently, I have seen databases that are designed a bit different but still pretty effective. There would be hundreds of tables but all tables (the records) are tied together by a designated key (UniqueIdentifier) to all tables. I guess this can be seen as a denormalized database.

For example, lets say we have a patient table that has unique record for each patient. This table drives and ties the rest of the tables with the designated key (UniqueIdentifier) for a patient.

Are there advantages vs disadvantages in this database design compared to the traditional nested parent-child relationship design? One advantage that I see with this design so far is that it is so much easier to track down data. Take the key and do a "WHERE" on a table.

Hmmm... Are my questions related to Normalize vs Denormalize design? Maybe that is what I should google on. Is Denomalize design usually tie by keys? And it makes sense since these database are for reporting tiers

Can you create two or three tables with some sample data in a "classic" normalised data model?
And do the same in the denormalised data model way. It should contain the same information as the normalised tables.

It will be easier for us to understand what you mean.

1 Like

@BabyAqua ,

Rather than it being a form of denormalization, it sounds to me like they may have used a form of normalization the outstrips the 3rd normal form.