Devo conservare le date o le regole di ricorrenza nel mio database durante la creazione di un app calendario?

Question

Sto costruendo un calendario del sito (ASP.NET MVC) applicazione (si pensi semplice versione di outlook) e voglio iniziare a sostenere gli eventi di calendario che sono ricorrenti (mensile, annuale, ecc.)

adesso io sono la memorizzazione di date effettive nel mio, ma volevo capire se, con la ricorrenza, ha senso continuare a memorizzare le date (con qualche evidente taglio), o devo conservare le opzioni di ricorrenza e di generare le date sul fly.

Mi ha fatto pensare come outlook, google mail, ecc, non di questo o di qualsiasi altro servizio che supporta gli elementi ricorrenti del calendario.

Ci sono suggerimenti su questo?

Answer 1

separare i dati in due parti: i dati "canonici" (la regola di ricorrenza) e "servire" (generato date; sola lettura a parte la rigenerazione). Se i dati vengono modificati canoniche, rigenerare i dati "che servono" a quel punto. Per infinite ricorrenze, mantenere un po 'il numero di istanze e generare più se si esegue fuori (ad esempio, se gli sguardi degli utenti al loro calendario per il 2020).

Se si ha la velocità del processore infinita, si avrebbe solo bisogno i dati canoniche - ma in realtà, facendo tutto il processo di data / ora per tutte le regole di ricorrenza di tutti visualizzazione di una pagina è probabile che sia troppo tempo ... quindi è il commercio fuori alcuni di stoccaggio (e complessità) per salvare che il calcolo ripetuto. Lo storage è di solito piuttosto a buon mercato, rispetto al calcolo necessaria per un gran numero di eventi. Se solo necessità di memorizzare le date degli eventi, è davvero molto a buon mercato - si potrebbe facilmente utilizzare un intero 4 byte per rappresentare una data, e quindi generare un completo data / ora da quello, supponendo che il recidive sono tutti data base. Per ricorrenze basati sul tempo (ad esempio "ogni tre ore") si potrebbe istanti pieni UTC - 8 byte rappresenterà che fino a una risoluzione piuttosto bene per tutto il tempo è molto probabile che necessità

.

È necessario essere attenti a mantenere la validità anche se - se una modifica riunione ricorrente oggi , che non cambia quando si ha è successo in passato ... così probabilmente avrete bisogno di anche sono canonica di sola lettura dei dati su quando ricorrenze realmente accaduti. Ovviamente non si vuole che per mantenere il passato per sempre, quindi probabilmente si vuole "Garbage Collect" eventi più di pochi anni, a seconda delle limitazioni di storage.

Si può anche avere bisogno la possibilità di aggiungere note e le eccezioni (ad esempio, "incontro non avviene oggi a causa di un giorno festivo" o "si trasferisce a 4:00") su base per-occorrenza. Che diventa davvero divertente quando si cambia la ricorrenza - se si cambia "ogni Lunedi" a "ogni Martedì" si fa a mantenere le eccezioni o no? Come si fa anche abbinare le eccezioni quando si passa da "ogni giorno" a "ogni settimana"? Queste non sono domande che sono direttamente sullo stoccaggio - ma le decisioni di archiviazione influenzerà quanto è facile da implementare ciò che la politica a decidere quale

.

Answer 2

Sarà necessario gestire separatamente eventi e ricorrenze.

EVENTO WISE: Per gli eventi, è necessario memorizzare le regole REITERAZIONE (che può essere un RRULE come specificato dal rfc5545, ma anche un insieme esplicito di date come rdate in rfc5545), ma anche delle eccezioni (vedi exdate di rfc5545 e possibilmente exrule come in RFC2445). Sarà inoltre necessario tenere traccia delle modifiche di queste regole: Variazioni rdate, exdate non sono un problema quando si verificano in futuro e per essere ignorati per date passate. Le variazioni di RRULE sono più difficili da incidere occorrenze precedenti. La mia preferenza personale è quello di aggiungere una proprietà specifica per il vecchio e il nuovo RRULE per specificare il loro rispettivo inizio e fine data di validità.

se l'evento ha un arco di tempo limitato (ad esempio COUNT o fino a quando proprietà sono presenti) è necessario memorizzare il suo inizio e la fine della tabella per facilitare l'esecuzione di query di eventi (soprattutto quando alla ricerca di occorrenze fuori della vostra finestra di tempo precalcolata (vedi sotto ), può contribuire a ridurre il numero di eventi per i quali il calcolo è da rifare).

EVENTI WISE: per occorrenze è necessario memorizzare le istanze all'interno di una finestra predefinita intorno presenti (dici +/- 6 mesi o 12 mesi e calcolato su base regolare) e tenere un registro di questo per consentire ricalcolo se gli utenti vogliono vedere ulteriormente in futuro (per problemi di prestazioni). si dovrebbe anche prendere in considerazione il calcolo dell'indice (REITERAZIONE-ID) per aiutare più facile ritrovamento della prossima occorrenza.

meno sul back-end, ma più sul front-end si dovrebbe anche tenere traccia delle modifiche tzid per chiedere all'utente se un evento che è stato programmato su un dato tzid se si intende per soggiorno sulla fuso orario corrente di esso ha bisogno di essere aggiornato (si pensi a qualcuno nell'isola di Samoa che aveva calendario una riunione il Venerdì 30 Dicembre, 2011 prima che il paese ha deciso oggi non esisterebbe), allo stesso modo si può chiedere se un evento che accade durante l'ora legale si intende a "mai accadere" o "accadere due volte" (più su questo argomento qui )

