Schema / Codice per rispettare i diversi programmi

Quindi, qualsiasi fornitore di lead può inviare lead al tuo sito se l'ora corrente rientra in una delle tue pianificazioni, purché a tale lead provider sia permesso di pubblicare lead all'interno di tale pianificazione? Quanto sopra è vero a meno che l'ora corrente non sia un'eccezione?

Se è quello che stai chiedendo, allora direi che ci sono diverse tabelle di database che dovranno esistere:

1. LeadProvider (Nome, ID univoco, ecc.)
2. Pianificazione (data di inizio, data di fine, ora di inizio, ora di fine)
3. Tabella link / bridge che collega la tabella LeadProvider alla tabella Schedule (un record in questa tabella con riferimenti a chiavi esterne alle tabelle 1 e 2 indica che un leadprovider può pubblicare lead in questo periodo
4. Tabella delle eccezioni - assomiglia alla tabella di pianificazione, ma ha anche un riferimento a una chiave esterna alla tabella di pianificazione e un record in questa tabella indica che a un leadprovider non è consentito pubblicare post sul tuo sito se l'ora corrente rientra in questa tempo di eccezione
5. Tabella lead - tiene traccia di un lead fornito da un LeadProvider - questo potrebbe anche essere usato per tenere traccia di se un lead pubblicato è caduto entro un tempo consentito.

Questo è qualcosa di abbastanza vicino a come vorrei costruire il lato del database. Il codice deve semplicemente supportare questo modello (se sto capendo correttamente la tua domanda)

Ci sono alcuni problemi che dovresti risolvere per risolvere il problema.

A.  Authentication
B.  Authorization

Dato che hai detto che il client ti sta inviando uno schema XML con le loro informazioni, spero tu abbia un metodo per autenticare il client in modo sicuro. Se stanno già tentando di bypassare la sicurezza, non passerà molto tempo prima che provino a impersonare altri client per continuare a bypassare la sicurezza.

Il problema B richiede che tu verifichi che l'utente è autorizzato a eseguire l'azione o "pubblica un lead". A seconda della progettazione del sistema, questo può essere semplice come

class User
{
  bool IsAuthorized(DateTime Now) { }
}

controlla prima di eseguire l'azione. Dovresti anche definire come funzionerà il tempo. È tutto il tempo standard centrale, orientale ...? Il cliente deve essere consapevole di questa limitazione e idealmente avvisato tramite un messaggio di errore.

Vorrei separare i dati usati per definire il programma dai tempi di pianificazione generati - probabilmente la logica per definire un programma cambierà molto, ma probabilmente la logica per dire se un dato orario cade in un programma probabilmente no. Tuttavia, è ancora ragionevole archiviare solo la definizione della pianificazione se si ritiene di poter incapsulare la logica per determinare se un determinato periodo di tempo rientra in una pianificazione. Se il controllo avviene principalmente al di fuori di un DB, questo potrebbe non essere un problema, ma se scriverai un sacco di SQL che ha bisogno di sapere questo, ha bisogno di usare gli indici, ecc. Allora è più difficile e sarà più probabile che tu voglia orari di pianificazione generati.

Per le tabelle generate, Tim Claason ha uno schema ragionevole. Per le tabelle che creano la pianificazione, registreranno praticamente le opzioni inserite da una schermata di immissione dati. Questi possono cambiare - giorno della settimana, giorno del mese, saltare le festività, saltare le vacanze ma lasciare che le persone vadano il giorno dopo una vacanza se potessero andare in vacanza - chissà cosa sognano le persone? Avrei quindi un processo che legge le definizioni e fa saltare la data / ora di inizio del programma - i record di data / ora di fine per un fornitore leader per un intervallo di date nel futuro.

Questo potrebbe essere eccessivo se le regole sono semplici, ma sembra che siano ragionevolmente complicate.