Arthur Fuller
fuller.artful at gmail.com
Tue May 28 12:37:42 CDT 2013
Aw.... you flatter me, William! LOL. On Tue, May 28, 2013 at 12:53 PM, William Benson <vbacreations at gmail.com>wrote: > I like this approach because if more associates are added later they would > not get left out. Super good forward thinking thinking Arthur. > On May 27, 2013 11:53 PM, "Arthur Fuller" <fuller.artful at gmail.com> wrote: > > > One possibility is to include an EventType column, with one value > > identifying company events such as the annual picnic and another value > > identifying employee events. Depending on that value, you could switch > the > > rowsource of the combobox to suit. Both types of events could reside in a > > single table, with queries identifying one type or the other. Just a > > thought. > > > > Arthur > > > > > > On Mon, May 27, 2013 at 11:22 PM, William Benson (VBACreations.Com) < > > vbacreations at gmail.com> wrote: > > > > > I realize I have used "latter approach" kind of ambiguously in the > > "latter" > > > sentence. > > > > > > > > > LOL (Lots of Latters)... > > > > > > -----Original Message----- > > > From: William Benson (VBACreations.Com) [mailto:vbacreations at gmail.com > ] > > > Sent: Monday, May 27, 2013 11:20 PM > > > To: Access Developers discussion and problem solving > > > Subject: A noun is a person place or thing - what is an Event? > > > > > > 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 > > > > > > > > > > > -- > > Arthur > > Cell: 647.710.1314 > > > > Prediction is difficult, especially of the future. > > -- Niels Bohr > > -- > > 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 > -- Arthur Cell: 647.710.1314 Prediction is difficult, especially of the future. -- Niels Bohr