Sistemi multiutente e CRUD

Di solito ci sono quattro opzioni per gestire la manutenzione dei dati collaborativi in un sistema multiutente:

1. Basta sovrascriverlo. Elabora senza problemi le richieste nell'ordine in cui arrivano al server. Quando l'utente B tenta di aggiornare un elemento che l'utente A ha appena cancellato, basta dare un messaggio di errore "questo elemento non esiste". Quando l'utente A e l'utente B aggiornano lo stesso oggetto con pochi millisecondi, si prende l'ultimo. Semplice, grezzo e incline agli errori, ma può essere appropriato in alcune situazioni.
2. Blocco e sblocco. Prima che un utente possa aggiornare un record, per prima cosa deve bloccarlo. Solo un utente alla volta può avere un set di dati bloccato. Quando qualcun altro tenta di bloccarlo, viene visualizzato un messaggio di errore "L'utente XYZ sta attualmente modificando questo elemento". Quando salvano i dati (o annullano la modifica), il set di dati è sbloccato.
3. Controllo delle versioni e risoluzione dei conflitti. Ogni volta che un utente salva un elemento, viene creata una nuova versione. Quando qualcun altro ha creato una versione in conflitto nel frattempo, eventuali differenze vengono mostrate all'utente e possono decidere come risolvere i conflitti.
4. Modifica collaborativa in tempo reale. Gli utenti ricevono una notifica quando un altro utente modifica lo stesso elemento. Possono vedere i cursori e le selezioni degli altri. Le modifiche appaiono sugli schermi degli altri in tempo reale. (ad es. Etherpad )

Quale soluzione è la migliore dipende dalle esigenze della tua azienda. L'aspetto più importante è solitamente il tempo impiegato dagli utenti per aggiornare un record. Quando è questione di secondi, preferiresti la prima opzione. Quando è questione di minuti, preferiresti la seconda opzione. Quando un aggiornamento può richiedere un'ora o più, preferiresti la terza opzione.

La quarta opzione può essere davvero utile per alcuni tipi di lavoro altamente collaborativo, specialmente in un ambiente in cui gli utenti non possono comunicare direttamente. Ma non è sempre appropriato. Può anche essere molto difficile da implementare in modo user-friendly. Potresti anche voler aggiungere un canale di meta-comunicazione, in modo che gli utenti non debbano comunicare scrivendo nei dati stessi (" Description: This item is a PETER GO AWAY I WAS HERE FIRST!! ").

Oltre alla risposta di Philipp ce n'è un'altra che uso in parecchi sistemi che non sono la versione e l'override.

È un po 'come il # 1 e il # 2 combinati.

Supponiamo che tu abbia un corpo di testo, tu md5 (o CRC, o qualcos'altro a buon mercato, io utente aggiornato_a) il tuo record. Quindi invia questo con il record. Quindi, come il record ritorna se quel "hash" non corrisponde, allora un altro parametro "override" deve essere incluso.

Quindi, ad esempio, hai un documento, ha il corpo e l'hash.

Quando pubblichi il documento,

• se l'hash corrisponde (nessuna modifica), solo la scrittura cieca.
• se l'hash non corrisponde (cambia) quindi genera un errore (dal quale il modulo del documento può funzionare)
• se l'hash non corrisponde AND è presente il parametro override, write cieco

Funziona bene quando hai un cambiamento che potrebbe prendere un astuzia, quindi non vuoi solo scrivere cieco, ma quando la maggior parte delle volte è esattamente ciò che accade comunque.

Funziona bene anche con JSON o altri trasporti. Può essere contenuto interamente nel livello dati (il livello dell'interfaccia utente dell'utente deve visualizzare l'errore, ovviamente, ma il controllo e l'override sono nei dati) ed è retrocompatibile con i client / front end che non supportano l'override (hanno solo ottenere un errore) e funziona MOLTO bene quando gli utenti stanno combattendo l'automazione (ad esempio, le importazioni).