FUDforum
Fast Uncompromising Discussions. FUDforum will get your users talking.

Home » Imported messages » comp.lang.php » thank you, richard@noreply
Show: Today's Messages :: Unread Messages :: Show Polls :: Message Navigator
| Subscribe to topic | Bookmark topic 
Switch to threaded view of this topic Create a new topic Submit Reply
thank you, richard@noreply [message #184477] Thu, 02 January 2014 17:11 Go to next message
M. Strobel is currently offline  M. Strobel
Messages: 386
Registered: December 2011
Karma: 0
Senior Member
add to buddy list
ignore all messages by this user
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.
Re: thank you, richard@noreply [message #184478 is a reply to message #184477] Thu, 02 January 2014 20:16 Go to previous messageGo to next message
Mr Oldies is currently offline  Mr Oldies
Messages: 241
Registered: October 2013
Karma: 0
Senior Member
add to buddy list
ignore all messages by this user
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.
Re: thank you, richard@noreply [message #184504 is a reply to message #184477] Fri, 03 January 2014 12:46 Go to previous messageGo to next message
Denis McMahon is currently offline  Denis McMahon
Messages: 634
Registered: September 2010
Karma: 0
Senior Member
add to buddy list
ignore all messages by this user
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
Re: thank you, richard@noreply [message #184513 is a reply to message #184504] Sat, 04 January 2014 13:48 Go to previous message
M. Strobel is currently offline  M. Strobel
Messages: 386
Registered: December 2011
Karma: 0
Senior Member
add to buddy list
ignore all messages by this user
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.
Quick Reply
Formatting Tools:   
  Switch to threaded view of this topic Create a new topic
Previous Topic: Processing accented characters submitted from forms
Next Topic: Loop through array, change headings
Goto Forum:
  

-=] Back to Top [=-
[ Syndicate this forum (XML) ] [ RSS ]

Current Time: Wed Oct 18 14:40:40 EDT 2017

Total time taken to generate the page: 0.00678 seconds