Pianifica attività impedisce la notifica duplicata

3

Sto creando attività pianificate che vengono eseguite su base giornaliera per monitorare gli eventi di sistema e inviare notifiche via email in base a determinati criteri. Ad esempio, se la sottoscrizione utente scadrà dopo un mese, l'utilità di pianificazione rileverà il risultato confrontando le date e quindi inviando una notifica via e-mail. Ci sono molti compiti che ascoltano molti eventi accaduti nel sistema, molti dei quali controllano le date.

Voglio assicurarmi di non inviare questa email il giorno successivo, perché la condizione è ancora valida e sarà valida tutti i giorni fino a quando (ad esempio, l'utente aggiorna il suo abbonamento).

Sto cercando un design che impedisca all'utilità di pianificazione dell'invio di inviare e-mail se già inviato.

Il mio approccio è creare la tabella Evento che contiene chiavi esterne da varie tabelle e verificare se esistono combinazioni di chiavi con un tipo di evento specifico e viene notificato. se è così, non lo notificherò di nuovo.

Con questa progettazione, l'attività si verificherà eventType = 'subscription_expire' e companyId = [id] e seriviceid = [id] se già esistono.

Mentre l'attività due controllerà eventTyp = 'notPaidInvoice' e productId = [id] e companyId = [id] esistono già o meno.

Non mi piace il design a causa di molte chiavi esterne coinvolte e mancanza di scalabilità se vengono aggiunte nuove attività e regole.

C'è un approccio standard o popolare per gestire queste situazioni?

    
posta user968159 15.08.2016 - 14:09
fonte

1 risposta

1

Un'altra opzione sarebbe quella di calcolare un insieme comune di campi per tutti gli eventi. Ad esempio potrebbe essere {id, eventType, occurenceDate} . Quindi puoi creare una tabella con queste tre colonne e con una colonna di testo in più evendData che conterrebbe JSON o XML con i parametri degli eventi serializzati. Inoltre, puoi avere un'altra colonna che conterrà un HASH di quel JSON o XML. Quella colonna può essere indicizzata e utilizzata per la ricerca rapida.

Il vantaggio di questo approccio:

  1. Puoi aggiungere in modo flessibile nuovi eventi.
  2. Non è necessario mantenere molte colonne NULL per eventi in cui tali colonne non sono utilizzate.
  3. Ricerca rapida tramite HASH per verificare se è stato eseguito un evento con gli stessi parametri. È sufficiente un solo indice per cercare un evento.

Pochi svantaggi che mi viene in mente:

  1. Se si aggiunge un nuovo parametro all'evento esistente, è necessario aggiornare i record precedenti con il nuovo JSON / XML e ricalcolare HASH. Ma immagino che dovresti fare lo stesso con il tuo progetto attuale.
  2. Devi assicurarti che la serializzazione dei parametri restituisca risultati coerenti ogni volta che serializzi gli stessi parametri, quindi l'HASH è sempre lo stesso per lo stesso set di parametri.
  3. Nessuna verifica dei vincoli di chiave esterna, sebbene potrebbe non essere un problema.
risposta data 15.08.2016 - 18:13
fonte

Leggi altre domande sui tag