Re: Abnormal Normalization?

From: tina (nospam_at_address.com)
Date: 05/25/04 

Date: Tue, 25 May 2004 04:25:37 GMT

well, if a person can fill multiple roles in the data you're storing, i can
see a reason to have a separate "person" table. and storing honorifics in a
table as opposed to using a value list in the RowSources of combo boxes, i
do that myself - for several reasons. you could apply the same reasons to
justify a separate supporting table (i hate to call them lookup tables) for
the suffixes.
but the first/middle and last name separations? yeah, i think you're going a
little table-crazy there. <g>
and the addresses bit? i'm not even going to touch that one! but i have to
admit the idea of an employee also being a contact (which i've always used
with the connotation of an entity *outside* my customer's organization), and
the idea of an employee having the same address as a client, or a job
site....all this makes me wonder what-in-the-heck kind of business this
database will be used in! <big g>

"Brian Kastel" <be-ar-eye-ay-en--kay-ay-ess-tee-ee-ell@tampabay.rr.com>
wrote in message news:k1xsc.25753$Ol3.19925@twister.tampabay.rr.com...
> I took people's names out of my Employees and Contacts tables, and created
a
> Names table with the PK linked to a FK in each of the two original tables.
> I did this because sometimes the employee could also be the contact, or
> vice-versa. But I didn't stop there. I created four tables; one for name
> prefixes (Mr., Ms., etc.), one for name suffixes (Esq., Ph.D., etc.), one
> for forenames (for first and middle names), and one for surnames. So now
I
> have nothing in the Names table except for its own PK and the five FKs
> linking with the simple tables (First and Middle names both being linked
to
> the Forenames table). I know this is decidedly 3NF, but does anyone think
> that I am overdoing it?
>
> The madness doesn't end there, either. Employees, Contacts, Job Sites,
and
> Clients can all share one address. Of course, I now have one Addresses
> table linked to those four, but I found I had to assign each address a
> "title" to allow for practical selection of the address from a list or
> combo. Again, am I overdoing it? Laziness prompted me to create this
> structure: since I would be the one doing the data entry, I simply didn't
> want to enter data more than once, ever.
>
>

Relevant Pages

  • Re: Still Struggling...
    ... In my opinion it should be in separate tables regardless. ... Then you would use DeptID and SubjectID as foreign keys in other tables. ... in the employee table and live with a few empty address fields. ... that will basically just be "lookup" tables. ...
    (microsoft.public.access.gettingstarted)
  • Re: Still Struggling...
    ... don't understand how I would be entering the same information again and ... In my opinion it should be in separate tables regardless. ... in the employee table and live with a few empty address fields. ...
    (microsoft.public.access.gettingstarted)
  • Re: How quickly we forget Delgados shortcomings
    ... There are perfectly legitimate business reasons for ... > monitoring employee phone calls. ... writings and business activities as well as group ... >>Actually, the way the contracts are written, they have cart blanche to ...
    (alt.sports.baseball.ny-mets)
  • Re: Still Struggling...
    ... Employee ID- Auto number Long Integer ... but the school data belongs in a separate table/tables. ... address or emergency info. ...
    (microsoft.public.access.gettingstarted)
  • Re: Analyzing/Normalizing Database
    ... The Table Analyzer Wizard tries its best to do a good job, ... direct attributes of an employee, so belong in the Employees table. ... this database better by getting it "Normalized" so that there is one table ... I used the Analyze Table function to separate the big table into smaller ...
    (microsoft.public.access.tablesdbdesign)