Generally in a relational model, you break out groups of attributes if they
will repeat more than once or if they will repeat an unknown number of
times. In your case if you want to store multiple types of addresses for a
client, a separate table would be a good solution(mailing address,main
office , ect). For phone numbers, a separate table would give you the
flexibility to add multiple cell phones and pagers without having to add
columns to the base table.
If neither of those conditions exist, just leave the single address group in
line. If you have severe performance problems, you would have to sacrifice
the flexibility you gain from the separate address table. I would generally
model it differently than you have. I would create an artificial key for
the client and have the address table inherit that key plus add the address
type for the rest of the primary key.
I believe that in object oriented languages, relational models work fine if
you bind to the primary keys.
Steve Lucord wrote in message <38590DB6.BDF479BF_at_lmco.com>...
>I have several tables that contain address information in the system I
>am currently working on. Instead of putting the columns that pertain to
>
>the address in each table, I created an address table with a system
>assigned key. Each database table that needs an address contains a
>foreign key to the seperate address table.
>
>For example:
>
>CLIENT
>
>Social Security VARCHAR2(11) 555-55-5555
>Address_Id NUMBER(15) 1
>Name VARCHAR2(30) Joe Client
>
>ADDRESS
>
>Address_Id NUMBER(15) 1
>Address_Line VARCHAR(80) 123 Address Way
>City VARCHAR(30) Any City
>State VARCHAR(2) AK
>Zip Code VARCHAR(10) 77598-5339
>
>I am looking for the pros-and-cons of modeling the database in this
>manner. Philosophical as well as practical arguments are welcome.
>
>Thanks in advance for any suggestions.
>
>Steve Lucord
>
>
Received on Thu Dec 16 1999 - 15:39:03 CST
