| Re: thank you, richard@noreply [message #184504 is a reply to message #184477] |
Fri, 03 January 2014 17:46   |
Denis McMahon
Messages: 634
Registered: September 2010
Karma:
|
Senior Member |
|
|
On Thu, 02 Jan 2014 23:11:01 +0100, M. Strobel wrote:
> And youse guys keep up the good work!
Following on, may I present:
A brief comparison and examination of the differences between
contemporary database theory and richardian database theory, as shown by
dissecting a typical database structure according to each theory of
database design.
A "contemporary" events calendar database:
Tables:
table 'events', one record for each event:
id / date / event_name / location_id (locations.id)
table 'locations', one record for each location:
id / name / address / phone / manager_id (people.id)
table 'people', one record for each person (be they an event attendee or
location manager or both):
id / name / address / phone
table 'attendees', one linking record for each attendee for each event
they attend:
event_id (events.id) / attendee_id (people.id)
The "Richardian" version of the same events calendar database:
table 'calendar_YYYY': One table for each calendar year with one record
for each attendee for each event:
Date / Event / Location / Location address / Location Phone / Location
manager name / Location manager phone / Attendee name / Attendee phone /
Attendee address
Note especially the duplication of event and location information across
multiple records where an event has multiple attendees, as well as the
duplication of attendee information across multiple records where an
attendee attends multiple events. Note also that if a location manager is
also an event attendee, it is necessary to run multiple updates eg to
change their phone detail.
--
Denis McMahon, denismfmcmahon(at)gmail(dot)com
|
|
|
|
Calendar
Search
Help
Members
Register
Login
Home
]