Что ж, чтобы сохранить само правило повторения, вы можете использовать урезанную версию RFC 5545 (и я действительно предлагаю вам сильно сократить его). Помимо всего прочего, это упростит экспорт в другие приложения, если вы захотите.
После того, как вы приняли это решение, для стороны базы данных вам нужно решить, хотите ли вы хранить каждое вхождение события или только одну запись для повторяющегося события, расширяя ее по мере того, как вы нужно. Очевидно, что гораздо проще запрашивать базу данных, когда вы уже все расширили, но это усложняет обслуживание.
Если вам не нравится писать довольно сложный SQL, который может быть трудно протестировать (и вам понадобится много модульных тестов для всех видов угловых случаев), я бы посоветовал вам сделать саму базу данных относительно " тупой »и напишите большую часть бизнес-логики на таком языке, как Java или C # - любой из которых, конечно, может быть встроен в хранимые процедуры, в зависимости от вашей базы данных.
Еще одна вещь, которую вы должны спросить себя, - нужно ли вам справляться с исключениями для событий - одно событие в серии, меняющее время / местоположение и т. Д.
У меня есть некоторый опыт работы с календарями (большую часть прошлого года я работал над календарем в Google Sync через ActiveSync), и я должен вас предупредить, что все усложняется действительно быстро. Все, что вы считаете «выходящим за рамки», - это благословение. В частности, вам нужно работать в нескольких часовых поясах?
И, наконец, будьте очень, очень осторожны, когда выполняете арифметические операции с календарными операциями. Если вы собираетесь использовать Java, пожалуйста используйте Joda Time, а не встроенные _1 _ / _ 2_ классы. Они вам очень помогут.
person
Jon Skeet
schedule
16.10.2009
