Am I making this harder than I need to?

Results 1 to 6 of 6

Thread: Am I making this harder than I need to?

  1. #1

    Default Am I making this harder than I need to?

    Hi guys. Im wanting to get some feedback as to how I should handle this problem.<BR><BR>I have an events calendar of which allows the entry of single events, recurring events and ranging <BR><BR>events.<BR><BR>Single events - single instance only<BR>Recurring events - events that recur and have the same details such as venue, times, costs etc<BR>Ranging events - events that recur and have different details such as venue, times, costs etc<BR><BR>Data is stored in an access db within the following tables.<BR><BR>events<BR>this table holds all event information excluding dates<BR><BR>event_dates<BR>this table holds all of the event dates<BR><BR>The two have a value of which ties them together.<BR><BR>eg<BR>event - Internet Awareness Session <BR>ID 34587654293930074<BR><BR>event dates 23/07/04 10am 23/07/04 3pm <BR>ID 34587654293930074<BR><BR>When populating the database with single and recurring events, the actual event detail information <BR><BR>is recorded once only as this information is the same throughout. Entering the same information over <BR><BR>is pointless and causes performance issues when submitting recurring events that may consist of up <BR><BR>to 300 odd entries. <BR><BR>Now this works fine with single and recurring events but doesnt with ranging events because the <BR><BR>actual event details are different. Im a little confused myself.<BR><BR>How can I populate the database in an efficient manner without sacrificing any functionality?<BR><BR>Beforehand I just put everything in together into the events table as individual entries, with the <BR><BR>event dates and details together. Should I go back to this? Or am I on the right track?<BR><BR>Thanks,<BR>John

  2. #2

    Default anyone..?


  3. #3
    Join Date
    Dec 1969

    Default I think either way is going to have its...

    ...advantages and disadvantages. Personally, I would have only one table to avoid join queries and the like, even though it means the information isn&#039;t normalized. To link recurring events, I would give them all a unique ID that they share, so that you can change all their details in one foul swoop. Then you can have any combination of events, single, range and recurring.<BR><BR>But as I said - that&#039;s not going to be a lot better than the way you&#039;re suggesting. It&#039;s more of a personal preference.<BR><BR>Oliver.

  4. #4

    Default Im already doing that Oliver

    "To link recurring events, I would give them all a unique ID.."<BR><BR>thats what that big long string of numbers is. 34568765243678987<BR><BR>Its great just inserting the one record for recurring events because its a lot quicker. And as I said, the event information doesnt change, just the dates. Problem is identifying individual instances of each event.<BR><BR>Its a little messy. I think ill go back to the way I was doing it initially. The thought was there...<BR><BR>Oh well.<BR><BR>Thanks,<BR>John

  5. #5
    Join Date
    Dec 1969

    Default I know you're doing that already in...

    ...your current setup, but I was speaking about going back to having one table, in which case each event would get its own ID - even if it&#039;s part of a recurring event or not - which is why I suggested adding back in the ID that links them all. I didn&#039;t mean to offend or imply you&#039;re doing the wrong thing.<BR><BR>Oliver.

  6. #6

    Default sorry mate...

    no need to apologise<BR><BR>Im doing what you suggested now.<BR><BR>Gotta change so much!<BR><BR>Cheers,<BR>John

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts