2015-06-02 5 views
8

Ich baue ein System, das verschiedene Arten von Ereignissen speichern/verwalten muss. Der Einfachheit halber werde ich mich auf die Gestaltung eines Kalenders konzentrieren (ich baue etwas etwas anderes, aber der Kalender ist eine gute Analogie und es ist einfach, darüber nachzudenken). Ich würde gerne über mögliche Datenbank-/Schemadesignideen hören.Datenbankentwurf für wiederkehrende Ereignisse mit Ausnahmen

Problem Beschreibung

Ich habe einen Kalender mit verschiedenen Arten von Ereignissen (der Einfachheit halber, sagen, dass es nur 1 Art von Veranstaltung ist: Aufgabe). Der Benutzer kann ein neues Ereignis für ein bestimmtes Datum hinzufügen, bearbeiten (Details ändern, Titel ändern oder zu einem anderen Datum wechseln) oder löschen. Es kann einmalige Ereignisse und wiederkehrende Ereignisse geben (mit verschiedenen Arten von Wiederholungen: alle X Tage, jeden 15. Tag des Monats, jede Woche am Montag; so ähnlich wie einfache Cron). Wenn ein Benutzer ein wiederkehrendes Ereignis verschiebt, werden alle anderen Instanzen dieses Ereignisses auf dieselbe Weise verschoben (z. B. +3 Tage). Wichtiger Teil: wiederkehrende Ereignisse können Ausnahmen haben. Nehmen wir zum Beispiel an, dass ich ein wiederkehrendes Ereignis A habe, das alle 7 Tage wiederholt wird. Aber ich möchte das Datum für die nächste Woche ändern, also wird es statt Dienstag am Freitag zugewiesen, danach am Dienstag. Dieses "Ausnahme" -Ereignis sollte nicht beeinflusst werden, wenn das "Eltern" -Ereignis verschoben wird.

Auch jedes wiederkehrende Ereignis kann zusätzliche Informationen haben, die nur auf eine bestimmte Instanz bezogen sind, zB: Ich habe das gleiche wiederkehrende Ereignis A, das alle 7 Tage wiederholt wird. Ich möchte eine Notiz für diese Woche hinzufügen. X ", und ich möchte eine weitere Notiz für das Ereignis A nächsten Monat hinzufügen, die" Y "sagt - diese Felder sind nur für diese einzelnen Instanzen sichtbar.

Ideen

-System mit regelmäßigen, sind einmalige Ereignisse ziemlich einfach so, dass ich nicht diskutieren werden und nur Ereignisse auf wiederkehrenden konzentrieren.

1. Eine mögliche Lösung ist die, die OOP ähnelt: I mit Feldern eine Event „Klasse“ haben kann wie start_date, end_date (null sein kann), recurrence_type (so etwas wie Enum mit möglichen Werten von EVERY_X_DAYS, DAY_OF_WEEK, DAY_OF_MONTH) und recurrence_value (zB 7). Wenn der Benutzer ein neues wiederkehrendes Ereignis hinzufügt, erzeuge ich einfach Event in der Datenbank. Wenn der Benutzer 1 Vorkommen dieses Ereignisses ändern möchte, füge ich dem DB des Typs/der Klasse MovedEvent einen neuen Eintrag hinzu, der von Event mit unterschiedlichem Datum "erbt" und das zusätzliche Feld related_to hat, das auf die ID (oder) zeigt) der Event, mit der es verwandt ist. Aber zur gleichen Zeit muss ich alle MovedEvent s verfolgen (sonst hätte ich 2 Ereignisse in der gleichen Woche angezeigt), also muss ich ein Array moved_events von ID s haben, das auf alle MovedEvent s zeigt. Nachteil: jedes Mal, wenn ich den Kalender anzeigen möchte, muss ich Event und wählen Sie alle Ereignisse aus der moved_events, die nicht optimal ist, wenn ich viele bewegte Ereignisse haben werde.

