[AccessD] A noun is a person place or thing - what is an Event?

Darryl Collins darryl at whittleconsulting.com.au
Mon May 27 22:45:07 CDT 2013


Don't tie the events to anything.

You have Events (one table)
You have People (2nd Table)
You have Company (3rd Table)

You can then set up a 4th table which combine all 3 (Just on their PK of course) that is created, updated as the data is entered.

Say Table "tblEventSent"

Then you can send "Event 1" to Person1, Person4 and Company 3 (for this demo I will assume that the company Key is prefixed with 100)

So your "Event Sent" table will look something like (Event, Target)

1,1
1,4
1,103

Then you can search for which event went where (So E1 was sent to P1, P4 and C3),
Which People got what event? (P1 and P4 got E1)
Which company got what event? (C3 got E1)

Clearly in the real world you would add more smarts like Issue date, expiry date and other constrains that are relevant to the event.
But on a simple level,  Does that makes sense?

Cheers
Darryl.


-----Original Message-----
From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of William Benson (VBACreations.Com)
Sent: Tuesday, 28 May 2013 1:20 PM
To: 'Access Developers discussion and problem solving'
Subject: [AccessD] 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





More information about the AccessD mailing list