F
fajita
All of my info is in one table. Is that a big "No, No?"
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an alternative browser.
You should upgrade or use an alternative browser.
P
Peter van der Goes
fajita said:All of my info is in one table. Is that a big "No, No?"
Depends on what information.
If you post a table layout with field names and descriptions, I'm sure folks
here will be glad to offer suggestions for normalizing your data.
J
John Vinson
All of my info is in one table. Is that a big "No, No?"
Maybe yes, maybe no; it depends on the information.
The way one should decide what tables you need is to turn off the
computer, walk away from it, and find a sheet of paper and a pencil.
Think about the business problem that the database is designed to
solve.
Identify each "Entity" - real-life person, thing, or event - the is of
importance in the problem. Each such Entity should have its own
separate table. For instance, you might have a table of People.
For each Entity, identify its "Attributes" - distinct, atomic (having
only one value), non-interdependent chunks of information that you
need to know about the entity for the purpose of the database. For
example, each Person in the People table has a firstname, a lastname,
a birthdate, maybe some other relevant attributes. However you should
NOT have fields like "CurrentPosition", "PreviousPosition",
"LastButOnePosition" - these fields are repeating fields which are
related to one another, not just to the person; you have discovered
another entity, PeoplesPositions, which deserves its own table.
Each Attribute becomes a field in the table.
Finally determine how the tables are related. You might have a table
of People, and a separate table of Jobs; each person might work (over
time) at several jobs, and each job might have several people doing
it. For this you need the PeoplePositions table above - it's linked
one to many to the People table and also one to many to the Jobs
table.