Re: re-designing & normalizing - best way to go about this?

In message <c883e8dd.0204111430.ede7e7f_at_posting.google.com>, D Newsham <d_newsham_at_hotmail.com> writes
>Hi all,
>
>Any advice will be appreciated here. I have been tasked with
>re-designing a database that, IMHO, is a mess. All of the data is in
>one table, fields:
>

>My questions are:
>Does it look like I am achieving my goal? I began breaking down the
>main table and what I found was, for instance - in the Species table,
>I may have 200 of the same class, family, genus - and the species is
>different. Should I have a seperate table each for class, family,
>genus... my thinking is not, because the species is dependant on the
>other 3 fields, but when I look at 2500 entries in the species table
>and see class repeated over and over... I am not sure.

It's a compromise. You could choose to build a database that sticks closely to the logical structure of the data, and have separate tables for every level of the hierarchy from Kingdom to Species or perhaps even down to strain for subspecies.

In general if you stray from the logical structure you will find that you need to do more programming to handle possible duplications in your data. And if anyone is going to search the database for all members of a given Class then it's best to only record the Class only once, in a Classes table.

-- 
Bernard Peek
bap_at_shrdlu.com

In search of cognoscenti