Mysql
 sql >> Database >  >> RDS >> Mysql

Design ottimale per un Database con eventi ricorrenti

Vorrei solo creare una voce per ogni ricorrenza dell'evento, verso un orizzonte. Tuttavia, significa che avrai bisogno di un'altra tabella che puoi utilizzare per proiettare le date se scansionano oltre la data dell'orizzonte. Vale a dire, avrai bisogno di una tabella degli eventi che contenga un record per ogni occorrenza di un evento ripetuto (1 gennaio, 8 gennaio, 15 gennaio, ... fino a dicembre) e una tabella con ogni record disponibile per il seeding degli anni futuri (inizio data:1 gennaio; ripetere:7; fino a:2011) in modo che all'inizio del 2012 (o non appena l'utente richiede la visualizzazione di un mese 2012+) è possibile generare gli eventi futuri.

Questo ha due grossi svantaggi:

  1. Il tuo database contiene dati per un anno intero. Tuttavia, se l'aggiunta di un intero anno di dati rovina le tue prestazioni, il tuo sistema è probabilmente sottodimensionato. (Sembra un requisito che un'app di calendario sia in grado di gestire molti anni di date)
  2. Alla fine dell'orizzonte degli eventi, devi generare le date future per gli eventi ricorrenti.

I vantaggi (IMO) che superano gli svantaggi:

  1. Matematica più semplice durante la visualizzazione del calendario. Usando il metodo di Tim, sopra, se l'utente carica il 18 dicembre 2011, come calcolerai quali eventi ricorrenti dovrebbero essere inseriti in quel giorno? Sarai costretto a scorrere OGNI evento ricorrente ogni volta che visualizzi una data. Il compromesso è lo svantaggio n. 1, che penso sia la soluzione migliore rispetto a dover rifare questi calcoli.
  2. Puoi modificare istanze specifiche di un evento. Utilizzando il metodo di Tim, se un incontro avvenisse in un giorno festivo e l'utente lo cambiasse al giorno precedente, come lo faresti? Usando il metodo di una voce per evento qui descritto, potresti semplicemente modificare quel record per l'evento, spostando facilmente singole occorrenze nel calendario.