Что лучший способ состоит в том, чтобы представить “Повторяющиеся события” в базе данных?

Я тоже думал об этом, хотя еще не реализовал это, но это мои мысли о простом решении.

При настройке повторяющегося события попросите пользователя указать " дата окончания »и создайте отдельные события для каждого из них (на основе повторяющихся параметров). Поскольку это повторяющееся событие, установите уникальный «повторяющийся идентификатор» для каждого из них. Затем этот идентификатор будет использоваться для отметки события как повторяющегося, и если вы измените будущее событие, вы можете предложить пользователю применить его к остальным будущим событиям, удалив и воссоздав повторяющиеся события с новым «повторяющимся идентификатором», который также будет отличать это повторяющееся событие от ранее измененных.

Надеюсь, что это имеет смысл, и хотел бы получить любые комментарии.

Что ж, чтобы сохранить само правило повторения, вы можете использовать урезанную версию RFC 5545 (и я действительно рекомендую вам сильно урезать ее). Помимо всего прочего, это упростит экспорт в другие приложения, если вы захотите.

После того, как вы приняли это решение, для стороны базы данных вам нужно решить, хотите ли вы сохранять каждое вхождение. события или только одна запись для повторяющегося события, расширяя ее по мере необходимости. Очевидно, что гораздо проще запрашивать базу данных, когда у вас уже все расширено, но это усложняет обслуживание.

Если вы не хотите писать довольно сложный SQL, который может быть трудно протестировать (а вы » мне понадобится много модульных тестов для всех видов крайних случаев) Я бы посоветовал вам сделать саму базу данных относительно «тупой» и написать большую часть бизнес-логики на таком языке, как Java или C # - на любом из которые, конечно же, могут быть встроены в хранимые процедуры в зависимости от вашей базы данных.

Еще одна вещь, которую вы должны спросить, - это нужно ли вам справляться с исключениями для событий - одно событие в серии, изменяющее время / местоположение и т. д.

У меня есть некоторый опыт ведения календаря (большую часть прошлого года я провел, работая над битом календаря Google Sync через ActiveSync), и я должен предупредить вас, что все становится сложнее действительно быстро. Все, что вы считаете «выходящим за рамки», - это благословение. В частности, вам нужно работать в нескольких часовых поясах?

О, и, наконец, будьте очень, очень осторожны, когда выполняете арифметические операции с календарными операциями. Если вы собираетесь использовать Java, , пожалуйста, используйте Joda Time , а не встроенные классы Calendar / Date . Они вам очень помогут.

I would record recurring events as two separate things in the database. First of all, in an events table, record each and every occurence of the event. Secondly, have recurrences table in which you record the details that you ask for to set up the recurring event. Start date, periodicity, number of occurences, etc.

Then you might think of tying it all together by putting the PK of recurrences into each of the event records as an FK. But a better design would be to normalise the event table into two tables, one which is just the barebones of an event, and one which has the details, which could now be referring to multiple events. That way every event record, recurring or not, has an FK to the PK of the eventdetails table. Then in eventdetails, record the PK of recurrences somewhere along with agenda, invitees, etc. The recurrence record does not drive anything. For instance, if you want a list of all recurring events, you look through eventdetails for all events with a non-null FK to recurrences.

You'll need to be careful to synchronise all of these things, so that you insert or delete events when the recurrence data changes.

"Aside from anything else"

does this include "the very requirements" ?

"that will make it easy to export into other applications should you wish to."

Do the stated requirements include "it must be easy to export the calendars to other applications" ? My impression was that the problem consisted solely of building the FIRST application.

that said, my own response :

You need to limit yourself/your user on the types of "recurrency" your sytem will be able to support. And "All of the above" or "No Limitations" will not be a valid answer if you/your user want(s) to end up with a usable application.