/ Forside / Teknologi / Udvikling / SQL / Nyhedsindlæg
Login
Glemt dit kodeord?
Brugernavn

Kodeord


Reklame
Top 10 brugere
SQL
#NavnPoint
pmbruun 1704
niller 962
fehaar 730
Interkril.. 701
ellebye 510
pawel 510
rpje 405
pete 350
gibson 320
10  smorch 260
Generering af tilfældige nøgler i mySQL
Fra : Jesper Stocholm


Dato : 10-02-03 11:46

Jeg skal have lavet en tabel i mySQL med tilfældige primære nøgler. Dette
er jo desværre ikke muligt direkte i mySQL, så jeg skal have fundet en
måde at lave disse nøgler i mit applikationslag. Dette lag ligger på en
Windows-maskine, så jeg har overvejet at anvende GUIDs fra Windows, der
giver en 32-tegn (ca 168bits) streng, der "ser meget tilfældig ud".

Er der nogen af jer, der har erfaring med at anvende dette som primær
nøglegenerator ? Mit forbehold er naturligvis, om jeg realistisk kan
risikere, at den laver de samme GUIDs af og til [1]. Hvis det er
tilfældet, så skal jeg jo indbygge noget logik, er håndterer indsætning
af en række med dublet-primær nøgle. Det er jo ikke ligefrem
raketvidenskab at lave dette - men hvis det kan undgåes, så vil det jo
ikke være at foragte.

Hvad siger I ?



[1] Fx genanvendes sessions-ids fra IIS jo hele tiden, så jeg er lidt
bange for, at det samme gør sig gældende her.

--
Jesper Stocholm
http://stocholm.dkk
Svar til gruppen og ikke til mig privat pr. email :|

 
 
Jens Gyldenkærne Cla~ (10-02-2003)
Kommentar
Fra : Jens Gyldenkærne Cla~


Dato : 10-02-03 12:25

Jesper Stocholm skrev:

> Er der nogen af jer, der har erfaring med at anvende dette som
> primær nøglegenerator ? Mit forbehold er naturligvis, om jeg
> realistisk kan risikere, at den laver de samme GUIDs af og til
> [1].

Jeg tror godt du kan antage at genererede GUIDs er unikke. Se fx
følgende side:
<http://www.devx.com/dbzone/Article/10167/1954?pf=true>


> [1] Fx genanvendes sessions-ids fra IIS jo hele tiden, så jeg
> er lidt bange for, at det samme gør sig gældende her.

GUIDs er beregnet til at være unikke, ikke bare her og nu men også
over tid. Session-id'er skal bare være unikke på én server og ét
tidspunkt. Hvis et session-id genavendes er det formentlig fordi
der er en performancegevinst i at gøre det. Men funktionen af en
GUID gør at man aldrig vil tillade bevidst genanvendelse af dem.
Samtidig er udfaldsrummet stort nok til at et tilfældigt sammenstød
ikke skulle kunne ske. Se fx følgende citat:

,---- [ <http://www.developerfusion.com/show/1713/4/> ]
| Each time you create a new Globally Unique IDentifier, a GUID, you
| can be sure that it is really, truly, unique. It is not only unique
| for you, it is unique for everyone, everywhere, all the time. It
| incorporates the time and date, the MAC address from your network
| card (and if you don't have a network card, it uses another method,
| which has something like one chance in 2^63 of conflicting with
| another GUID), and a bunch of other information. Therefore, there
| is no way, short of explicit collusion between two programmers,
| that they will use the same GUID.
`----
--
Jens Gyldenkærne Clausen
MF (medlem af FIDUSO - www.fiduso.dk)
I ovenstående tekst benyttes nyt komma
(rettelser modtages gerne i dk.kultur.sprog)

Jesper Stocholm (10-02-2003)
Kommentar
Fra : Jesper Stocholm


Dato : 10-02-03 12:36

Jens Gyldenkærne Clausen wrote :

> Jesper Stocholm skrev:
>
>> Er der nogen af jer, der har erfaring med at anvende dette som
>> primær nøglegenerator ? Mit forbehold er naturligvis, om jeg
>> realistisk kan risikere, at den laver de samme GUIDs af og til
>> [1].
>
> Jeg tror godt du kan antage at genererede GUIDs er unikke. Se fx
> følgende side:
> <http://www.devx.com/dbzone/Article/10167/1954?pf=true>

interessant artikel ... :)

>> [1] Fx genanvendes sessions-ids fra IIS jo hele tiden, så jeg
>> er lidt bange for, at det samme gør sig gældende her.
>
> GUIDs er beregnet til at være unikke, ikke bare her og nu men også
> over tid. Session-id'er skal bare være unikke på én server og ét
> tidspunkt. Hvis et session-id genavendes er det formentlig fordi
> der er en performancegevinst i at gøre det.'

dette er naturligvs korrekt :)

> Men funktionen af en
> GUID gør at man aldrig vil tillade bevidst genanvendelse af dem.
> Samtidig er udfaldsrummet stort nok til at et tilfældigt sammenstød
> ikke skulle kunne ske. Se fx følgende citat:
>
> ,---- [ <http://www.developerfusion.com/show/1713/4/> ]
>| Each time you create a new Globally Unique IDentifier, a GUID, you
>| can be sure that it is really, truly, unique. It is not only unique
>| for you, it is unique for everyone, everywhere, all the time. It
>| incorporates the time and date, the MAC address from your network
>| card (and if you don't have a network card, it uses another method,
>| which has something like one chance in 2^63 of conflicting with
>| another GUID), and a bunch of other information. Therefore, there
>| is no way, short of explicit collusion between two programmers,
>| that they will use the same GUID.
> `----

ok ... det ser ud til, at det netop er dette jeg skal bruge. Den eneste
anke - som jeg ser det - er neddroslet performance ved joins på disse id-
kolonner - og så selvfølgelig, at jeg skal have ændret den meste af min
SQL til at id ikke er et tal men en streng.

Jeg kan også se, at Access kan lave disse GUIDs automatisk, så det er i
hvert fald noget af starte med ... :)