Nota: si può prendere in considerazione il sostegno al di là di ciò che viene definito in rfc5545 in termini di regole REITERAZIONE e anche aggiungere il supporto per le regole religiose ricorrenti ( vedi l'introduzione USNO ai calendari o in stampa "Calcoli Calendrical"(terza edizione) da E. e N. Reingol Dershowitz).

Dal momento che tu chiedi implementazione esistente, è possibile controllare facilmente lo schema del database di Sunbird (SQLite) o della di Apple open source calendario e contatti Server , un elenco più completo dei progetti open source esistenti per i server CalDAV (che è probabilmente un sottoinsieme di ciò che si sta cercando) è disponibile qui )

Answer 3

ho dovuto costruire un sistema che ha lavorato con la pianificazione e abbiamo fatto entrambe le cose. Ecco quello che avevamo

• una serie di tabelle che tenevano traccia del programma.
• una tabella che teneva traccia delle precedenti istanze del programma (quando effettivamente verificato)
• una tabella che teneva traccia dell'ultimo e istanza successiva (quando la prossima voce è dovuto a verificarsi in base l'ultima volta) Non avete bisogno di questo tavolo, ma abbiamo usato, perché altrimenti si sarebbe essere costantemente calcolando se un elemento dovrebbe essere succedendo adesso

Con la pianificazione, le cose possono diventare davvero difficile perché si deve ricordare che in qualsiasi punto nel tempo, il programma può cambiare. Inoltre, un elemento può essere dovuto quando l'applicazione non è in esecuzione, e quando inizia di nuovo, è necessario sapere come identificare SCADUTE.

Inoltre, abbiamo fatto in modo che le tabelle che tenuto traccia del programma vero e proprio in piedi da solo. La ragione di questo è che quelli erano i più complessa serie di tabelle nel sistema e volevamo essere in grado di riutilizzarli in modo che possano essere utilizzati per cose diverse che necessario di pianificazione. Come ad esempio l'invio di messaggi di posta elettronica di amministrazione, l'invio di notifiche e la manutenzione del server, come la pulizia dei file di log.

Answer 4

avrei sicuramente usare il vostro seconda opzione. Utilizzare diverse opzioni di ricorrenza, conservarla separatamente e calcolare al volo. Memorizzazione di tutte quelle date sarebbe una barca di dati che non è necessaria.

Ecco una buona risposta per completare la vostra domanda.
Struttura dei dati per la memorizzazione di eventi ricorrenti?

Inoltre, come nota a margine. Ho iniziato la memorizzazione di tutto come ora UTC in modo da avere una base comune, se mai hai bisogno di usare di più fusi orari.

Answer 5

Ho avuto un problema simile in un web-application che ho fatto qualche anno fa (ci potrebbe essere un modo migliore adesso :)). Ho voluto inserire un programmatore che aveva tutte le funzionalità di eventi ricorrenti, tempo di maniglia, giorni, settimane, mesi, anni, e le eccezioni, in modo che io possa avere regole come:

1) tutti i giorni alle ore 10 Excepted mercoledì

2) Ogni 2 ore con un massimo di 4 iterazioni al giorno

3) ogni primo Lunedi del mese

etc ..

Memorizzazione le date ricorrenti / orari era possibile, ma inflessibile. Ogni iterazione del vostro evento cambia quando la "massima" sarebbe. E come molto più avanti cerchi?

Alla fine ho scritto una classe pianificazione personalizzata in grado di leggere e scrivere su una stringa. Questa è stata la stringa che è stata memorizzata nel database e quindi una semplice funzione può essere chiamato per sapere quando l'occorrenza successiva è.

Answer 6

è necessario memorizzare alcuni di loro di sicuro. L'utente potrebbe modificare uno degli eventi, lasciando gli altri intatti. (Probabilmente incontrato la domanda: "? Vuoi modificare tutti gli eventi ricorrenti o solo questo" in alcuni calendari, vale a dire Windows Mobile)

È inoltre possibile archiviare eventi passati e non rimuoverli quando l'utente elimina l'evento ricorrente.

Se si memorizzano tutti gli altri o li genera è un dettaglio di implementazione. Io preferirei generarli, se possibile.

In ogni caso si vuole avere qualche ID dell'evento ricorrente memorizzato con ogni evento, oltre ad alcuni bandierina che indica se l'evento è stato modificato in seguito. O in approccio più complicato, una bandiera per ogni proprietà raccontare eventi, se il suo valore di default (dalla manifestazione ricorrente) o se è stato modificato per questo caso particolare. Avrete bisogno di questo quando l'utente decide di modificare l'evento ricorrente.

Answer 7

Nota che la maggior parte delle risposte magra verso il salvataggio di dati generati.Ma assicurati di prendere in considerazione il vostro caso d'uso.

Nei giorni miei server sono stati limitati dal io con un sacco di cpu non fare nulla.Oggi si dispone di ssd (se si può permettersi quelle, altrimenti a sinistra, con una vecchia filatura hd), ma nota che il numero di core è aumentato troppo.

La cosa bella di questi tipi di calcoli che si possono dividere facilmente e dare loro il tuo numero di core o anche a un buon server in una rete locale.Spesso più conveniente rispetto all'impostazione di un nosql cluster o andando l'intero cluster di database modo.

E l'alternativa potrebbe anche essere una cache, solo cache la visualizzazione del calendario, non c'è bisogno di fare tutti i calcoli ogni volta che non è cambiato nulla.

Ma, come detto, dipende dal tuo caso d'uso.Non basta seguire le risposte di cui sopra, ma fare i vostri calcoli se avete tempo e di prendere una decisione.