9
Preferisci usare un numero di versione (che incrementerà) o un timestamp per verificare i problemi di concorrenza?Numero di versione o data/ora per concorrenza ottimistica?
A
risposta
11
Il numero di versione è migliore perché non importa quale formato di tempo si utilizza, può ancora essere eliminato se l'orologio del server è sbagliato o diventa errato nel tempo.
Devo ammettere che in molti database ho usato un timestamp perché può servire a un duplice scopo di controllo della concorrenza e di leggibilità per quando i dati sono stati modificati l'ultima volta. Tuttavia, l'utilizzo di un numero di versione è davvero il modo migliore per andare.
3
Numero versione. O se sto usando il timestamp, mi assicurerò che sia UTC - quindi non c'è confusione con il fuso orario.
3
Vorrei usare un numero di versione, in particolare se la risorsa potrebbe mai essere aggiornata più della risoluzione dei tuoi timestamp (ad esempio se stai memorizzando i timestamp a una risoluzione di secondi, se hai più aggiornamenti in un solo secondo , la tua versione verrà interrotta).
4
Lieven,
so non è stato specificato di SQL Server, ma se si sta parlando di SQL Server quindi il tipo di dati TimeStamp sarebbe il metodo migliore da utilizzare. Nonostante la sua descrizione, in realtà non ha nulla a che fare con la data e l'ora. In realtà è solo un numero binario che cambia ogni volta che la riga è stata modificata. Quindi, se vengono apportate modifiche alla riga, allora la colonna timestamp cambierà. Questo ha il vantaggio sui numeri di versione perché tu, il programmatore, non devi "mantenere" il numero di versione. I timestamp di data/ora effettivi devono essere utilizzati con maggiore attenzione come un altro poster a cui si fa riferimento prima - differenze temporali ecc.
+0
E a quale tipo devo mappare la data/ora in C#? Perché prima di un aggiornamento o eliminazione voglio verificare i problemi di concorrenza. (Sto lavorando con SQL Server in realtà. Flex-WebORB-.NET-SQLServer). Stiamo inviando dto's a Flex. In quel dto dovrò inserire il timestamp. Ogni volta che il dto torna a essere salvato, ho bisogno di chack se il timestamp nel dto corrisponde al timestamp nel database. Grazie. –
+0
Ecco alcune chat al riguardo: http://social.msdn.microsoft.it/Forum/it-it/adodotnetdataproviders/thread/0ad05e31-c3b2-44fb-99f5-32e80754e37a/ Tuttavia, hai considerato di consentire al server di gestire le versioni? Se utilizzi il blocco ottimistico, sarebbe il tuo inserto sql che rileverà un problema e genererà un'eccezione. – BIDeveloper
+0
Stavo per farlo, lasciando che lo sql insert rilevasse il problema. Ma hai bisogno di inviare il timestamp al cliente o no? Se stai inserendo devi confrontare il timestamp in db con il timestamp nell'oggetto. O mi sto perdendo qualcosa qui? –
0
Se si utilizza Windows, si consiglia di utilizzare un identificatore univoco globale (GUID) come identificatore di versione.
Un timestamp (anche se UTC) può causare problemi se l'orologio è impostato dall'utente. Un numero incrementale (se premuto in memoria) può causare problemi se l'applicazione server viene riavviata, o se è in overflow (se è solo un numero intero a 16 o 32 bit).
-1
Numero versione. DateTime non è univoco a causa di alcuni motivi, ad esempio "Ora legale" - potrebbero esserci due "2 AM" h. (Ambiguous Time).
Immagino che sia più che sufficiente numero intero a 32 bit senza segno, perché praticamente c'è una probabilità ZERO che potrebbe verificarsi durante il salvataggio della transazione 4.294.967.295.
Sì, idd, ho già una colonna ModifiedOn e stavo pensando di usarlo, ma consiglieresti una colonna in più? –
Sì. Per quanto odio avere un sacco di colonne in una tabella, è la soluzione più a prova di proiettile. – NYSystemsAnalyst
Beh, sono un po 'confuso a causa della risposta di Jim. Se TimeStamp cambia automaticamente quando si modifica la riga, allora è abbastanza utile. Cosa intendi con "può ancora essere buttato via"? thx –