Hello and welcome to our community! Is this your first visit?
Register
Enjoy an ad free experience by logging in. Not a member yet? Register.
Results 1 to 5 of 5
  1. #1
    New to the CF scene
    Join Date
    Sep 2011
    Posts
    3
    Thanks
    2
    Thanked 0 Times in 0 Posts

    Multi User Calender/Availability + search

    Hello all.

    Could someone give me some advice on the following problem:

    I am wanting to design a basic calender system for multiple users.
    So each user has their own calender, in which they can enter information for any particular day (probably just 3 fields: 2 drop downs (time, location), 1 text (extra info.)).

    User should also be able search other the entries of other user's and find a match - i.e. I am looking for a [user-type] on the [date] at [time] in [location].

    The problem I have is I can't figure out the best structure for the database - should I use one table per user (potentially 1000+) with a row for the date holding the time, location and extra info.
    Or one table with a row for date and have the different fields stuck together (e.g. for 20/09/2011 - user1, 0900, location1, extra info). These can then be extracted individually (breaking up the string into it's components if that's possible) to populate the original front-end fields should that user wish to make an edit.

    My thoughts are that the multiple table approach would serve best - I can create a script (php) to create the table, create the fields and the table name will allow for easy retrieval should the user wish to administrate their own calendar.
    However, I also think this would cripple the server if someone tries to search all tables.

    Whereas the single table should be quicker to search, but doesn't make it easy for administration.



    Many thanks for any input.

  • #2
    Senior Coder djm0219's Avatar
    Join Date
    Aug 2003
    Location
    Wake Forest, North Carolina
    Posts
    1,293
    Thanks
    4
    Thanked 202 Times in 199 Posts
    NO NO NO on a table for each person! Nightmare waiting to happen.

    One table for the calendar entries and another for user details (I'm assuming some sort of registration will be required). For the table of calendar entries:

    entry# - auto increment
    userid - corresponds to the user id in the user table (which will likely be an auto increment column also)
    datetime - a datetime column
    extra - a text or varchar column for extra data - column type depends on how much you want them to be able to enter
    Dave .... HostMonster for all of your hosting needs

  • Users who have thanked djm0219 for this post:

    eipi (09-21-2011)

  • #3
    New to the CF scene
    Join Date
    Sep 2011
    Posts
    3
    Thanks
    2
    Thanked 0 Times in 0 Posts
    Thanks for the prompt reply djm0219.
    Sorry I haven't replied sooner.

    The one table approach does seem rather obvious now that someone else has explained it.

    But if you don't mind, I have just one more question.
    Instead of the datetime column, I would need to separate them to date & time.
    And I plan to display this (front end) as a table, so is there a crafty way to id the <td> and populate them with the entries from the db so that only one table needs to be made and the contents are dynamic?
    Or is it best to create a table for each month, have them labelled appropriately and then populate via code?

  • #4
    Senior Coder djm0219's Avatar
    Join Date
    Aug 2003
    Location
    Wake Forest, North Carolina
    Posts
    1,293
    Thanks
    4
    Thanked 202 Times in 199 Posts
    Quote Originally Posted by eipi View Post
    But if you don't mind, I have just one more question.
    Instead of the datetime column, I would need to separate them to date & time.
    Why? Store them in a way that has meaning which, in this case, is a date and time. How they end up being displayed is a secondary and minor issue.

    Quote Originally Posted by eipi View Post
    And I plan to display this (front end) as a table, so is there a crafty way to id the <td> and populate them with the entries from the db so that only one table needs to be made and the contents are dynamic?
    I don't understand that question.
    Quote Originally Posted by eipi View Post
    Or is it best to create a table for each month, have them labelled appropriately and then populate via code?
    Again, NO NO NO on a table for each month. Any combination of dates and/or times and/or users that you want may be easily retrieved from a single table.
    Dave .... HostMonster for all of your hosting needs

  • Users who have thanked djm0219 for this post:

    eipi (09-21-2011)

  • #5
    New to the CF scene
    Join Date
    Sep 2011
    Posts
    3
    Thanks
    2
    Thanked 0 Times in 0 Posts
    Thanks again for the reply djm0219

    Since I am rather new to php, I am certainly not describing my problem appreciably.

    My problem is how to generate the calendar for each month and have each day populated with the information from the db.
    So the user picks a day he wishes to make an entry for, fills in the appropriate information and saves.
    I am just getting a massive headache thinking about how to unify the db with the user interface.

    However, I have found a tutorial and some sample code which I believe I can tweak to accomplish this.
    Basically the code will generate a this months calendar, which I will tinker with to change the month as well as having the individual days as links to a popup from which the user can enter his information. So I don't need to display the db entries for each day in the calendar, but have the calendar days link to the db entries.

    The part about using multiple tables was concerning multiple html tables - basically me trying to alleviate a migraine by simplifying the problem.

    This stuff gets rather complicated very quickly. But thanks again for the reply.


  •  

    Tags for this Thread

    Posting Permissions

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