Copy to Multiple Schedules is Wasteful

Message Topic Search Topic Options Post Reply Create New Topic Printable Version Translate Topic


   I'm working on incorporating your wonderful Calendar Active X control into my application and would like to make a suggestion: rather than having to copy a row from the event table to each schedule ID (to allow an event to show up for multiple people), you should consider allowing for a concatenated field of schedule IDs for which the event would be related.  
 
For example: 
 
Currently, if Mike (ID 1) and John (ID 2) wanted to meet and John created the event in his schedule, then there would be a ScheduleID of 2 for this.  The event would have to be copied (second row) with ScheduleID of 1 for this to appear also for Mike.  This is of course would work.  
 
The problem is that if there are 10 users and they each create 3 events a day then that is 1000 x 10 = 10,000 created each year.  If each of these records need to beshared with at least one other person then, using your existing approach, would bloat the database up to 20,000 (at least) events.  Using my suggest approach would still keep this to 10,000 records.  
 
I hope this is clear.  
 
Thanks,

Author	Message Topic Search Topic Options Post Reply Create New Topic Printable Version Translate Topic
CharlieF2 Members Profile Send Private Message Find Members Posts Add to Buddy List Newbie Joined: 20 September 2006 Location: United States Status: Offline Points: 1	Post Options Post Reply Quote CharlieF2 Report Post Thanks(0) Quote Reply Topic: Copy to Multiple Schedules is Wasteful Posted: 20 September 2006 at 12:17pm
	I'm working on incorporating your wonderful Calendar Active X control into my application and would like to make a suggestion: rather than having to copy a row from the event table to each schedule ID (to allow an event to show up for multiple people), you should consider allowing for a concatenated field of schedule IDs for which the event would be related. For example: Currently, if Mike (ID 1) and John (ID 2) wanted to meet and John created the event in his schedule, then there would be a ScheduleID of 2 for this. The event would have to be copied (second row) with ScheduleID of 1 for this to appear also for Mike. This is of course would work. The problem is that if there are 10 users and they each create 3 events a day then that is 1000 x 10 = 10,000 created each year. If each of these records need to beshared with at least one other person then, using your existing approach, would bloat the database up to 20,000 (at least) events. Using my suggest approach would still keep this to 10,000 records. I hope this is clear. Thanks,
	CharlieF2

sserge Members Profile Send Private Message Find Members Posts Add to Buddy List Moderator Group Joined: 01 December 2004 Status: Offline Points: 1297	Post Options Post Reply Quote sserge Report Post Thanks(0) Quote Reply Posted: 21 September 2006 at 8:24am
	Hello Charlie, Thanks, your idea is clear enough. We also thought about this approach when created multischedules functionality (as well as some other nice ideas ) But implementation of this will add redundant complexity to data structure, to data provider, and to the control. So, for the beginning we decided not to implement this feature. Below are a few notes and suggestions which may help you to choose a way of resolving this problem. Calendar have some features to avoid copying of events. NOTE: 1) Each calendar resource can display more than one schedule ID. 2) For shared events you can use some special ScheduleID. 3) There is a PrePopulate notification where you can filter calendar events before displaying. Implementation: 1. Virtual common schedule. Example: PersonalScheduleMike (ID 1), PersonalScheduleJohn (ID 2), CommonScheduleMikeJohn (ID 3) a) You create a single event with ScheduleID = 3 b) You setup Calendar to show 2 resoruces: Mike (ID 1 and 3), John (ID 2 and 3) This approach has only 1 disadvantage -- you have to create a lot of CommonSchedules when there are a lot of people. However, each such record takes a very small amount of storage. 2. Shared events know their Schedules. a) For shared events set ScheduleID = -1 (some default shared ID) and use CustomProperties collection to store ScheduleIDs of peoples who participate in this event. b) Such shared events will be populated for all users, and you should use PrePopulate notification to filter events. Check whether the ViewGroup's first ScheduleID presents in CustomProperties ScheduleIDs set. If not - remove such event from the collection. An advise: iterating from last to first element would let you easily remove event at current index. 3. Use IsEditOperationDisabled, BeforeEditOperation to customize shared events editing. For example you can disable moving shared events between users, but let to change a time start and duration. -- Best regards, Sergey