Start off by modeling entities, not tables (and remember that they _are_
different).
If they are different entities, then model them that way. If they are two
subtypes of the same entity, then model them as the same entity with two
subtypes. When the logical model is resolved into a physical model, then
you might end up merging the attributes of these two subtypes into a single
table with the mutually-exclusive subtype columns NULLable.
Also take into consideration any relationships your model might have between
the Player entity and a "Team" entity: a Prospect most likely is not related
to a Team, and that is something much more significant that a "Status" value
separating Players from Prospects. Don't try to accommodate this by putting
both Prospects and Players into a single table and making the relationship
between Player and Team optional rather than mandatory. If you do, then
you're letting the tail wag the dog.
Respectfully,
Adam Phillip Churvis
Productivity Enhancement, Inc.
Want truly advanced ColdFusion 5 training? Register for the Advanced
Bootcamp for ColdFusion 5, Database, and Javascript at
http://www.ColdFusionTraining.com!
http://www.CommerceBlocks.com
E-mail: [EMAIL PROTECTED]
Phone: 770-446-8866
----- Original Message -----
From: "Alexander Aguilar" <[EMAIL PROTECTED]>
To: "CF-Talk" <[EMAIL PROTECTED]>
Sent: Thursday, May 17, 2001 12:41 PM
Subject: OT: database modeling
> I'm working on an amateur sport team's website and they of course want to
keep track of their player information. On their website they want a
contact/membership form for prospective players. Now the data that is
stored for a Player and a Prospect is very similar (personal info [height,
weight, age], contact info and prowess [batting style, specialty,
experience,etc]. A prospect is not a member of the team until approved by
the team.
>
> Initially, I was leaning toward building a Prospects table but as I
mentioned the fields are basically the same as the Player table. Now I'm
thinking I should put prospect data directly into the Player table but
differentiate it by using a "status" column which would one of the three
following values (active | inactive | prospect). My question is which is
the better way to handle Prospects (ie, separate Prospect table or use
Player table with status field) ?
>
> thanks,
> alex
>
>
>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Structure your ColdFusion code with Fusebox. Get the official book at
http://www.fusionauthority.com/bkinfo.cfm
Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/
Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
