Re: database design question

You want to be careful here.

Columns in a database should serve one of two functions:

1. Identify objects/entities/rows (i.e. something)
2. Contain facts about that something

The two uses should not be mixed, or you will surely regret it later and suffer the consequences. Facts about things change over time, but a changed fact should not cause the identity of the thing to change.

Another standard design rule (normalization) is to not subdivide a single data field (first seven digits of account number) so that it means anything. Segregate individual facts into separate columns.

In terms of primary-foreign keys, each table should have a defined primary key. Related tables will contain a reference column (foreign key) that identifies the other tables primary key (this happens on the many side of a 1:many relationship). This is a matter of referential integrity, so that the information in your database makes sense.

For performance reasons, and index can be placed on foreign keys to improve access speed when joins occur.

To overcome your inexperience, you should find yourself a good book on database design theory.

Good luck
-wcb

Ed Lufker <elufker_at_swcp.com> wrote in article <63384k$cdb$1_at_sloth.swcp.com>...
> Hi All:
>
>
> I am getting pulled in a project that is requiring me to design
> a database. Not much experience here. I have 3 files that have
> related info to a customer. Here's the info I have, the first 7 digits
> of the account number field in file1 is the house number field in file2.
> The question is: would you set up a primary-foriegn key relationship or
> should I just load each file into a table in Oracle and just do joins
> when I need to get infomation out of the database. What would having
> the primary-foreign key relationship buy me.
>
> thanks in advance for any help with this.
> eddie lufker
>
>
Received on Thu Oct 30 1997 - 00:00:00 CST