I am working on creating a online calendar system for a friend. It is a multi-user system where each user can make their own calendar and add dates. I need to make this database scale nicely so that it can easily be split up. I have each user's calendar data in its own table so that I can split the databases neatly by user. Any recommendations as to how I should structure the user information (id, password, settings, ect.)? Thanks guys.
I would not give each user their own table. Once you get a lot of users, you may have too many tables to easily deal with. I would use a single table for the users, and a second table for all of the calendar entries. Something like: Users: user_id (primary auto increment) user_name other_user_info_fields.... Calendar: cal_id (primary auto increment) user_id (= users.user_id) date cal_entry User_id in the calendar table should be the same as the user_id in the users table. You should use a foreign key to restrict this field to only existing users. This setup will scale very well, and will make your database transportable.
YEs this is the correct way where the user table refers the time_table table , user is the foreign key . This way it can be manipulated and normalized further. Thanks & Regards, desitharki.com
I had each user have their own calendar table, because I have a system to split the database into 256 evenly distributed databases and this facilitates the splitting. The reason for the splitting being that the proposed system will run across several servers. I was thinking that maybe I would go with the single table idea for the users and put that into it's own database. I am not sure how easy it would be to scale that though. EDIT: I split the databases by taking the hash of the user_id and the first 2 characters of the hash dictates what database it gets stored/read from. Thinking about this further it might be easier not to give each user their own table, and just use the two table plan. What do you think?