At to GUIDs dannet på to forskellige maskiner "aldrig vil blive ens"
stiller jeg mig dog lidt uforstående overfor ... algoritmen til dannelse
af dem må jo nødvendigvis være deterministisk, så formuleringen må jo
være "_nok_ aldrig blive ens".



--
Jesper Stocholm
http://stocholm.dk
Svar til gruppen og ikke til mig privat pr. email :|

Kim Bach Petersen (10-02-2003)
Kommentar
Fra : Kim Bach Petersen


Dato : 10-02-03 14:37

> Den
> eneste anke - som jeg ser det - er neddroslet performance ved joins
> på disse id- kolonner - og så selvfølgelig, at jeg skal have ændret
> den meste af min SQL til at id ikke er et tal men en streng.

En GUID er sådan set en 128-bit integer, der blot normalt gengives som
hexadecimal streng, så i princippet kan den sagtens konverteres og gemmes
som integer.

Kim



Jens Gyldenkærne Cla~ (10-02-2003)
Kommentar
Fra : Jens Gyldenkærne Cla~


Dato : 10-02-03 14:51

Kim Bach Petersen skrev:

> En GUID er sådan set en 128-bit integer, der blot normalt
> gengives som hexadecimal streng, så i princippet kan den
> sagtens konverteres og gemmes som integer.

Er det ikke lidt svært at få plads til et 128-bit-tal i et
integerfelt? Felttypen bigint er så vidt jeg ved 8 byte / 64 bit -
så der er et stykke op til de 128.
--
Jens Gyldenkærne Clausen
MF (medlem af FIDUSO - www.fiduso.dk)
I ovenstående tekst benyttes nyt komma
(rettelser modtages gerne i dk.kultur.sprog)

Kim Bach Petersen (10-02-2003)
Kommentar
Fra : Kim Bach Petersen


Dato : 10-02-03 17:04

> Er det ikke lidt svært at få plads til et 128-bit-tal i et
> integerfelt? Felttypen bigint er så vidt jeg ved 8 byte / 64 bit -
> så der er et stykke op til de 128.

Ups, jeg tænkte ikke lige så langt som til at det kunne være et problem - du
har helt ret i at bitint er 64 bit, så det går selvfølgelig ikke.





Jesper Stocholm (10-02-2003)
Kommentar
Fra : Jesper Stocholm


Dato : 10-02-03 23:51

Jens Gyldenkærne Clausen wrote :

> Jesper Stocholm skrev:
>
>> Er der nogen af jer, der har erfaring med at anvende dette som
>> primær nøglegenerator ? Mit forbehold er naturligvis, om jeg
>> realistisk kan risikere, at den laver de samme GUIDs af og til
>> [1].
>
> Jeg tror godt du kan antage at genererede GUIDs er unikke.

jeg lavede lige en lille .net-app, der indsætter disse unikke IDs i en
tabel som primær nøgle (genereret via System.Guid-namespace) i en tabel på
en MS SQL-server. Den tæller op til en million, og indtil nu er der lavet
253153 unikke værdier ... :) Det rækker fint til mig.



--
Jesper Stocholm - http://stocholm.dk

Svar til gruppen og ikke til mig privat !
Skriv under det du svarer på - www.usenet.dk/netikette/citatteknik.html

Anders Johannsen (12-02-2003)
Kommentar
Fra : Anders Johannsen


Dato : 12-02-03 16:55

"Jesper Stocholm" <jespers@stocholm.invalid> wrote in message
news:Xns931E77B6A2136spamstocholmdk@130.226.1.34...

> Jeg skal have lavet en tabel i mySQL med tilfældige primære nøgler.

Må jeg spørge hvorfor?

/A



Jesper Stocholm (12-02-2003)
Kommentar
Fra : Jesper Stocholm


Dato : 12-02-03 17:53

Anders Johannsen wrote :

