jack drawbridge
jackandpat.d at gmail.com
Tue May 28 07:02:20 CDT 2013
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 >