|
|
Posted by Captain Paralytic on 12/21/07 13:06
On 21 Dec, 11:49, Jeff North <jnort...@yahoo.com.au> wrote:
> On Fri, 21 Dec 2007 03:12:18 -0800 (PST), in comp.lang.php Captain
> Paralytic <paul_laut...@yahoo.com>
> <ad3571cd-05c5-420c-8adc-0d4b61bbb...@e25g2000prg.googlegroups.com>
> wrote:
>
>
>
> >| On 21 Dec, 10:52, Tarscher <tarsc...@gmail.com> wrote:
> >| > On 21 dec, 11:45, Captain Paralytic <paul_laut...@yahoo.com> wrote:
> >| >
> >| >
> >| >
> >| > > On 21 Dec, 10:36, Tarscher <tarsc...@gmail.com> wrote:
> >| >
> >| > > > On 21 dec, 11:13, Captain Paralytic <paul_laut...@yahoo.com> wrote:
> >| >
> >| > > > > On 21 Dec, 08:43,Tarscher<tarsc...@gmail.com> wrote:
> >| >
> >| > > > > > Hi all,
> >| >
> >| > > > > > I have events containing attendees (events has many attendees). The
> >| > > > > > attendee table tells whether a user will attend the event or not. I
> >| > > > > > want to build a query that returns all the different events to a user
> >| > > > > > and if he will attend the event or not (or hasn't filled it in yet)
> >| >
> >| > > > > > the returned result could be something like:
> >| >
> >| > > > > > event.id attendees.user_id attendee.present
> >| > > > > > 1 1 0
> >| > > > > > 2 1
> >| > > > > > 3 1 1
> >| >
> >| > > > > > Please note that attendee.present can be null if the user didn't yet
> >| > > > > > tell if he would come to the event.
> >| >
> >| > > > > > Can this be done?
> >| >
> >| > > > > > thanks
> >| > > > > > Stijn
> >| >
> >| > > > > And this has what to do with php?
> >| >
> >| > > > > You would be better to ask this in a database group.
> >| >
> >| > > > > However some questions:
> >| > > > > If a user is querying the database to find if he will be attending the
> >| > > > > event, why does his own ID need to be present in the output?
> >| > > > > How does the attendee's id get into the table against an event in the
> >| > > > > first place?
> >| >
> >| > > > I indeed don't need the user_id since it is stored in the session. It
> >| > > > was just to clarify that the query need to return 1 user.
> >| >
> >| > > > Via the session the user_id stored in the session.
> >| >
> >| > > > Regards
> >| >
> >| > > I don't understand how
> >| > > "Via the session the user_id stored in the session."
> >| >
> >| > > answers the question
> >| > > "How does the attendee's id get into the table against an event in the
> >| > > first place?"
> >| >
> >| > sorry, a typo
> >| >
> >| > INSERT INTO attendee (event_id, user_id) VALUES ($event_id,
> >| > session['user_id'])
> >| >
> >| > I get the event_id via the url since the user does this per event.
> >| > eg
> >| > event1: 'will attend' 'will not attend'
> >| > event2: 'will attend' 'will not attend'
> >| >
> >| > The 'will attend' and 'will not attend' links point to the sql query
> >| > inserting in attendee
> >| >
> >| > I hope this helps
> >|
> >| No, that is not what I mean.
> >|
> >| You have a table attendee which contains events. Personally I would
> >| have an events table to contain the events.
>
> The 'attendee' table only contains 0, 1 or null. I think you mean the
> attendeeS table.
>
> Tarscher does have that structure. Ever heard of link tables? The id's
> in this case would be foreign keys thus perfectly valid.
>
> >| Now you tell us that the attendee table has events and attendees and
> >| it is possible for an attendee to say that they will not attend the
> >| event. I have to say that someone who will not attend an event will by
> >| definition not be an attendee!
>
> Don't jump to conclusions. The information may be needed for other
> purposes i.e. if a user hasn't responded to the last 10 invites then
> remove them from the list or if the user has declined so many invites
> then send an email to see if they want to stay on the list etc etc
> etc. We haven't been given this information.
>
> >| My question is, if for some reason you have all your events listed in
> >| the attendee table and the attendee has not put in there a record
> >| saying that he will or will not attend the event, how did the record
> >| with the event id and attendee id get in the table in the first place?
>
> You'd jumped to the wrong conclusion again. The attendeeS table
> contain foreign keys thus the information is correct.
>
> Although I would admit that there is really no need for the attendee
> table because the additional information could be stored within the
> attendeeS table, unless there was other relevant data that has not
> been shown.
> -- -------------------------------------------------------------
> jnort...@yourpantsyahoo.com.au : Remove your pants to reply
> -- -------------------------------------------------------------
I haven't jumped to any conclusions. I am trying to understand what
the proposed design is supposed to be. One should not name a table
attendee is if contains records of people who are not attendees. I
have no problem with data being held for any purpose whatsoever, but
something in the design must give a clue as to what is supposed to be
happening.
Navigation:
[Reply to this message]
|