Domanda Perché ASP.NET Identity 2.0 utilizza un GUID / stringa come ID utente?


Come dice il titolo, mi chiedo, perché ASP.NET Identity 2.0 utilizzi una stringa con un GUID come chiave cluster primaria per la tabella utente. Questo ha qualche vantaggio per un ID intero? Vedo solo il problema, che un GUID non è la scelta migliore per un indice cluster.

Mi manca qualcosa o è ancora un numero la scelta migliore?


23
2018-05-27 13:56


origine


risposte:


Per quanto riguarda l'uso di guid, c'è un punto di vista che promuove l'uso di id senza "significato" al fine di separare completamente l'identificatore dai dati che lo circondano; questo ID non dovrebbe essere visibile dall'esterno del datastore. Se guardiamo alcune caratteristiche di a chiave surrogata, abbiamo il seguente

  • il valore è unico a livello di sistema, quindi mai riutilizzato
  • il valore è generato dal sistema
  • il valore non è manipolabile dall'utente o dall'applicazione
  • il valore non contiene alcun significato semantico
  • il valore non è visibile all'utente o all'applicazione
  • il valore non è composto da diversi valori di domini diversi.

Quindi un guid va bene perché è effettivamente generato dal sistema e non ha alcuna relazione con il dominio. Penso che l'uso di un guid sia principalmente una questione di tendenza in questo particolare modo di pensare; tuttavia, poiché stanno introducendo un nuovo meccanismo di "chiave primaria estensibile", la chiave può essere cambiata, quindi è possibile fallback su un numero intero per il tuo PK.


Per quanto riguarda le prestazioni, ti indico a questo thread dove la risposta accettata dice:

GUID può sembrare una scelta naturale per la tua chiave primaria - e se   devi proprio, probabilmente potresti argomentare di usarlo per il PRIMARY   CHIAVE del tavolo. Quello che consiglio vivamente di non fare è usare il   Colonna GUID come chiave di cluster, quale SQL Server esegue per impostazione predefinita,   a meno che tu non lo dica espressamente.

Hai davvero bisogno di tenere separati due aspetti:

  • la chiave primaria è un costrutto logico, una delle chiavi candidate che identifica in modo univoco e affidabile ogni riga della tabella. Questo   può essere qualsiasi cosa, davvero - un INT, un GUID, una stringa - scegli ciò che rende   più sensato per il tuo scenario.
  • la chiave di clustering (la colonna o le colonne che definiscono l'indice "clustered" sulla tabella) - questa è una memoria fisica correlata   cosa, e qui, un tipo di dati piccolo, stabile e sempre crescente è tuo   scelta migliore: INT o BIGINT come opzione predefinita.

che confermano completamente la tua impressione.


20
2018-05-27 14:10



Le altre risposte sono eccellenti, tuttavia un vantaggio che non ho visto menzionato è quello Guid.NewGuid() (teoricamente) crea un ID univoco senza impegnare la riga nel database.

Una colonna Identity basata su un numero intero richiede un flush del database per ottenere l'ID. Ci sono alcune circostanze in cui è utile avere il PK per la tua riga generato nel codice e passato al database (ovviamente ci sono altri modi per ottenere questo con un vincolo univoco ma un Guid è un'opzione ragionevolmente buona).


5
2018-05-27 14:37



Suppongo che con "a un id" intendi un ID integrale sequenziale, dato che un UUID è dopotutto un ID.

Se nessuno utilizza Identity 2.0, o una versione futura, mai voluto unire insieme, o combinare più di un negozio, o mai importare utenti e / o ruoli, allora funzionerebbe un ID numerico.

Se solo poche persone lo fanno, o addirittura potrebbero, allora un UUID ha molto più senso.

C'è una discussione da fare per usare una chiave naturale, come ad esempio un nome utente, con i pro e i contro di ciò che è ben esplorato in generale. IIRC, lo hanno fatto davvero la prima volta.

In tutto, un UUID sembra una scelta ovvia.


2
2018-05-27 14:14



Un Guid come UserId (quindi chiave primaria) può essere a volte il tuo migliore amico.

Qualcosa da considerare quando la gente "urla" contro un GUID è che potrebbero non considerare applicazioni "occasionalmente connesse" in cui non è possibile colpire il database per ottenere il valore del campo di identità "int" fino a quando non si ricollega, ma è necessario creare più record in vari tavoli collegati insieme offline. Avere un Guid consente all'applicazione di creare un "utente" e quindi il "userId" come chiave primaria senza collisioni quando si esegue la sincronizzazione quando si torna online.

Per evitare colpi di performance, non inserire la guida nell'indice cluster. È sempre possibile utilizzare un campo univoco diverso come id del cluster o magari utilizzare un campo di identità intero aumentato di uno come "clusterId" e utilizzarlo.

Un altro motivo è quando si aggregano dati da molte fonti diverse, se l'ID utente (chiave primaria) è un Guid, è possibile evitare le collisioni.


2
2018-06-07 17:24



Come al solito, Microsoft pensa alla "semplicità" più che all'essere effettivamente utile e performante. Sì GUID è unico nel suo genere, sì, puoi testarlo senza scaricare nuovi ID dal database ... MA ...

Non sto nemmeno discutendo di indici DB che sono sicuro che molti pensassero. Ecco un altro aspetto negativo delle stringhe. Anche se uso BIGINT nel db come userid, è ancora solo 8 byte vs varchar (128). Capisco che lo spazio su disco è poco costoso in questi giorni, ma perché devo ingombrare il mio db con cose inutili. Chiunque abbia mai lavorato a un progetto che coinvolge milioni di utenti disapprova le stringhe come userid. Tutte le risposte di Microsoft sul "motivo per cui hanno usato le stringhe" sono fondamentalmente risposte sfumate.

Naturalmente diranno: "puoi cambiarlo per usare INT, BIGINT ecc ...". Certo, devi cambiare una miriade di classi, implementare il tuo negozio utente ecc. Giusto ... qualcosa di così semplice deve essere così complicato.

/ fine rant


0
2018-05-20 18:07