Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.php > #12509 > unrolled thread

thank you, richard@noreply

Back to article view | Back to comp.lang.php

Contents

  thank you, richard@noreply "M. Strobel" <sorry_no_mail_here@nowhere.dee> - 2014-01-02 23:11 +0100
    Re: thank you, richard@noreply richard <noreply@example.com> - 2014-01-02 20:16 -0500
    Re: thank you, richard@noreply Denis McMahon <denismfmcmahon@gmail.com> - 2014-01-03 17:46 +0000
      Re: thank you, richard@noreply "M. Strobel" <sorry_no_mail_here@nowhere.dee> - 2014-01-04 19:48 +0100

#12509 — thank you, richard@noreply

Most often the apparent nonsense of your questions was getting in my nerves.

But today I really laughed my ass off.

And youse guys keep up the good work!

/Str.

[toc] | [next] | [standalone]

#12510

On Thu, 02 Jan 2014 23:11:01 +0100, M. Strobel wrote:

> Most often the apparent nonsense of your questions was getting in my nerves.
> 
> But today I really laughed my ass off.
> 
> And youse guys keep up the good work!
> 
> /Str.

You're welcome.
I earned the title "Lord of the Bull!" quite well thank you.

[toc] | [prev] | [next] | [standalone]

#12532

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@gmail.com

[toc] | [prev] | [next] | [standalone]

#12542

Am 03.01.2014 18:46, schrieb Denis McMahon:
> 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.
> 

Do not complain about the Richardian version. It looks like he dropped using a
database, because it was too complicated, and started using hand crafted arrays
instead. So there is progress.

Now he should realize that he should drop that because he is making too many typing
errors.

There is still plain HTML.

/Str.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.php

csiph-web