Bruker vi MD5 som ID i tabeller ?

[RulleRimfrost]

Har en tabell med navn og adresser. ID er autogenerert av sql server.

Inn til programmet mitt kommer uendrede, endrede og nye adresser, uten noen unik ID.

Disse skal jeg vaske mot databasen.

Ved uendrede skal jeg ikke gjøre noe, men ved endrede og nye skal jeg gjøre en insert (ikke update).

Det jeg tenkte så langt var å sette sammen alle feltene fra innkommende rad, kalkulere MD5 hash og benytte denne som unik ID. Deretter la dataAdapter ta seg av resten basert på MD5 som unik id.

 

Er MD5 checksum på voksne 128 bit det mest effektive .net har her, eller finnes det raskere måter å gjøre dette på ?

[Manfred]

skal du bruke en slik hash som ID, så vil du jo måtte søke i tekst når du skal sammenligne. Kan du ikke bare bruke et autonummer som ID?

[GeirGrusom]

Det er ingen garanti for at to forskjellige data i en rad ikke vil generere lik MD5 hash.

 

Hvorfor ikke bare bruke en teller, og legge til et MD5 felt?

[Manfred]

HAHA! Jeg kom først!

[RulleRimfrost]

Nope. Data kommer inn som :

[Per] - [Hansen] - [skomakergata 1] - [0150] - [Oslo]

Innkommende rad får ingen ID før den evt er lagt i databasen, og den skal ikke legges inn før jeg har sjekket at det ikke eksisterer en rad der alle feltene er helt like.

 

 

Om Han gifter seg og blir hetende Per Olsen - Ny rad

Om han flytter til Parkveien - Ny rad

 

Jeg tenkte kanskje at MD5 er være en flaskehals når .net evt må kalkulere det for 20 000 rader, men antar det skulle gå greit å benytte en teller for ID.

Endret 3. april 2008 av RulleRimfrost

[Manfred]

Som GeirGrusom sier, så har du ingen garanti for at to linjer ikke skaper samme hash... Da hadde det vært sikrere å bruke SHA1, som gir en mye lengre string, men uansett: Problemet kommer til når du skal søke gjennom databasen med en kjempelang tekststreng som sammenligning. Det er nok ikke i .net flaskehalsen ligger her.

[steingrim]

Det er ingen garanti nei, og som vi vet skal man ikke lenger benytte MD5 i noen form for sikkerhetsmekanikk, men jeg vil si det er SVÆRT usannsynlig at to adresser gir lik MD5 sum. De to adressene skulle jeg likt å sett!

[Manfred]

Dette er snakk om tilfeldigheter. Ja, det er mange muligheter, men en MD5-hash er ikke SÅ lang...

 

Men hovedpoenget mitt er at søking i databasen vil gå som sirup...

[GeirGrusom]

Det er ingen garanti nei, og som vi vet skal man ikke lenger benytte MD5 i noen form for sikkerhetsmekanikk, men jeg vil si det er SVÆRT usannsynlig at to adresser gir lik MD5 sum. De to adressene skulle jeg likt å sett!

 

Logikken er veldig enkel

 

Jo lenger inndata er, jo flere varianter har lik hash verdi.

Selvom det er særdeles vanvittig usannsynlig, er det ikke umulig.

 

En teller derimot vil aldri gi like verdier noensinne, og vil også ha like stor nytteverdi som en hash.

 

Hvis du på død og liv vil ha en hash, kan du jo presentere en MD5 hash av telleren.

MD5 er asynkron allikevel, så det spiller ingen rolle hva innverdien er i dette tilfellet.

[RulleRimfrost]

Ja, jeg bruker en servergenerert teller i databasen, men input-row har dessverre ingen slik unik identifikator. Den leses fra fil eller brukerinput. Trenger heller ingen sikkerhet, kun raskest mulig sammenligning av input-row mot database. Vi kan ha flere Per Hansen og flere beboere i Parkveien 27, men vi kan ikke ha flere Per Hansen i Parkveien 27...

 

Om .net er kjapp å beregne MD5(felt_1 + felt_2 + .... + felt_n) så funker det. Alt for mange felter i tabellen til å bare sammenligne hele raden. Foreløpig ser den slik ut :

[GeirGrusom]

System.Security.Cryptography.MD5 md5 = System.Security.Cryptography.MD5.Create();

 

Så kan du legge sammen alle feltene til en string, og bruke Encoding.ASCII.GetBytes for å hente bytes fra den.

[RulleRimfrost]

Jeg ser SHA1 lager en hash på 40 tegn og MD5 lager 32 tegn. Begge er så raske at det ikke har noe og si egentlig, men MD5 er kortest og dermed mest databasevennlig. Finnes det noen kortere enn 32 tegn ?

[Manfred]

Problemet er ikke å lage de, men du skal vel lage spørringer som spør etter de i databasen.

 

Av typen

SELECT * FROM Tabell WHERE md5 = '....'

 

Det er jo DETTE jeg mener blir problemet. Ikke å lage selve hashen.

[RulleRimfrost]

Ah, sjønner. Og nei, egentlig ikke. Når brukerne kjører en spørring vil den benytte en link-tabell mot AD_ID, en teller som knytter den adressen mot evt andre tabeller.

Det er kun når programmet skal sette inn nye adresser den skal sjekke at akkurat den adressen ikke ligger inne fra før. Tenkte noe som :

 

NyMD5 = hentMd5(alle_data_for_ny_kunde)

da = new sqlDataAdapter("select * from adresser where MD5 = " + NyMd5, con)

if ' da har hentet noe

Hent ut AD_ID og sett inn i link-tabellen

else ' fant ikke samme md5 i databasen

dataAdapter.update(tempDataSet, "adresser")

[GeirGrusom]

Ok, greit med MD5 e.l. men det er litt poengløst å bruke det som primærnøkler.

[RulleRimfrost]

Ja. Må vel benytte Autogenerert id-felt som primær.

Men hash-tabell blir mindre enn jeg trodde. Om jeg har MD5 for hele Norges befolkning:

16 Byte md5 * 4 500 000 / 1 000 000 = 72MB index på sql-server