Come salvare molte modifiche ai dati del database?

Puoi tenere traccia di quali righe l'utente ha modificato utilizzando l'id per quella riga. Quindi, aggiorna la riga che è stata cambiata. Questa dovrebbe essere una ottimizzazione del primo passo abbastanza semplice e può essere implementata in molti modi diversi.

Sono preoccupato per le dimensioni dei dati che stai inviando all'utente. È davvero necessario? Normalmente gli utenti sono limitati a vedere molto meno di 1000 righe alla volta.

La rimozione di massa e l'inserimento di massa di record è un'operazione eseguita in quello che è noto come "tempo di macchina" (veloce quanto la macchina può farlo) e che potrebbe, forse, sotto un po 'di immaginazione, consumare l'intero numero di numeri interi a 32 bit delle chiavi generate automaticamente.

Ma molto più ragionevole della rimozione di massa e dell'inserimento di massa è una strategia solo per l'aggiornamento, che è stata modificata, (come suggerito da Paul Nikonowicz), il che significherebbe che l'inserimento e la rimozione avverrebbero solo singolarmente, a tempo umano, (veloce come un umano può farlo), il che a sua volta significherebbe che ci vorrebbe un utente per molti secoli di clic e digitazioni continue per causare inserimenti sufficienti per utilizzare lo spazio numerico intero a 32 bit disponibile.

Inoltre, ovviamente, è sempre possibile eseguire l'aggiornamento a chiavi a 64 bit, nel qual caso non si hanno problemi, qualunque cosa si faccia. O anche i guids a 128 bit, se ti piace l'overkill.

La modifica di ogni singola riga modificata, incluso il tenere traccia delle cancellazioni e delle aggiunte, non è una ricetta per gli errori, è la cosa più ragionevole, ragionevole da fare.

Una tecnica che ho usato per modificare e riordinare un numero arbitrario di record è di unire / espandere le righe, mantenendo gli ID auto-incrementati e usando una colonna separata per gestire l'ordinamento. L'ordinamento viene tracciato dall'applicazione front-end e passato come parametro di query aggiuntivo al momento del salvataggio dei record, consentendo l'inserimento di nuovi record in qualsiasi posizione dall'applicazione. Per MySQL, usa la sintassi INSERT INTO... ON DUPLICATE KEY UPDATE .

Alcune opzioni che prenderei in considerazione (non scelte esclusive):

• usa il codice che effettivamente fa un UPDATE quando il record esiste già. L'utente sta aggiornando il record in modo che un'istruzione UPDATE corrisponda meglio dell'eliminazione e reinserimento manuale che è irto di pericoli e soggetto ad errori.
• utilizza una tabella temporanea (con la stessa struttura tabella) per archiviare le transazioni che vengono presentate all'utente, più eventuali modifiche apportate durante la modifica. Quando infine salveranno, eseguiranno tutte le convalide sui record in questa tabella e quindi li applicheranno alla tabella di base.
• utilizzando una tabella di controllo per archiviare i record eliminati prima di eliminarli.
• contrassegna i record come eliminati in sospeso ora e quindi hanno un processo in background eseguito a intervalli appropriati (potrebbe essere orario, potrebbe essere mensile, dipende dalla necessità) per eliminarli (o archiviarli) effettivamente.

Assicurati, se il tuo database lo consente, di creare e applicare vincoli di chiave esterna, in modo da non lasciare i record "ciondolanti" mentre menzioni. Mantenere un database relazionale in buona forma quando si eliminano i record è solo una delle pratiche che è necessario imparare e applicare quando si utilizzano i database.

Inoltre, in particolare nel caso di eliminazione e reinserimento, se si utilizza un GUID abbastanza grande, milioni di record al secondo non rappresentano un problema. Ottenere id unici non dovrebbe essere un problema che guida la tua progettazione architettonica.