Re: Database design
- From: "BruceM" <bamoob@xxxxxxxxxxxxxxxxxx>
- Date: Mon, 1 May 2006 09:18:18 -0400
Responses inline.
"javagirl" <javagirl@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:C5EDC97C-E56D-436F-8601-B63E7FDD7ED1@xxxxxxxxxxxxxxxx
"BruceM" wrote:
A few questions:
Is each session related to a client? Can a session involve several
clients?
Yes, each session is related to a single client, or so I anticipate.
I wondered if there could be a many-to-many relationship between Sessions
and Clients. If not, that simplifies things a bit.
I assume that OrderMast is related to a client. In other words, a client
places an order. If you look up a client, I expect you would want to be
able to see a listing of that client's orders. Do you need to keep track
of
Session information in OrderDetails? If you keep track of sessions, you
will also be able to keep track of Products, which are related to
sessions.
That's what I haven't quite figured out. tblProduct is MY output. It
would
catalogue the negatives and/or digital files. I'm not sure yet if this is
going to be overkill; My intention is only to catalogue media that meets
my
professional standards as a photographer so that when a client requests
prints, I don't have to weed through the unsatisfactory shots to find what
I
want. I'm working on a more thorough description of my tables, but may
not
have that done for a little while yet.
If Product is for your information you may not want to include Product
information in Orders (or OrderDetails). A few questions to ask yourself:
Can a single order include output from several sessions? Do you want to
catalogue by Client or by Session? If the former, you may want Product to
be related to Client AND to Session. I have to say, though, that this kind
of relationship pushes the limits of my knowledge. Once you have decided on
what exactly you need to do it would probably be best to start a new thread
(which I will be following with interest).
My initial plan is that a session will be related to a client, an order
to
a session, a product to a session but also to a detailed order. That's
where
things are still fuzzy for me; I want to avoid creating circular
relationships. Phew, I've been away from this for TOOO long!
I would think a Detail may be associated with a Session, but again, I don't
see from what you have said why you would want Product information (as I
understand the contents of tblProduct) on an Order. I could see including
Session information. I may not understand fully, but I'll toss in the
observation anyhow.
For the relationships tables, I am a bit uncertain about how to proceed.
I
expect you would want a separate table for Children, etc., but I cannot
think offhand of the best way to transfer that information to a record in
the Client table and still maintain the relationship information. I hope
somebody else jumps in on this part of it at least.
tblFamDemo is primarily a means of keeping track of my clients' family
names and personal info that would help refresh my memory and allow
promotional mailings to be sent. At current it contains only a few fields
but I imagine it expanding as I go along. It's a tool for building client
relationships and marketing.
I think it makes sense to have a separate table. You could have a Yes/No
field to use if a child becomes a client in the future, or something like
that.
In general you will want to create the relationships between the
like-named
fields, then build a form (frmClient) based on tblClient, and subforms
(fsubSession and fsubProduct) based on tblSession and tblProduct. You
can
drag a subform icon onto a form (fsubProduct onto fsubSession, and
fsubSession onto frmClient) in form design view to create a subform. It
will probably help if fsubProduct is a Continuous form.
Yeah, I'm not EVEN there yet. I'm sure I'll have plenty of questions when
I
get to that point though.
Just pointing out the general shape of a possible user interface. I kept in
very general because you are clearly still in the planning stages.
That's all I can add for now. I think you're on the right track with the
table relationships. I have used form names, etc. because it is easier
to
refer to names than to descriptions, but of course you will be using
whatever names suit you.
Thanks for your help.
.
- Prev by Date: Re: Database design
- Next by Date: Re: Resetting a field property from text to Autonumber in Access 2
- Previous by thread: Re: Database design
- Next by thread: Re: Database design
- Index(es):
Relevant Pages
|
