TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
Joy Brady wrote:
> You need to approach this as a database problem, not
> an Access 2000 problem. For those of you not
> interested, I warn you: the following is a super-quick
> overview of how to normalize information and create a
> quicky "relational" database using Jazzmyne's case.
> I'll guess that your table is something like this
> right now. Let's call it "Employees":
> UniqueID Fname LName Title Projects
> jbra1 Joy Brady Advice-Giver (empty)
> jsmi1 Jim Smiley Receptionist CCC
> jsmi2 Joe Smith Committee Guy CCC,PDC,PCCC
>
> If you have, or can have, multiple entries in a given
> field (such as Projects, in your case), it is good to
> break that field out into two separate tables. One to
> describe the projects themselves. One to link the
> projects to the people. Here's a lookup, or
> descriptive table - "Projects":
> ProjAbbr ProjectName
> CCC Committee-Creation Committee
> PDC Process-Definition Committee
> PCCC Process-Committee Creation
Joy,
You have provided one of the most concise and clearest examples of
relationship database theory that I have seen in a long time.
Now only if you could explain cubed database theory.
--
Peter
"When a man sits with a pretty girl for an hour, it seems like a
minute. But let him sit on a hot stove for a minute-and it's
longer than any hour. That's relativity," - Einstein-
