Vantaggi e svantaggi dell'utilizzo di MD5 Hash come chiave primaria rispetto all'utilizzo di un'identità int come chiave primaria in SQL Server

Question

Ho un'applicazione per gestire un file e frammentarlo su più segmenti, quindi salvare il risultato in SQL Server Banca dati. Esistono molti file duplicati (magari con percorso file diverso), quindi prima di tutto analizzo tutti questi file e computo l'hash Md5 per ogni file e contrassegno il file duplicato utilizzando la colonna [Duplicato].

Poi ogni giorno eseguirò questa applicazione e salverò i risultati nella tabella [Risultato]. Lo schema db è come qui sotto:

CREATE TABLE [dbo].[FilePath] 
    (
     [FilePath] NVARCHAR(256) NOT NULL PRIMARY KEY, 
     [FileMd5Hash] binay(16) NOT NULL, 
     [Duplicated] BIT NOT NULL DEFAULT 0, 
     [LastRunBuild] NVARCHAR(30) NOT NULL DEFAULT 0 
    ) 

    CREATE TABLE [dbo].[Result] 
    (
     [Build] NVARCHAR(30) NOT NULL, 
     [FileMd5Hash] binay(16) NOT NULL , 
     [SegmentId] INT NOT NULL, 
     [SegmentContent] text NOT NULL 
     PRIMARY KEY ([FileMd5Hash], [Build], [SegmentId]) 
    ) 

E ho un obbligo di aderire a questi 2 tabella a FileMd5Hash.

Dal momento che il numero di righe di [Risultato] è molto grande, vorrei aggiungere una colonna int Identity per unire queste tabelle come qui sotto:

CREATE TABLE [dbo].[FilePath] 
    (
     [FilePath] NVARCHAR(256) NOT NULL PRIMARY KEY, 
     [FileMd5Hash] binay(16) NOT NULL, 
     **[Id] INT NOT NULL IDENTITY,** 
     [Duplicated] BIT NOT NULL DEFAULT 0, 
     [LastRunBuild] NVARCHAR(30) NOT NULL DEFAULT 0 
    ) 

    CREATE TABLE [dbo].[Result] 
    (
     [Build] NVARCHAR(30) NOT NULL, 
     **[Id] INT NOT NULL,** 
     [SegmentId] INT NOT NULL, 
     [SegmentContent] text NOT NULL 
     PRIMARY KEY ([FileMd5Hash], [Build], [SegmentId]) 
    ) 

Quindi qual è la Pro e contro di questi 2 modi?

Answer 1

Un tasto int è più semplice da implementare e più facile da usare e da capire. È anche più piccolo (4 byte contro 16 byte), quindi gli indici si adattano al doppio del numero di voci per pagina IO, il che significa prestazioni migliori. Anche le righe della tabella saranno più piccole (OK, non molto più piccole), quindi di nuovo avrai più righe per pagina = meno IO.

Hash può sempre provocare collisioni. Sebbene estremamente raro, tuttavia, come mostra lo birthday problem, le collisioni diventano sempre più probabili man mano che aumenta il conteggio dei record. Il numero di elementi necessari per un 50% di probabilità di una collisione con varie hash bit di lunghezza è la seguente:

Hash length (bits) Item count for 50% chance of collision 
       32 77000 
       64 5.1 billion 
       128 22 billion billion 
       256 400 billion billion billion billion 

C'è anche il problema di dover passare intorno byte non ASCII - più difficile da mettere a punto, inviare oltre filo, ecc.

Utilizzare le chiavi primarie sequenziali per le vostre tabelle int. Lo fa chiunque altro.

Answer 2

Ecco un bellissimo articolo che spiega Pro e contro dell'utilizzo di entrambi:

http://databases.aspfaq.com/database/what-should-i-choose-for-my-primary-key.html

Utilizzando MD5 hash sarà come usare un GUID per la chiave primaria. Le collisioni di hash sono rare ma possono accadere, potresti volerlo gestire.

Vado personalmente con INT IDENTITY ma potrebbe differire in base all'implementazione.

Answer 3

Utilizzare le inte per le chiavi primarie, non gli hash. Tutti mettono in guardia contro le collisioni di hash, ma in pratica non sono un grosso problema; è facile verificare la presenza di collisioni e re-hash. Gli ID sequenziali possono collidere anche se si uniscono i database.

Il grosso problema con gli hash come chiavi è che non è possibile modificare i dati. Se ci provi, il tuo hash cambierà e tutte le chiavi esterne non saranno più valide. Devi creare una colonna "no, questo è il vero hash" nel tuo database e il tuo vecchio hash diventa un grande numero intero non sequenziale.

Scommetto che il vostro analista di business dirà "implementiamo WORM in modo che i nostri record non cambieranno mai". Saranno smentiti.