2. Eine andere Idee ist, jedes Ereignis als separaten Datensatz zu speichern. IMO, es ist eine schreckliche Idee, aber ich erwähne es nur, weil es eine Möglichkeit ist. Nachteile: jedes Mal, wenn ich das Hauptereignis bearbeiten möchte (z. B .: Ich möchte das Ereignis von "alle 7 Tage" auf "alle 9 Tage" ändern), muss ich jedes einzelne Vorkommen des Ereignisses ändern. "Ausnahmen" (Ändern einzelner Instanzen) ist jedoch einfacher.

SQL/NoSQL? Maßstab Details

Ich verwende PostgreSQL in meinem Projekt, aber ich habe Grundkenntnisse in NoSQL-Datenbanken und wenn sie besser für diese Art von Problem geeignet sind, kann ich es verwenden.

Maßstab: Sagen wir, ich habe 5k Benutzer, und jeder wird im Durchschnitt 150 Ereignisse/Woche haben, 40% davon können "Ausnahmen" sein. Deshalb möchte ich dieses System so gestalten, dass es effizient ist.

ähnliche Fragen & Weitere Ressourcen

Ich habe gerade angefangen zu lesen Martin Fowler „Recurring Events für Kalender“ (http://martinfowler.com/apsupp/recurring.pdf), aber ich bin mir nicht sicher, ob es für mein Problem gilt und wenn ja, wie man würde Datenbankschema entsprechend diesem Dokument entwerfen (Vorschläge sind willkommen).

Es gibt ähnliche Fragen, aber ich sah keine Erwähnung von „Ausnahmen“ (Wechsel 1 Ereignisinstanz ohne andere zu beeinflussen), aber vielleicht jemand diese Links hilfreich:

Sorry für eine lange Frage, ich wollte auch das Problem beschreiben. Trotzdem finde ich das ziemlich chaotisch. Wenn Sie weitere Fragen haben, werde ich Ihnen gerne weitere Details geben. Auch hier möchte ich gerne Informationen zu möglichen Datenbank-/Schemadesignideen und anderen Vorschlägen erhalten. Vielen Dank!

+0

hey kann Ihre Erfahrung teilen, wie Sie diese oder einige Tipps für die Implementierung umgesetzt haben. – user3775217

+1

Hallo, ich habe es auch mit diesem Problem zu tun. Ich habe mich entschieden, für jedes wiederholte Vorkommnis die stumpfe Lösung separater Ereigniseinträge zu verwenden. Mein Ereignissystem verfügt über Aktivitäten wie RSVPs, Zahlungen und Kommentare für jedes Ereignis, und jedes Ereignis muss seine eigene eindeutige Ereignis-ID mit der höchsten Priorität haben. Dies allein macht meine Wahl einfach, ich muss jedes Ereignis separat speichern. Auf der positiven Seite tritt meine Benutzerbasisaktivität nur einige Monate auf einmal auf, so dass ich eine automatische Ablaufregel (z.B.3 Monate maximal), wodurch DB-Bearbeitungszeiten überschaubar bleiben. – MarsAndBack

Antwort

5

Verwenden iCalendar RRules und ExDates

Wenn es ein wiederkehrendes Ereignis ist, speichern nur die Start/End Datetimes und RRules und ExDates für die Veranstaltung.

Verwenden Sie eine materialisierte Ansicht, um bevorstehende tatsächliche Ereignisse vorauszusagen, etwa für die nächsten 30 Tage oder 365 Tage.

Wie Sie Postgres verwenden, können Sie vorhandenen Python, Perl oder JavaScript RRULE Bibliotheken (wie dateutil) innerhalb pg Funktion für auf dem rrules zukünftige Ereignisse, die Berechnung und exdates

UPDATE: check out pg_rrule Erweiterung : https://github.com/petropavel13/pg_rrule

+4

ExRules sind in RFC 5455 veraltet (der eine Link). ExDates werden jetzt verwendet, um Ausnahmen für RRules zu erstellen. ExDate wird jedoch ab diesem Kommentar nicht von pg_rrule unterstützt. [Es gibt ein offenes Problem] (https://github.com/petropavel13/pg_rrule/issues/3) – austinian