Re: Use relationship or not?
- From: Martin <Martin@xxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Wed, 24 Dec 2008 11:35:01 -0800
Susanne,
I'm a retired Marine CWO and working out here in 29 Palms CA. I'm now a DOD
civilian and have been designing dB for over 25 years. Your table seems to
me it needs to be normalized. At least to the third normal form. You can
get info from the Internet about how to do this. There are great examples on
the net. I am currently working to fix a dB that has over 50 tables in
relationships. If you understand normalization, then you can easy ask
normalization questions to see if you do infact need all the fields in one
table.
Example. A diver can only where 1 suit at a time. Is this a true statment.
If it is, then you can seperate all the suit info into a table and have a
SuitId to associate the suit to the diver. But each suit can be worn by many
divers.
If you are not familiar with diving, you need to ask your SME's questions to
help you normalize your dB.
Martin Cox
"John W. Vinson" wrote:
On Tue, 23 Dec 2008 10:11:01 -0800, Susanne.
<Susanne@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
It's dealing with something for the military, and yes, there are a lot of
fields that they need to keep info on. Not my decision :) I do have some
one to many relationships where they are appropriate, like keeping an
environment log for each dive (yes, diving) every 30 minutes. There is a
bunch of pieces on each suit they need to keep track of (every single piece,
that is why there are so many fields, Serial #s for each type). I do NOT
have a field for each piece, just each of the mandatory items. They are
being very strict in how they want it to display on the screen (as it does on
paper, a specific layout in a specific order) and so I cannot create a simple
one to many relationship.
So, I have a dive with lots of attributes. This is what I want to split,
the dive suit parts ... what they call pooled and non-pooled parts. It is
all still related to the regular dive info, but I can easily separate it.
That certainly sounds like a on (dive) to many (pieces) relationship - or more
likely a many to many, since I presume that a given suit piece will be used on
many dives. The appearance on the screen should certainly NOT drive your
decisions about table structure! I'd even consider using an unbound form with
VBA code to move data to and from normalized tables, before creating a
wide-flat design as you suggest. But it sounds like you have a handle on the
design and can do it either way: one hugely wide table (if it won't push up
against the 2000 bytes per record limit), or a normalized design (my
recommendation).
--
John W. Vinson [MVP]
- References:
- Use relationship or not?
- From: Susanne
- Re: Use relationship or not?
- From: John W . Vinson
- Re: Use relationship or not?
- From: Susanne
- Re: Use relationship or not?
- From: John W . Vinson
- Use relationship or not?
- Prev by Date: Automating Excel Spreadsheet
- Next by Date: Sample code of auto add ID with year prefix ...
- Previous by thread: Re: Use relationship or not?
- Next by thread: print form
- Index(es):
Relevant Pages
|
