Bloccaggio ottimistico con vincoli di business [chiuso]

Sembra che tu stia cercando un vincolo di unicità su un intervallo di tempo. In alcuni DBMS come PostgreSQL puoi dichiarare dichiarativamente vincoli sugli intervalli . In altri DBMS non è possibile un vincolo dichiarativo e è necessario un approccio imperativo, come l'uso dei trigger.

In entrambi i casi, un'implementazione corretta che consideri la concorrenza multiutente includerà blocchi per impedire doppie prenotazioni. In questo caso, un blocco esclusivo sul record "tavolo da pranzo" al quale si applica la prenotazione potrebbe essere preso prima che venga effettuato il controllo relativo alle sovrapposizioni per garantire che una sola prenotazione venga elaborata in qualsiasi momento.

Tuttavia, nel caso generale potrebbe non esserci un record esistente adatto da bloccare per controllare la concorrenza. Inoltre, il blocco dei record padre per controllare l'accesso ai record figlio può essere considerato troppo zelante poiché serializza inutilmente l'accesso ad alcune risorse quando non è necessario. In questo caso possono essere utilizzati blocchi esplicitamente denominati, ad esempio un blocco denominato "TABLE_BOOKING_ [TABLE_ID] " che utilizza funzionalità come advisory lock in PostgreSQL o DBMS_LOCK in Oracle.

Per un controllo ottimistico della concorrenza potrebbe esserci un numero di versione della prenotazione sul record della "tavola della cena" che viene incrementato ogni volta che viene inserita o aggiornata una prenotazione associata. È possibile utilizzarlo quando si verificano sovrapposizioni nelle prenotazioni per assicurarsi che non siano state apportate modifiche tra il recupero dei dati di prenotazione esistenti per verificare la presenza di sovrapposizioni e la prenotazione effettiva. Una prenotazione non sarebbe consentita se fossero state apportate modifiche tra il recupero e il salvataggio e un errore segnalato.

Supponiamo che tu abbia una tabella Table (principale) e una tabella Bookings (dettaglio). Le prenotazioni hanno alcuni attributi come

• BookingID
• TableID
• StartDateTime
• data_ora_fine
• Nome del booker ecc.

Supponiamo inoltre che le prenotazioni possano essere raggruppate "di giorno" (il ristorante avrà probabilmente orari di chiusura regolari, e le prenotazioni non saranno consentite quando si sovrappongono a tali orari di chiusura).

Quindi organizza le tue transazioni in modo che tutte le modifiche al set di record di prenotazione per una tabella specifica e un giorno specifico vengano eseguite in una transazione , che

• cancella tutte le prenotazioni esistenti per quella tabella e il giorno

• scrivi i record di prenotazione che rappresentano la nuova pianificazione per la tabella e il giorno

Se subisci una collisione, hai bisogno di una strategia per gestirla, come "prima arriva prima" o qualcosa del genere, ma non dovresti mai imbatterti in una situazione in cui ci sono prenotazioni sovrapposte nel database.

Una variazione di tale strategia potrebbe funzionare anche quando il ristorante non ha orari di chiusura. Caricare sempre tutte le prenotazioni di un tavolo e modificarle contemporaneamente, in un'unica transazione, in teoria potrebbe risolvere il problema, ma questo diventa rapidamente poco pratico se si devono sempre scrivere tutte le prenotazioni degli ultimi 5 anni per un tavolo, per ogni lieve cambiamento al programma. Tuttavia, limitando le modifiche solo alle prenotazioni future e proibendo qualsiasi modifica alle prenotazioni precedenti, questa diventa una strategia di lettura, modifica e commit dell'intero programma futuro in una sola volta. Questo dovrebbe funzionare, anche se il set di prenotazioni di un tavolo non può essere facilmente tagliato in sottoinsiemi indipendenti di giorno.