sometimes if you have to use join to combine two or more columes, you can move one not frequently changed column to another table to decrease or eliminate join. this improve proformance. but you should be careful.
suppose you have devloped a library mamnagement system
with the folowing tables which are normlaized.with the folowing relations,
member can borrow many books and books can be borrowed by many members additionaly a book belongs to a particular subject (hope this is plain english)
if you want to know which members has borrowed which books on which subjects you have to do a 4 table join.which should look something like this
select distinct a.name,d.desc
from membes a,borrow b,books c,subjects d
ah now thats quite a gew joins isnt it ?
now how about breaking some rules of normalization or denormalizing as u call it.
lets change the dat model so that subject table is eliminated .
so we are left with the following tables
in order to answer our previous question of you want to know which members has borrowed which books on which subjects
we would have to write
select distinct a.name,c.subject
from members a,borrow b,books v
you can get an answer in just 3 table join.
isin that great :-)
be warned denormalization has got its cost in case of real applications like the one i work upon i would probably ahve to code additional database triggers if i dont normalize to maintain refrential integrity.
A simple example is the zip code/state and city relationship. Rarely do you see tables where an address is stored with just a street, number and zip, and then a lookup table with city/state. However, you can determine the city/state from the zip. It's just easier to record it every time, and most people denormalize to avoid the operational, programmatic and database complexity and maintenance headaches of normalizing this relationship.