In uno scenario tipico, un oggetto che deve essere persistente nel database verrà creato nel codice dell'applicazione senza un identificatore e successivamente salvato in una tabella nel database. Alcuni costrutti di database, come una colonna Identity, genereranno un nuovo identificatore, tipicamente un intero che è unico per tutte le righe di quella tabella. Questo identificatore può quindi essere restituito al codice dell'applicazione e quindi trattato come una chiave.
CREATE TABLE Users (
UserId int IDENTITY(1,1) NOT NULL, DisplayName nvarchar(max),
UserName nvarchar(50), [Password] nvarchar(50))
GO
INSERT INTO Users (DisplayName, UserName, [Password])
VALUES ('Joe Shmo', 'jshmo', 'pw1')
SELECT @@IDENTITY
Un altro scenario comune è che l'identificatore sia GUID:
CREATE TABLE Users (
UserId uniqueidentifier NOT NULL, DisplayName nvarchar(max),
UserName nvarchar(50), [Password] nvarchar(50))
GO
DECLARE @id uniqueidentifier = NEWID()
INSERT INTO Users (UserId, DisplayName, UserName, [Password])
VALUES (@id, 'Joe Shmo', 'jshmo', 'pw1')
SELECT @id
Questo secondo modo offre il seguente vantaggio: il GUID può essere generato nel codice dell'applicazione, che può quindi essere utilizzato come chiave per scopi di caching / riferimento delle applicazioni prima che l'oggetto sia mai stato salvato. Tuttavia, vi è un costo associato all'utilizzo di GUID in termini di dimensioni e, in particolare, costi di ricerca. Questi possono essere banali quando il tavolo è piccolo, ma possono diventare un fattore importante quando il tavolo è enorme.
Esistono best practice o tecniche per i casi in cui un identificatore univoco per il tipo di oggetto deve essere generato nel codice dell'applicazione, ma non può essere un GUID per qualsiasi motivo?
Un pensiero era di avere un'altra tabella che genera un identificatore avvolto da un servizio identificatore che il codice dell'applicazione potrebbe chiamare.