William Benson
vbacreations at gmail.com
Tue May 28 11:50:29 CDT 2013
Thanks All , I need time to digest responses. Critical at this stage to pick the right design, going back and changing later will be painful. Hopefully the choice is more arbitrary. I am so far leaning towards advice already given that an Event item stands on its own in an Event table and may have as many relationships to associates within a company as I care to populate into a cross table. On May 28, 2013 8:04 AM, "jack drawbridge" <jackandpat.d at gmail.com> wrote: > Are the items of info collected at the various Events similar? You may want > to investigate subtype/supertype. > see > http://technet.microsoft.com/en-us/library/cc505839.aspx > > http://stackoverflow.com/questions/7044448/supertype-subtype-database-schema-question > http://www.crcnetbase.com/doi/abs/10.1201/9780203486054.ch8 > > Your Events,reminded me of the Generalization Vehicles for Trains, Planes > and Automobiles. > jack > > On Tue, May 28, 2013 at 3:54 AM, William Benson <vbacreations at gmail.com > >wrote: > > > An event cannot apply to muliple companies. > > On May 27, 2013 11:54 PM, "Stuart McLachlan" <stuart at lexacorp.com.pg> > > wrote: > > > > > Can an event relate to multiple associates in different companies? > > > > > > i.e. six people from each of four different companies all attend the > same > > > seminar? > > > > > > If so, I'd go with an Event table and a link table containing eventID > and > > > associateID. > > > > > > Alternatively make your link table: > > > > > > EventID > > > LevelFlag > > > ConcernedPartyID > > > > > > where LevelFlag is C]ompany or A]ssociate and the value of that flag is > > > used to determine > > > which table is linked. > > > > > > -- > > > Stuart > > > > > > On 27 May 2013 at 23:20, William Benson (VBACreations. wrote: > > > > > > > Hi this may well be long-ago-covered ground, but I am stuck in a > > > relational > > > > database conundrum. > > > > > > > > Simple world, there are companies, they have associates (people), > those > > > > people have events, and those events require notification circles. > > > > > > > > For example, a driver for a trucking company, may have a medical > > > inspection, > > > > notification of the due date for which, is to be sent to the trucker > as > > > well > > > > as the company's dispatcher (so that, after a certain date, the > > > dispatcher > > > > will remember not to send that trucker on any routes without proof of > > > > completed medical check). > > > > > > > > I am struggling over whether to make all events tied to the company > > with > > > a > > > > FK, or whether to make all events tied to an Associate, thus only > > > indirectly > > > > tied to the Company. > > > > > > > > The reason for my second-guessing the latter approach, which on the > > face > > > of > > > > things seems obvious, is scalability. Suppose there are certain kinds > > of > > > > events which are not related to associates, but based on the company > > > itself. > > > > I can't think of too many of examples of these off-hand, but for > > example, > > > > certain marketing oriented events, or billing related events, might > be > > > worth > > > > tracking. > > > > > > > > If I chose the other approach, to work at a Company level, create an > > > Event > > > > for that company, then choose the Associate(s) for whom the Event > > > mattered, > > > > then it seems all bases would be covered. > > > > > > > > Am I right in leaning towards the latter approach? > > > > > > > > -- > > > > AccessD mailing list > > > > AccessD at databaseadvisors.com > > > > http://databaseadvisors.com/mailman/listinfo/accessd > > > > Website: http://www.databaseadvisors.com > > > > > > > > > > > > > -- > > > AccessD mailing list > > > AccessD at databaseadvisors.com > > > http://databaseadvisors.com/mailman/listinfo/accessd > > > Website: http://www.databaseadvisors.com > > > > > -- > > AccessD mailing list > > AccessD at databaseadvisors.com > > http://databaseadvisors.com/mailman/listinfo/accessd > > Website: http://www.databaseadvisors.com > > > -- > AccessD mailing list > AccessD at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/accessd > Website: http://www.databaseadvisors.com >