Re: Design question : Normalize or Not to normalize ?

I will do the due diligent that the I/O verses the storage space. In some cases even a redundancy may help me in the overall performance.

Yes, if you ask academic, his answer will be Normalize it to maximum but working daily in the pits with Developers I know and feel your concern, I will go and add the name in the table instead of making an i/o. but check the overall impact on the application, How it will be added /update in the file.

Do the due diligent.

Good Luck.

Nisar Tareen

andrewst_at_onetel.com (Tony) wrote in message news:<ed8a00fa.0410130647.8f52ee3_at_posting.google.com>...
> krislioe_at_gmail.com (xtanto) wrote in message news:<e1c9bd55.0410130133.76fb0378_at_posting.google.com>...
> > Hi gurus,
> >
> > In our custom HR application, the employee master table has about 3,8
> > million rows. Many transactions table has FK referring to the Big
> > master table.
> > (attached is the script sample)
> > Question :
> > Since the master table is big enough, should I still normalize here ?
> > Means I have to JOIN to employee table to get the ENAME with the risk
> > of slow join to big reference table ??
> > Or this is the case where we should sacrifice normalization for
> > performance?
>
> Normalise and do the join. It doesn't matter if EMP contains 3.8
> million rows or 38 rows, the primary key index on emp(empno) will get
> you the names blindingly fast.
Received on Wed Oct 13 2004 - 15:41:05 CDT