una - SQL Server 2005 mi penalizzerà per l'utilizzo di un nvarchar(50) come chiave primaria, anziché di un intero?



sql stored procedure input parameter table (4)

Sto considerando di alterare alcune tabelle per usare nvarchar (50) come chiave primaria invece di una chiave primaria int. L'utilizzo di un ID int per una chiave è in realtà un dato irrilevante, è la stringa a cui sono interessato. Che tipo di impatto sulle prestazioni si verificherà o dove lo si ricerca? Altro che tagliare e provare quello è.


Answer #1

Considerare l'utilizzo di una chiave surrogata (una chiave primaria int) come chiave primaria / chiave dell'indice cluster. Il problema con l'utilizzo di un nvarchar (50) come chiave primaria / chiave di indice cluster è che la tabella verrà ordinata da quella chiave, il che significa che è probabile che diventi molto frammentata e che qualsiasi altro indice abbia l'onere di fare riferimento a questo pesante chiave primaria.

Un altro problema è che presumibilmente hai bisogno di partecipare su altre tabelle con questo tipo di valore che è un'operazione più costosa con l'aumentare delle dimensioni della chiave.

Penso che ci siano pochissime situazioni in cui una chiave primaria nvarchar (50) abbia senso.

In generale, le chiavi primarie dovrebbero essere un surrogato A MENO CHE tu abbia una piccola chiave naturale immutabile. Probabilmente, SSN, ad esempio, potrebbe essere considerato una chiave immutabile naturale.


Answer #2

Perché UNICODE? ad es. se traducevo una parola inglese in caratteri cinesi Han, sarebbero considerati duplicati?

Perché variabile? La larghezza fissa è una buona caratteristica fisica di una chiave.

Perché 50 personaggi? Questo è un aspetto fondamentale per gli utenti (sono d'accordo che "un ID int per una chiave è in realtà un dato irrilevante" e penso che le cosiddette "chiavi surrogate" non dovrebbero mai essere esposte agli utenti finali, a proposito di BTW).

Inoltre, per me NVARCHAR(50) è un po 'un "odore": un default Microsoft, una porta diretta da MS Access, forse? Questo non significa che non hai dato il dovuto pensiero e considerazione alla tua chiave, ovviamente, solo una di quelle cose da recensire.

Oh, aspetta: intendevi specificamente PRIMARY KEY, giusto? Supponendo che si utilizzi esplicitamente il proprio indice cluster (per tabella), la designazione PRIMARY KEY AFAIK non ha implicazioni fisiche in SQL Server land. Naturalmente, tutte le chiavi candidate dovrebbero essere coperte da vincoli NOT NULL UNIQUE; quello che scegli di promuovere su PRIMARY è arbitrario.


Answer #3

Al fine di bruciare definitivamente tutti gli argomenti proposti dai leader della soluzione chiave naturale ( cfr surrogato vs guerra chiave naturale ), e per farla breve, dovrei dire che le chiavi surrogate funzionano SEMPRE, mentre le chiavi naturali hanno una debole tendenza a condurre a problemi e frustrazione, di solito in tempi inaspettati.

Non dico che siano la soluzione ottimale per ogni situazione, ma per evitare di perdere il tempo (e l'altro) di pensare ai parametri corretti per la migliore chiave naturale quando si crea una tabella, basta scegliere la surrogata ed è fatta. E se il tuo tavolo sembra avere una chiave naturale corretta, aggiungilo come campo con un indice (univoco?).

E per rendere più semplice per gli sviluppatori, avere sempre il primo campo come chiave primaria, il secondo è la presunta / pseudo chiave naturale. Il tuo tavolo dovrebbe apparire così:

Tbl_whatever
     id_whatever, unique identifier, primary key
     code_whatever, nvarchar(your favorite length), indexed
     .....

Dove id_ è il prefisso per la chiave primaria e code_ è utilizzato per il campo indicizzato "naturale"


Answer #4

Per le prestazioni, normalmente chiedo quanto segue:

  • quante righe? 1.000 o 1.000.000 o 10.000.000 ??

  • su che server è seduto? (memoria, spazio su disco)

Vorrei profilarlo e poi vedere. Normalmente per me, il collo di bottiglia non è il database, è un codice scritto male, distribuito male ecc. Ecc ...





primary-key