|
|
Posted by Jeff North on 12/21/07 11:49
On Fri, 21 Dec 2007 03:12:18 -0800 (PST), in comp.lang.php Captain
Paralytic <paul_lautman@yahoo.com>
<ad3571cd-05c5-420c-8adc-0d4b61bbbe81@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.
-- -------------------------------------------------------------
jnorthau@yourpantsyahoo.com.au : Remove your pants to reply
-- -------------------------------------------------------------
Navigation:
[Reply to this message]
|