> "Jesper Stocholm" <jespers@stocholm.invalid> wrote in message
> news:Xns931E77B6A2136spamstocholmdk@130.226.1.34...
>
>> Jeg skal have lavet en tabel i mySQL med tilfældige primære nøgler.
>
> Må jeg spørge hvorfor?

den skal bruges som db-backend til en web-applikation. Den primære nøgle
skal af og til overføres via URI, og jeg er ikke interesseret i, at man kan
gætte en rækkes id ved at kigge på en kendt værdi - altså at man ved at se
på en URI som page?id=232 kan (succesfuldt) gætte på page?id=233 .



--
Jesper Stocholm - www.stocholm.dk - www.asp-faq.dk
** De andre siger, at han er 16 **
Svar venligst til gruppen og ikke til mig privat !
Skriv under det du svarer på - www.usenet.dk/netikette/citatteknik.html

Anders Johannsen (12-02-2003)
Kommentar
Fra : Anders Johannsen


Dato : 12-02-03 19:20

"Jesper Stocholm"
<skal.du.absolut.vise.min.emailadresse.ved.svar@stocholm.invalid> wrote in
message news:Xns9320B5D5BC41Dspamstocholmdk@130.226.1.34...

> den skal bruges som db-backend til en web-applikation. Den primære nøgle
> skal af og til overføres via URI, og jeg er ikke interesseret i, at man
kan
> gætte en rækkes id ved at kigge på en kendt værdi - altså at man ved at se
> på en URI som page?id=232 kan (succesfuldt) gætte på page?id=233 .

Jeg ville nok vælge at løse problemet dér - i stedet for at undgå krumspring
i databasen.

Du kunne fx lave en checksum på din url:

id = 232
url = "http://example.com/page?id=" + id + "&check=" +
checksum("secret" + id)

/A



Jesper Stocholm (12-02-2003)
Kommentar
Fra : Jesper Stocholm


Dato : 12-02-03 20:35

Anders Johannsen wrote :

> "Jesper Stocholm"
> <skal.du.absolut.vise.min.emailadresse.ved.svar@stocholm.invalid>
> wrote in message news:Xns9320B5D5BC41Dspamstocholmdk@130.226.1.34...
>
>> den skal bruges som db-backend til en web-applikation. Den primære
>> nøgle skal af og til overføres via URI, og jeg er ikke interesseret
>> i, at man kan gætte en rækkes id ved at kigge på en kendt værdi -
>> altså at man ved at se på en URI som page?id=232 kan (succesfuldt)
>> gætte på page?id=233 .
>
> Jeg ville nok vælge at løse problemet dér - i stedet for at undgå
> krumspring i databasen.
>
> Du kunne fx lave en checksum på din url:

var allerede implementeret :)

> id = 232
> url = "http://example.com/page?id=" + id + "&check=" +
> checksum("secret" + id)

jeg er heller ikke interesseret i at man kan komme med et kvalificeret
gæt på, hvor mange enheder jeg har i databasen. Dette hjælper
fortløbende ids imo til at kunne.



--
Jesper Stocholm - www.stocholm.dk - www.asp-faq.dk
** De andre siger, at han er 16 **
Svar venligst til gruppen og ikke til mig privat !
Skriv under det du svarer på - www.usenet.dk/netikette/citatteknik.html

Jakob Andersen (12-02-2003)
Kommentar
Fra : Jakob Andersen


Dato : 12-02-03 20:32

"Jesper Stocholm" wrote
> Jeg skal have lavet en tabel i mySQL med tilfældige
> primære nøgler. Dette er jo desværre ikke muligt
> direkte i mySQL, så jeg skal have fundet en måde
> at lave disse nøgler i mit applikationslag.

Hvis du har adgang til databasen kan du også blot bruge en function som
denne:
<http://software.tangent.org/articles/02/10/21/1915224.shtml?tid=32>

--
Jakob Andersen



Jesper Stocholm (12-02-2003)
Kommentar
Fra : Jesper Stocholm


Dato : 12-02-03 20:40

Jakob Andersen wrote :

> "Jesper Stocholm" wrote
>> Jeg skal have lavet en tabel i mySQL med tilfældige
>> primære nøgler. Dette er jo desværre ikke muligt
>> direkte i mySQL, så jeg skal have fundet en måde
>> at lave disse nøgler i mit applikationslag.
>
> Hvis du har adgang til databasen kan du også blot bruge en function som
> denne:
> <http://software.tangent.org/articles/02/10/21/1915224.shtml?tid=32>

det har jeg desværre ikke direkte ...



--
Jesper Stocholm - www.stocholm.dk - www.asp-faq.dk
** De andre siger, at han er 16 **
Svar venligst til gruppen og ikke til mig privat !
Skriv under det du svarer på - www.usenet.dk/netikette/citatteknik.html

Søg
Reklame
Statistik
Spørgsmål : 177558
Tips : 31968
Nyheder : 719565
Indlæg : 6408925
Brugere : 218888

Månedens bedste
Årets bedste
Sidste års bedste