Re: db design question

From: t <tomcolumbia_at_hotmail.com>
Date: Mon, 17 Mar 2003 17:06:08 GMT
Message-ID: <4gnda.242639$na.12664536_at_news2.calgary.shaw.ca>


peter, thx for responding.

I like ur thoughts about maybe adding an account entity. But I will see if that is necessary according to the business rules here.

I am a bit confused about what you mean with having plans, rooms and codes as intersecting entities.

right now, an employee gets a customer. that customer will have many plans and plans will have many rooms. so the employee prices out these rooms for the plans using the codes (the codes represent all the parts and their prices).

with this being said, is it necessary to have types of plans, rooms and codes and have them intersect?

Also, with my current design, i'm using autonumbers as the primary key which can lead to delete anomolies if things are deleted. The way i understand it is that deleting database entries is usually not good practice. Therefore i have an active field which determines if that entry is still relevant. Are these good design practices?

I am open to new ideas. Please let me know.

tom

"Peter Johal" <pjohal02_at_hotmail.com> wrote in message news:b52rpm$oaj$1_at_reader1.tiscali.nl...
> Tom,
>
> Using this model, you can only link a customer to an employee if there is
a
> plan. You could introduce an Account entity, which links customers to
> employees, and base plans on that entity.
>
> Also, don't you want to model types of plans, rooms and codes? And then
make
> the plans, rooms and codes themselves into intersection entities.
>
> Peter
>
>
> t <tomcolumbia_at_hotmail.com> schreef in berichtnieuws
> sgqca.222883$na.10378076_at_news2.calgary.shaw.ca...
> > I'm relatively new to db design. So I'm just gonna throw this out to
> yall:
> >
> > I have the following database dependencies:
> >
> > employees->->customers
> > customers->->plans
> > plans->->rooms
> > rooms->->codes
> >
> > -a room only has one plan
> > -plan only has one customer
> > -a code only has one room
> >
> > i am having trouble trying to normalize those relations.
> >
> > would this be very far off design?
> >
> > employees(*empID, username, etc)
> > customers(*custID, customerName, etc)
> > plans(*planID,custID,empID, planName, etc)
> > rooms(*roomID,planID, roomName, etc)
> > codes(*codeID,roomID, codeName)
> >
> > this design allows me to keep track of which employee has what customer
> and
> > plan. Since every plan is unique, rooms and codes can be retrieved as
> well.
> >
> >
> > if you need more information, don't hesitate to ask. i really
appreciate
> > the help.
> >
> >
> >
>
>
Received on Mon Mar 17 2003 - 18:06:08 CET

Original text of this message