Tworzenie schematu bazy danych dla aplikacji kalendarza

Zmagałem się z tym samym problemem, i właściwie bawiłem się pomysłem "tabeli pamięci podręcznej" sugerowanym powyżej, ale potem natknąłem się na alternatywę (sugerowaną tutaj), która nie wydaje się być jeszcze reprezentowana.

Zbuduj tabelę zawierającą wszystkie zdarzenia

EventID (primary key)
Description
StartDate
PeriodType - days, weeks, months, years
PeriodFreq - # of days, weeks, etc between events
EndDate
... other attributes that can be modified

Następnie dodaj tabelę dla WYJĄTKÓW do tych zdarzeń. Ta tabela używa klucza złożonego, składającego się z identyfikatora EventID, który jest mapowany do tabeli zdarzeń, oraz identyfikatora wystąpienia do wybrania konkretnego zdarzenia w serii.

EventID (key)
InstanceID (key)
InstanceDate - the modified date of the exception 
IsCancelled - a flag to skip this date when traversing the series
... other attributes that can be modified

Wydaje się, że tabela zdarzeń jest znormalizowana i unika rozdzielania serii w celu obsługi wyjątków.

Dlaczego nie użyć kalendarza Google jako bazy danych dla tej aplikacji kalendarza, opierając się na API Kalendarza Google do przechowywania i pobierania wydarzeń kalendarza?

Calendar API to REST API, do którego można uzyskać dostęp za pośrednictwem jawnych wywołań HTTP; API udostępnia większość funkcji dostępnych w interfejsie Google Calendar Web, dzięki czemu aplikacja kalendarza może być tak samo funkcjonalna, jak Kalendarz Google (dużo funkcjonalności!!!).

Twoja aplikacja potrzebuje tylko zaimplementuj OAuth 2.0 Dla interfejsów API Google, które można ułatwić za pomocą pojedynczej usługi logowania, takiej jak Auth0, aby zapewnić odpowiednie tokeny dostępu. Następnie aplikacja kalendarza może używać tych tokenów w połączeniu z interfejsem API kalendarza, aby zapewnić bezproblemowe przechowywanie i pobieranie wydarzeń kalendarza w formacie JSON.

Użytkownicy tworzą wydarzenia w ramach własnego " nowego kalendarza."Ten kalendarz jest udostępniony w formie konta Gmail dedykowanego tej aplikacji- the konto Gmail aplikacji .

Zasadniczo Kalendarz Google staje się Twoją bazą danych, dzięki czemu możesz mieć konto gmail aplikacji nie tylko przechowywać wszystkie wydarzenia aplikacji, ale także umożliwić przeglądanie i edycję tych wydarzeń za pomocą intuicyjnego interfejsu.

Przytrzymaj element powtarzający się w tabeli zdarzeń jako normalny, ale oznaczony jako powtarzający się z odpowiednimi datami rozpoczęcia/ zakończenia.

Jeśli użytkownik modyfikuje pojedynczą instancję spotkania, po prostu utwórz nowe zdarzenie, być może z 'parentId' równym ID zdarzenia powtarzającego się.

Zbuduj logikę, która powoduje, że kalendarz nadpisuje wszystkie powtarzające się zdarzenia w danym dniu zdarzeniami z pasującymi identyfikatorami nadrzędnymi.

Twoje pytanie o wydajność to w zasadzie stara prędkość vs. problem z przechowywaniem. Naprawdę nie sądzę, aby wymagane obliczenia przekroczyły zapotrzebowanie na miejsce do przechowywania tak wielu terminów. Wystarczy poczytać o optymalizacji baz danych-indeksowaniu itp.

Czy mógłbyś połączyć dwa światy z tabelą" cache", w której wstępnie obliczasz następne X dni zdarzeń?

Więc trzy tabele:

recurring_event_specs
one_time_events
cached_recurring_events

Dla dowolnej części kalendarza w ciągu X dni od dnia dzisiejszego, Twoje zapytanie zostanie połączone one_time_events i cached_recurring_events.

Wtedy będziesz musiał wykonać obliczenia daty w locie, jeśli użytkownik spróbuje spojrzeć na Część kalendarza więcej niż X dni w przyszłości. Wyobrażam sobie, że można znaleźć sane X, który obejmowałby większość normalnych użyj.

Tabela cached_recurring_events musi być aktualizowana za każdym razem, gdy użytkownik dodaje nowe powtarzające się zdarzenie - i ewentualnie raz dziennie w trybie offline, przez zadanie cron/zaplanowane zadanie. Ale tylko w dniach, w których nie zostało utworzone żadne nowe powtarzające się wydarzenie.

Najlepszym sposobem na to jest zapisanie łańcucha wzorca powtarzania opartego na standardach (iCal).. i pozostaw puste, jeśli jest to pojedyncze wydarzenie. Istnieje kilka interfejsów API, które mogą analizować wzorzec powtarzania i tworzyć obiekty zdarzeń, które można powiązać z elementami interfejsu użytkownika.... żadne z wystąpień nigdy nie musi być przechowywane w bazie danych, tylko początkowe Zdarzenie (Zdarzenie)..

Nie możesz zapisać wydarzeń dziennie z czasem rozpoczęcia i zakończenia? Wygeneruje wiele danych dla zdarzeń, które dzieją się codziennie (może to nie jest relacyjne), ale ułatwi zadawanie zapytań i będzie można wprowadzać wyjątki(np. miejsce zdarzenia spłonęło lub pracownicy uderzają). Aby wygenerować dni na wydarzenie, proponuję zaimplementować to w front-endzie wywodzącym się z jakiegoś wzorca ICal-owskiego.