[Discussie] Check of een GUID al bestaat?

Pagina: 1
Acties:

Acties:
  • 0 Henk 'm!

  • Douweegbertje
  • Registratie: Mei 2008
  • Laatst online: 27-07 22:50

Douweegbertje

Wat kinderachtig.. godverdomme

Topicstarter
Ik zat op een gegeven moment na te denken over een stukje code. Hierin wordt een GUID gebruikt voor het opslaan van een gegeven. Nu word er totaal geen check gedaan of dit GUID al bestaat. In dit geval gaat het om een database waar o.a. de GUID in wordt gezet.

De reden waarom ik nadacht over dit stukje code, was omdat de insert fout was gegaan omdat de "unieke entry" al bestond. Er zijn 3.4×10^38 mogelijke keys en de kans voor een dubbele is dus 0.00000000006. Needless to say, ik heb dus gelijk een staatslot gekocht.

Nu zit ik zelf een beetje in dubio.. zou iemand nu een check moeten doen of een gegeven GUID al bestaat of niet. Immers is de kans 0.00000000006 dat het fout gaat. Het is verdomd weinig, en de vraag is; is het het waard om bijvoorbeeld eerst een SELECT uit te voeren om te zien of er al zo'n record bestaat?

Ik vind persoonlijk dat je uit moet gaan van het "feit" dat een GUID er juist is om als unieke identificatie te functioneren. Met de nadruk dus op uniek (wat het technisch gezien IMO niet helemaal is). Daarom zou een check dus niet nodig moeten zijn. Qua 'best practice' zou je -altijd- je input moeten controleren maar.. ik zie dit onderwerp graag als uitzondering.

Daargelaten dat de betreffende applicatie niet van levensbelang is, of financieel enorm veel schade kan opleveren bijvoorbeeld.

Wat denken jullie ervan? :)

Acties:
  • 0 Henk 'm!

  • Damic
  • Registratie: September 2003
  • Laatst online: 21:17

Damic

Tijd voor Jasmijn thee

Checken om te checken, er moet maar iets mis zijn met je GUI generator en krijg je veel meer dezelfde string terug.

Al wat ik aanraak werk niet meer zoals het hoort. Damic houd niet van zijn verjaardag


Acties:
  • +1 Henk 'm!

  • RobIII
  • Registratie: December 2001
  • Niet online

RobIII

Admin Devschuur®

^ Romeinse Ⅲ ja!

(overleden)
Douweegbertje schreef op maandag 03 augustus 2015 @ 21:55:
Immers is de kans 0.00000000006 dat het fout gaat.
Nee, dat is de kans dat je geraakt wordt door een meteoriet (1 op 17 miljard). De kans op een duplicate GUID, de birthday paradox in acht genomen, is vele ordegroottes kleiner nadat je al een shitload aan GUID's hebt gegenereerd. Als je 246 GUID's genereert is de kans op een duplicate nog steeds maar 0.0000000005. M.a.w. lees die alinea nog eens goed ;)
Damic schreef op maandag 03 augustus 2015 @ 21:57:
Checken om te checken, er moet maar iets mis zijn met je GUI generator en krijg je veel meer dezelfde string terug.
Die kans is inderdaad (veel) groter; er zijn dan ook niet voor niets unique constraints :Y)
Douweegbertje schreef op maandag 03 augustus 2015 @ 21:55:
is het het waard om bijvoorbeeld eerst een SELECT uit te voeren om te zien of er al zo'n record bestaat?
Nee. Hoewel de kans i.c.m. GUID's nog vele malen kleiner is, heb je kans op een race-condition. Je doet de select, GUID staat (nog) niet in de tabel, ander proces insert "toevallig" het GUID en daarna insert jij het omdat je select niets opleverde. Gebruik dan gewoon een unique constraint en maak dan de keuze: ga ik een DuplicateKeyException handlen (wat de moeite, an sich*, zeer waarschijnlijk niet waard is) of niet.

* Afhankelijk van de situatie natuurlijk; als je 2 processen hebt die allebei bestanden importeren en (potentieel, al dan niet per-ongeluk) hetzelfde bestand kunnen importeren dan kan het zich lonen die exception wel (goed) te handlen. Heb je een enkel proces dat zélf de GUID's genereert of je laat 't over aan SQL server dan is het natuurlijk weer een ander verhaal.

[ Voor 60% gewijzigd door RobIII op 03-08-2015 23:57 ]

There are only two hard problems in distributed systems: 2. Exactly-once delivery 1. Guaranteed order of messages 2. Exactly-once delivery.

Je eigen tweaker.me redirect

Over mij


Acties:
  • 0 Henk 'm!

  • Gumball
  • Registratie: December 2003
  • Niet online
De kans op niet unieke GUIDS (in bijvoorbeeld SQLserver) is eigelijk nul. Checken is dus niet noodzakelijk

Acties:
  • 0 Henk 'm!

  • gekkie
  • Registratie: April 2000
  • Laatst online: 17:07
Hangt wellicht een beetje van het achterliggende algoritme af .. en waarvoor je het gebruikt .. heb je een iets wat guid uitdeelt dan kun je checken .. heb je meerdere entiteiten die onafhankelijk van elkaar guid kunnen aanmaken die elkaar tegen kunnen komen dan wordt het lastiger.

Als de guid gedeeltelijk op timestamp gebaseerd is valt het wellicht mee ..
aan de andere kant kan het zaken wel danig in de soep draaien wat weer fijn te debugselen is ..

Maar als je een enkele entiteit hebt .. waarom dan geen bigserial ?

BTW .. opzich check je toch al .. aangezien je kennelijk een unique constraint op je guid column hebt ?

[ Voor 16% gewijzigd door gekkie op 03-08-2015 22:05 ]


Acties:
  • 0 Henk 'm!

  • Douweegbertje
  • Registratie: Mei 2008
  • Laatst online: 27-07 22:50

Douweegbertje

Wat kinderachtig.. godverdomme

Topicstarter
Ik gebruik eigenlijk deze 2. Ik brouw niets zelf als het er al is.

PHP GUID
.NET
gekkie schreef op maandag 03 augustus 2015 @ 22:01:

BTW .. opzich check je toch al .. aangezien je kennelijk een unique constraint op je guid column hebt ?
meh ja, discutabel. Je checkt het omdat het op zijn bek gaat, niet omdat je iets goed afvangt. Je krijgt meer iets van "er ging iets fout" in plaats van "duplicate, hier is een nieuwe GUID".

[ Voor 47% gewijzigd door Douweegbertje op 03-08-2015 22:09 ]


Acties:
  • 0 Henk 'm!

  • RobIII
  • Registratie: December 2001
  • Niet online

RobIII

Admin Devschuur®

^ Romeinse Ⅲ ja!

(overleden)
Douweegbertje schreef op maandag 03 augustus 2015 @ 22:08:
Ik gebruik eigenlijk deze 2. Ik brouw niets zelf als het er al is.

PHP GUID
.NET
Dat staat toch los van de vraag :?
Even aangenomen dat de GUID's goed gegenereerd worden; je vraag was: is het het waard om te checken? Antwoord: een check is sowieso zinloos (allee, niet helemaal natuurlijk) want dan hou je nog steeds een (piepkleinere) kans over op een race condition; doe het dan goed en gebruik een unique constraint en handle eventuele exceptions al dan niet af. En onder 'afhandelen' kun je dan uiteraard ook gewoon "nieuw GUID genereren en opnieuw proberen" verstaan...

Afhankelijk van de situatie zou je eens naar een "snowflake achtige" oplossing kunnen kijken (*kuch*).

[ Voor 17% gewijzigd door RobIII op 03-08-2015 22:13 ]

There are only two hard problems in distributed systems: 2. Exactly-once delivery 1. Guaranteed order of messages 2. Exactly-once delivery.

Je eigen tweaker.me redirect

Over mij


Acties:
  • 0 Henk 'm!

  • Douweegbertje
  • Registratie: Mei 2008
  • Laatst online: 27-07 22:50

Douweegbertje

Wat kinderachtig.. godverdomme

Topicstarter
Nja er waren wat 'opmerkingen' c.q. reacties die gingen over het type algoritme e.d. Vandaar even de verheldering over wat ik precies gebruik. Ik heb mij er ook niet heel erg in verdiept tussen de verschillen, maar ik neem aan dat de één wat "meer random" is dan de ander.

Acties:
  • 0 Henk 'm!

  • RobIII
  • Registratie: December 2001
  • Niet online

RobIII

Admin Devschuur®

^ Romeinse Ⅲ ja!

(overleden)
Douweegbertje schreef op maandag 03 augustus 2015 @ 22:12:
maar ik neem aan dat de één wat "meer random" is dan de ander.
GUID's zijn niet random.

[ Voor 26% gewijzigd door RobIII op 03-08-2015 22:15 ]

There are only two hard problems in distributed systems: 2. Exactly-once delivery 1. Guaranteed order of messages 2. Exactly-once delivery.

Je eigen tweaker.me redirect

Over mij


Acties:
  • 0 Henk 'm!

  • gekkie
  • Registratie: April 2000
  • Laatst online: 17:07
Douweegbertje schreef op maandag 03 augustus 2015 @ 22:08:
meh ja, discutabel. Je checkt het omdat het op zijn bek gaat, niet omdat je iets goed afvangt. Je krijgt meer iets van "er ging iets fout" in plaats van "duplicate, hier is een nieuwe GUID".
Klopt maar opzich krijg je geen silent corruption ... Als het dan toch faalt .. Fail hard .. fail fast.

Acties:
  • 0 Henk 'm!

  • Douweegbertje
  • Registratie: Mei 2008
  • Laatst online: 27-07 22:50

Douweegbertje

Wat kinderachtig.. godverdomme

Topicstarter
pseudorandom dan. In elk geval was er vroeger iets met MS die iets van een mac adres gebruikte waardoor er iets van een flaw in zat. Zij het nu achterhalen welke PC de GUID vandaan kwam of dat het minder "veilig" was of niet :p In elk geval kan ik mij voorstellen dat je met de ene implementatie technisch gezien sneller een hit krijg dan de ander.

Overigens correct op de birthday paradox :p Niet aan gedacht ^^ .

[ Voor 16% gewijzigd door Douweegbertje op 03-08-2015 22:16 ]


Acties:
  • 0 Henk 'm!

  • Tsurany
  • Registratie: Juni 2006
  • Niet online

Tsurany

⭐⭐⭐⭐⭐

De vraag is ook of je perse een GUID nodig hebt of dat een sequence in je database niet praktischer is. Ik zou vooral goed over je exception handling nadenken. Wat doe je als je toch een duplicate error krijgt? En wat als het verder op in je applicatie mis gaat, kan het zijn dat je dan deze insert opnieuw probeert uit te voeren?

SMA SB5.0 + 16x Jinko 310wp OWO + 10x Jinko 310wp WNW |--|--| Daikin 4MXM68N + 1x FTXA50AW + 3x FTXM20N


Acties:
  • 0 Henk 'm!

  • ValHallASW
  • Registratie: Februari 2003
  • Niet online
Douweegbertje schreef op maandag 03 augustus 2015 @ 22:15:
In elk geval was er vroeger iets met MS die iets van een mac adres gebruikte waardoor er iets van een flaw in zat.
Het is geen flaw, het is een ontwerpkeuze. Als je een distributed systeem hebt dan is het handig om het mac-adres te gebruiken om de kans op collisions te verkleinen (immers: niemand anders bouwt een uuid met jouw mac-adres). Dat algoritme is alleen niet handig op het moment dat je op één server al je uuid's genereert, aangezien je dan alleen nog maar een timestamp hebt als uniqueness constraint. Let erop dat dit in ieder geval voor com_create_guid is wat er gebeurt; voor de c#-code weet ik het niet.

Zie ook: Wikipedia: Universally unique identifier

Acties:
  • 0 Henk 'm!

  • RobIII
  • Registratie: December 2001
  • Niet online

RobIII

Admin Devschuur®

^ Romeinse Ⅲ ja!

(overleden)
C#:
1
Console.WriteLine(Guid.NewGuid());


f6db344d-976b-48be-a74d-d0694927b503

V4 dus ;) (zie derde groepje, eerste digit (M) is 4).

[ Voor 24% gewijzigd door RobIII op 03-08-2015 22:44 ]

There are only two hard problems in distributed systems: 2. Exactly-once delivery 1. Guaranteed order of messages 2. Exactly-once delivery.

Je eigen tweaker.me redirect

Over mij


Acties:
  • 0 Henk 'm!

  • Douweegbertje
  • Registratie: Mei 2008
  • Laatst online: 27-07 22:50

Douweegbertje

Wat kinderachtig.. godverdomme

Topicstarter
ValHallASW schreef op maandag 03 augustus 2015 @ 22:22:
[...]

Het is geen flaw, het is een ontwerpkeuze. Als je een distributed systeem hebt dan is het handig om het mac-adres te gebruiken om de kans op collisions te verkleinen (immers: niemand anders bouwt een uuid met jouw mac-adres). Dat algoritme is alleen niet handig op het moment dat je op één server al je uuid's genereert, aangezien je dan alleen nog maar een timestamp hebt als uniqueness constraint. Let erop dat dit in ieder geval voor com_create_guid is wat er gebeurt; voor de c#-code weet ik het niet.

Zie ook: Wikipedia: Universally unique identifier
Prima hoor, verbeteringen e.d. maar het is ook wel eens fijn als je door hebt wat iemand bedoeld in de gehele context in plaats van 1 woordje eruit te halen. Daarbij is het gewoon wel een flaw.
An imperfection, often concealed
of het nu bewust is, een ontwerpkeuze of niet. Het is een flaw. En wat dan precies? Nou, de effecten die ze niet voorzien hadden in het ontwerp.
Overigens is het dan wel discutabel of het voor iedereen een flaw is.. :)
Tsurany schreef op maandag 03 augustus 2015 @ 22:17:
De vraag is ook of je perse een GUID nodig hebt of dat een sequence in je database niet praktischer is. Ik zou vooral goed over je exception handling nadenken. Wat doe je als je toch een duplicate error krijgt? En wat als het verder op in je applicatie mis gaat, kan het zijn dat je dan deze insert opnieuw probeert uit te voeren?
Nee dat is de vraag niet. Het is een discussie over het onderwerp zelf. Niet of GUID de juiste implementatie is.

Acties:
  • 0 Henk 'm!

  • Gomez12
  • Registratie: Maart 2001
  • Laatst online: 17-10-2023
Douweegbertje schreef op maandag 03 augustus 2015 @ 23:35:
[...]
of het nu bewust is, een ontwerpkeuze of niet. Het is een flaw. En wat dan precies? Nou, de effecten die ze niet voorzien hadden in het ontwerp.
Overigens is het dan wel discutabel of het voor iedereen een flaw is.. :)
Wat is er dan exact de flaw aan in jouw optiek?

Want echte GUID's bij computers zijn een onmogelijkheid, elke implementatie zal imperfect zijn.Sterker nog, zolang een GUID in lengte beperkt is is het überhaupt theoretisch al een onmogelijkheid.

Maar ontopic : Waar ga je nou eigenlijk voor kiezen?
Want ik zou in principe gewoon voor try/catch gaan en de exception afhandelen, imho is dat volledig gerechtvaardigd (een GUID die meerdere malen voorkomt zou een uitzondering moeten zijn).
En het kost me niet extra tijd + race-conditions wat een check vooraf me wel kost.
Gumball schreef op maandag 03 augustus 2015 @ 22:00:
De kans op niet unieke GUIDS (in bijvoorbeeld SQLserver) is eigelijk nul. Checken is dus niet noodzakelijk
Lol, dit is wellicht enigszins zo met 1 enkele sql-server, maar gooi er een serieus cluster achter en ik hoop toch echt wel dat je ze opvangt. Want ze gaan voorkomen, het is alleen maar de vraag wanneer.

Acties:
  • 0 Henk 'm!

  • gekkie
  • Registratie: April 2000
  • Laatst online: 17:07
Douweegbertje schreef op maandag 03 augustus 2015 @ 23:35:
Nee dat is de vraag niet. Het is een discussie over het onderwerp zelf. Niet of GUID de juiste implementatie is.
Dat is wel heel makkelijk, alle flaws hangen namelijk samen met de implementatie details.
Gomez12 schreef op maandag 03 augustus 2015 @ 23:54:
[...
Maar ontopic : Waar ga je nou eigenlijk voor kiezen?
Want ik zou in principe gewoon voor try/catch gaan en de exception afhandelen, imho is dat volledig gerechtvaardigd (een GUID die meerdere malen voorkomt zou een uitzondering moeten zijn).
En het kost me niet extra tijd + race-conditions wat een check vooraf me wel kost.
Een unique constraint op je DB is natuurlijk ook niet helemaal gratis ... afhankelijk van hoeveel rows je erin hebt zitten. Wat dat betreft lijkt me een sequence een stuk efficienter en beter te indexen voor als je toe kan met 1 entiteit die ze uitdeeld, anders ben je er wel toe veroordeeld.

Maar goed afhankelijk van waarvoor je ze gebruikt ( :X ohnee geen implementatie details) is het meer of minder desastreus voor je data consistentie en meer of minder van invloed op performance.

[ Voor 61% gewijzigd door gekkie op 04-08-2015 00:46 ]


Acties:
  • 0 Henk 'm!

  • Douweegbertje
  • Registratie: Mei 2008
  • Laatst online: 27-07 22:50

Douweegbertje

Wat kinderachtig.. godverdomme

Topicstarter
gekkie schreef op dinsdag 04 augustus 2015 @ 00:35:
[...]

Dat is wel heel makkelijk, alle flaws hangen namelijk samen met de implementatie details.
:?

Ik start een discussie over het gebruik van een GUID, niet of ik persoonlijk dat moet gaan gebruiken. Ik hoef toch niet voor een algemene discussie niet mijn verantwoording af te leggen of ik een guid moet gebruiken of en oplopend ID. En dat stukje heeft helemaal niets met een flaw te maken.

[...]
Een unique constraint op je DB is natuurlijk ook niet helemaal gratis ... afhankelijk van hoeveel rows je erin hebt zitten. Wat dat betreft lijkt me een sequence een stuk efficienter en beter te indexen voor als je toe kan met 1 entiteit die ze uitdeeld, anders ben je er wel toe veroordeeld.

Maar goed afhankelijk van waarvoor je ze gebruikt ( :X ohnee geen implementatie details) is het meer of minder desastreus voor je data consistentie en meer of minder van invloed op performance.
Implementatie details doet er helemaal niet toe, het ging gewoon meer over 'wat zou jij doen', in de algemene zin.

Heb je zelf niet door dat we van gewoon een algemene discussie over een GUID doorgaan naar wat voor implementatie ik gebruik, of ik wel exception handling toepas en hoe dan? Ik wil dat helemaal niet vertellen, noch hoeft iemand dat te weten om inhoudelijk te kunnen discussiëren over "zou je een GUID checken of deze al bestaat".

[ Voor 12% gewijzigd door Douweegbertje op 04-08-2015 13:50 ]


Acties:
  • 0 Henk 'm!

  • gekkie
  • Registratie: April 2000
  • Laatst online: 17:07
Douweegbertje schreef op dinsdag 04 augustus 2015 @ 13:46:
[...]
:?

Ik start een discussie over het gebruik van een GUID, niet of ik persoonlijk dat moet gaan gebruiken. Ik hoef toch niet voor een algemene discussie niet mijn verantwoording af te leggen of ik een guid moet gebruiken of en oplopend ID. En dat stukje heeft helemaal niets met een flaw te maken.

Implementatie details doet er helemaal niet toe, het ging gewoon meer over 'wat zou jij doen', in de algemene zin.

Heb je zelf niet door dat we van gewoon een algemene discussie over een GUID doorgaan naar wat voor implementatie ik gebruik, of ik wel exception handling toepas en hoe dan? Ik wil dat helemaal niet vertellen, noch hoeft iemand dat te weten om inhoudelijk te kunnen discussiëren over "zou je een GUID checken of deze al bestaat".
Omdat er verschillende versies / implementaties zijn van GUID's .. die elk hun eigen eigenschappen hebben (en dus ook hebbelijkheden) .. en die je dus in de wielen kunnen rijden geheel afhankelijk van waar je het voor gebruikt.

In algemene zin zou ik dus nagaan of een GUID implementatie past bij wat ik wil implementeren en wat de gevolgen zijn als er een doublure optreed en of en hoe ik die kan dragen en of er betere alternatieven zijn voor hetgeen waarvoor ik het wil implementeren.

Wat vind jij van tractors in algemene zin ? net zo'n ontzettend kansloze vraag dan. Eerst wat iemand zal gaan vragen is .. dat is afhankelijk van waarvoor je het zou willen gebruiken. Of .. ik vind oranje en zo'n grote wel mooi .. waar je ook weinig mee opschiet.
Maar goed succes verder dan .. jouw topic.

[ Voor 7% gewijzigd door gekkie op 04-08-2015 14:07 ]


Acties:
  • 0 Henk 'm!

  • Douweegbertje
  • Registratie: Mei 2008
  • Laatst online: 27-07 22:50

Douweegbertje

Wat kinderachtig.. godverdomme

Topicstarter
Wat zit je nu moeilijk te doen. Kijk eens naar de reacties van RobIII, helemaal perfect, klopt helemaal, en dat zonder al die loze argumenten reageert hij gewoon inhoudelijk op de discussie. Jij haalt er allemaal dingen bij die helemaal niet relevant zijn voor deze discussie.
Zie je mij ergens vragen van "wat moet ik gebruiken"? Nee, ik hoef geen functioneel antwoord voor een eventueel probleem wat ik heb..

Het is een algemene discussie dus wie zegt dat ik überhaupt een GUID gebruik? Mag iemand niet een discussie starten over "iets" zonder daar daadwerkelijk gebruik van te maken? Als je perse zoveel factoren wilt meenemen in je argument, verzin deze dan zelf voor je eigen use-case of wat jij gebruikt.

Je wilt mij nu een antwoord op een vraag, om vervolgens antwoord te kunnen geven op een vraag die ik niet heb gesteld. Snap je zelf nog de logica dan? Wat is er zo moeilijk aan het woord Discussie, in plaats van "Antwoord mijn specifieke vraag met deze specifieke variabelen".

Bedankt voor je succes wens.

Acties:
  • 0 Henk 'm!

  • Tsurany
  • Registratie: Juni 2006
  • Niet online

Tsurany

⭐⭐⭐⭐⭐

Douweegbertje schreef op maandag 03 augustus 2015 @ 23:35:
Nee dat is de vraag niet. Het is een discussie over het onderwerp zelf. Niet of GUID de juiste implementatie is.
Het is jouw vraag niet, wel mijn vraag. Jij hebt het over een specifiek probleem dat op kan treden bij het gebruiken van GUID's omdat ze niet per definitie uniek hoeven te zijn. Een mogelijke oplossing daarvoor kan zijn om gebruik te maken van een generieke sequence. De id's zijn dan niet random maar wel gegarandeerd uniek. Dat kan voor database implementaties praktischer zijn omdat je dan in principe geen duplicates kan krijgen.

SMA SB5.0 + 16x Jinko 310wp OWO + 10x Jinko 310wp WNW |--|--| Daikin 4MXM68N + 1x FTXA50AW + 3x FTXM20N


Acties:
  • 0 Henk 'm!

  • gekkie
  • Registratie: April 2000
  • Laatst online: 17:07
Douweegbertje schreef op dinsdag 04 augustus 2015 @ 14:31:
Wat zit je nu moeilijk te doen. Kijk eens naar de reacties van RobIII, helemaal perfect, klopt helemaal, en dat zonder al die loze argumenten reageert hij gewoon inhoudelijk op de discussie. Jij haalt er allemaal dingen bij die helemaal niet relevant zijn voor deze discussie.
Zie je mij ergens vragen van "wat moet ik gebruiken"? Nee, ik hoef geen functioneel antwoord voor een eventueel probleem wat ik heb..

Het is een algemene discussie dus wie zegt dat ik überhaupt een GUID gebruik? Mag iemand niet een discussie starten over "iets" zonder daar daadwerkelijk gebruik van te maken? Als je perse zoveel factoren wilt meenemen in je argument, verzin deze dan zelf voor je eigen use-case of wat jij gebruikt.

Je wilt mij nu een antwoord op een vraag, om vervolgens antwoord te kunnen geven op een vraag die ik niet heb gesteld. Snap je zelf nog de logica dan? Wat is er zo moeilijk aan het woord Discussie, in plaats van "Antwoord mijn specifieke vraag met deze specifieke variabelen".

Bedankt voor je succes wens.
Dan zijn we eruit .. als je een GUID nergens voor gebruikt .. zijn er ook geen problemen en hoef je ook niet te checken. Had dat dan gelijk gezegd joh !
Tsurany schreef op dinsdag 04 augustus 2015 @ 14:37:
[...]
Het is jouw vraag niet, wel mijn vraag. Jij hebt het over een specifiek probleem dat op kan treden bij het gebruiken van GUID's omdat ze niet per definitie uniek hoeven te zijn. Een mogelijke oplossing daarvoor kan zijn om gebruik te maken van een generieke sequence. De id's zijn dan niet random maar wel gegarandeerd uniek. Dat kan voor database implementaties praktischer zijn omdat je dan in principe geen duplicates kan krijgen.
Als je veel rijen krijgt lijkt me een insert op een sequence een stuk goedkoper dan een unique check op een kolom met miljoenen random values. Dus alleen als je werkt met meerdere databases / servers die ook in een detached state id's moeten aanmaken die valide blijven .. dan zit er weinig anders op vrees ik dan te leven met de manco's.

[ Voor 25% gewijzigd door gekkie op 04-08-2015 14:47 ]


Acties:
  • 0 Henk 'm!

  • Douweegbertje
  • Registratie: Mei 2008
  • Laatst online: 27-07 22:50

Douweegbertje

Wat kinderachtig.. godverdomme

Topicstarter
Tsurany schreef op dinsdag 04 augustus 2015 @ 14:37:
[...]

Het is jouw vraag niet, wel mijn vraag. Jij hebt het over een specifiek probleem dat op kan treden bij het gebruiken van GUID's omdat ze niet per definitie uniek hoeven te zijn. Een mogelijke oplossing daarvoor kan zijn om gebruik te maken van een generieke sequence. De id's zijn dan niet random maar wel gegarandeerd uniek. Dat kan voor database implementaties praktischer zijn omdat je dan in principe geen duplicates kan krijgen.
In hoeverre is jouw oplossing dan relevant voor mij? Wat heeft dat te maken met de hoofdvraag of je een check zou moeten doen op een GUID of deze al bestaat?

Ik ben ook nog wel zover, dat als je -geen- GUID meer gaat gebruiken, dat je ook geen check meer hoeft te doen. Mja, dan ontgaat het nut van een discussie over een bepaald onderwerp nogal hard.

Dus ja, het klopt maar ik ben toch niet op zoek naar een praktische/technische oplossing, ik ben benieuwd naar de discussie rond dit onderwerp. Iets wat blijkbaar niet heel duidelijk is dan.

Acties:
  • 0 Henk 'm!

  • Douweegbertje
  • Registratie: Mei 2008
  • Laatst online: 27-07 22:50

Douweegbertje

Wat kinderachtig.. godverdomme

Topicstarter
gekkie schreef op dinsdag 04 augustus 2015 @ 14:44:
[...]

Dan zijn we eruit .. als je een GUID nergens voor gebruikt .. zijn er ook geen problemen en hoef je ook niet te checken. Had dat dan gelijk gezegd joh !
Echt als je zo ontzettend lomp gaat doen omdat je zelf de discussie niet snapt, ga dan ook gewoon niet meer reageren.

Acties:
  • 0 Henk 'm!

  • Russel88
  • Registratie: Juli 2009
  • Laatst online: 23:59
Sorry hoor. Zo duidelijk was je niet dat je een algemene discussie wilt hebben.
Snap ook niet wat er zoveel over te discuseren valt. Als je het gebruikt als unieke veld, dan zet je er toch gauw een unieke index erop. Is niet gratis, maar nog steeds effectiever dan eerst een select uit te voeren.

Acties:
  • 0 Henk 'm!

  • gekkie
  • Registratie: April 2000
  • Laatst online: 17:07
Douweegbertje schreef op dinsdag 04 augustus 2015 @ 14:47:
[...]
Echt als je zo ontzettend lomp gaat doen omdat je zelf de discussie niet snapt, ga dan ook gewoon niet meer reageren.
Tsja je vraagt of je een check moet implementeren .. zonder het over de rest van een implementatie te willen hebben. Lijkt me dat daar lastig over te discussieren valt ? In het ene geval wel .. in het andere niet is dan maar de laatste bijdrage. ;w

Acties:
  • 0 Henk 'm!

  • Tsurany
  • Registratie: Juni 2006
  • Niet online

Tsurany

⭐⭐⭐⭐⭐

Douweegbertje schreef op dinsdag 04 augustus 2015 @ 14:46:
In hoeverre is jouw oplossing dan relevant voor mij? Wat heeft dat te maken met de hoofdvraag of je een check zou moeten doen op een GUID of deze al bestaat?
Het is een mogelijke alternatieve oplossing om problemen met duplicate GUID's te omzeilen door überhaupt geen gebruik te maken van random gegenereerde data maar juist gestructureerde data. Als het gaat om een unieke sleutel in een database is een GUID wellicht een stuk minder praktisch dan een sequence. Maar dat is ook deels afhankelijk van je verdere ontwerp.
Ik ben ook nog wel zover, dat als je -geen- GUID meer gaat gebruiken, dat je ook geen check meer hoeft te doen. Mja, dan ontgaat het nut van een discussie over een bepaald onderwerp nogal hard.
Ik wist niet dat je zo streng was. Een alternatieve oplossing lijkt mij een valide uitstapje. Immers, waarom zou je niet willen kijken of de foutsituatie überhaupt te voorkomen is voor je gaat nadenken over het afhandelen er van?
Dus ja, het klopt maar ik ben toch niet op zoek naar een praktische/technische oplossing, ik ben benieuwd naar de discussie rond dit onderwerp. Iets wat blijkbaar niet heel duidelijk is dan.
Nou die discussie is kinderlijk eenvoudig. Als jouw GUID niet gegarandeerd uniek kan zijn heb je drie opties:
1. Van te voren controleren of hij uniek is, zo niet een tweede genereren.
2. Een duplicate key violation afvangen in je code.
3. Niets doen en uitval accepteren.

Afhankelijk van je requirement kan je voor een van die drie opties kiezen. Is de data die je gaat invoeren kritiek dan zou ik 1 of 2 kiezen. Is de data niet kritiek of heb je toevallig een manier om eenvoudig het proces op nieuw te triggeren kan optie 3 ook valide zijn.

SMA SB5.0 + 16x Jinko 310wp OWO + 10x Jinko 310wp WNW |--|--| Daikin 4MXM68N + 1x FTXA50AW + 3x FTXM20N


Acties:
  • 0 Henk 'm!

  • downtime
  • Registratie: Januari 2000
  • Niet online

downtime

Everybody lies

Douweegbertje schreef op dinsdag 04 augustus 2015 @ 14:46:
Dus ja, het klopt maar ik ben toch niet op zoek naar een praktische/technische oplossing, ik ben benieuwd naar de discussie rond dit onderwerp. Iets wat blijkbaar niet heel duidelijk is dan.
Maar het ene gaat niet zonder het andere. De essentie van een GUID is dat ie Globally Unique is. In theorie heb je daar geen checks op nodig. Uniek is uniek.

Dan volgt implementatie en daar ontstaan alle problemen: Je kan van alles bedenken om te garanderen dat die GUID echt wereldwijd uniek is, maar je loopt altijd tegen beperkingen op. In theorie zou je mac-adres (in theorie uniek), UTC-tijd (iets minder uniek), misschien een PID en eventueel nog een counter kunnen combineren, maar dan valt uit het GUID wel van alles te achterhalen over de machine die het GUID heeft gegenereert. Voor sommige toepassingen maakt dat een dergelijk GUID onbruikbaar. In de meeste situaties zal het echter geen enkel punt zijn.

Los van de mogelijke privacy/security issues, loop je ook tegen het probleem aan dat geen enkel deel van de input gegarandeerd uniek is. Mac-adres kun je immers aanpassen, en niemand garandeert dat het mac-adres wat jij gekozen hebt niet op tientallen andere plekken in de wereld ook in gebruik is. Voor de andere parameters die je als input kunt gebruiken, geldt hetzelfde.

Uiteindelijk zul je zelf moeten kiezen. Komen duplicaat GUID vaak genoeg voor om een echt probleem te vormen of ben je dan op spoken aan het jagen? Your choice. Hopelijk laat je implementatiedetails wel mede bepalen wat je uiteindelijk kiest.

Acties:
  • 0 Henk 'm!

  • Coca-Cola
  • Registratie: Maart 2001
  • Laatst online: 19:50
Verplichte link bij GUID gerelateerde discussies :+
http://blogs.msdn.com/b/oldnewthing/archive/2004/02/11/71307.aspx

Acties:
  • 0 Henk 'm!

  • roy-t
  • Registratie: Oktober 2004
  • Laatst online: 11-07 16:55
Hahah, dat is wel een erg leuk verhaal!




Als je de GUIDs gebruikt als primary key in de database dan kun je beter een GUIDComb gebruiken. GUIDs, zijn doordat ze toch vrij random zijn heel erg slecht om te gebruiken als clustered index. Een GUIDComb is deels sequentieel en daardoor sneller in gebruik. Zie bijvoorbeeld de implementatie van NHibernate https://github.com/nhiber...e/Id/GuidCombGenerator.cs

Hier staat het bijbehorden artikel van de NHibernate devs http://nhibernate.info/bl...-identifier-strategy.html

spoiler:
Overigens snap ik niet waarom je zo fel op ValHallASW reageerde. Je noemd een belangrijke ontwerpkeuze een flaw en dat was toch echt niet zo, dan mag toch iemand best even uitleggen waarom het juist een sterke keuze was. Anyway Guid v4s doen dit niet meer, dus het is verder ook niet belangrijk meer. En dat mensen vragen waarom je het gaat gebruiken en of andere oplossingen niet handiger zijn lijkt me ook niet meer dan logisch. 8)7

[ Voor 20% gewijzigd door roy-t op 05-08-2015 09:08 ]

~ Mijn prog blog!


Acties:
  • 0 Henk 'm!

Verwijderd

Ondanks dat je vindt dat je implementatie ervan niet uitmaakt, ben ik van mening dat je een Guid nooit expliciet hoeft te controleren. Unique constraint is sowieso goed om te doen (je gaat altijd wel een keer iemand krijgen die denkt dat 'ie met de hand in de database moet zitten). Maar als je tijdens het ontwikkelen al een collision hebt dan zou ik eens heel goed gaan kijken naar hoe Guids geimplementeerd zijn.

Het is natuurlijk maar een N=1, maar wij gebruiken altijd Guids als primary keys, en ik heb nog nooit een collision gezien tenzij er een programmeerfout bij hoorde.

Overigens is het cool dat SQL Server (of welke SQL dan ook) Guids kan genereren, maar één van de voordelen boven een auto increment is natuurlijk wel dat je ze in je client kunt genereren en gebruiken voordat je de boel opslaat. Zo hoef je het gegenereerde ID niet later op te halen. Dit is natuurlijk afhankelijk van je use case, maar iets waar wij op het werk altijd graag gebruik van maken.

edit: Leuk verhaal, Coca-Cola! :)

Acties:
  • 0 Henk 'm!

  • gekkie
  • Registratie: April 2000
  • Laatst online: 17:07
Verwijderd schreef op woensdag 05 augustus 2015 @ 15:49:
Overigens is het cool dat SQL Server (of welke SQL dan ook) Guids kan genereren, maar één van de voordelen boven een auto increment is natuurlijk wel dat je ze in je client kunt genereren en gebruiken voordat je de boel opslaat. Zo hoef je het gegenereerde ID niet later op te halen. Dit is natuurlijk afhankelijk van je use case, maar iets waar wij op het werk altijd graag gebruik van maken.
Opzich lijkt me dat niet het duurste aspect als je een RETURNING statements gebruikt en je guid of objid op basis van een sequence retourneert (de database heeft die gegevens immers al paraat van de rows affected by INSERT of UPDATE zelf).

Uit interessese, hoeveel rows bevatten die tabellen dan (en ook indexen) ?
Bij een wat groter aantal lijkt me dat je een merkbare penalty krijgt op een INSERT op een tabel met zeg 10 miljoen rijen met guids en een unique constraint.

Misschien maar eens testen zo :)

Acties:
  • 0 Henk 'm!

Verwijderd

gekkie schreef op woensdag 05 augustus 2015 @ 18:39:
[...]

Opzich lijkt me dat niet het duurste aspect als je een RETURNING statements gebruikt en je guid of objid op basis van een sequence retourneert (de database heeft die gegevens immers al paraat van de rows affected by INSERT of UPDATE zelf).
Dat is op zich waar, als je de statements direct uitvoert. Wij maken gebruik van ORM (Entity Framework), waarbij de statements pas worden uitgevoerd als je SaveChanges aangeroepen hebt. Tot die tijd zijn alle IDs dus leeg, als je ze niet zelf al aangemaakt had.
Uit interessese, hoeveel rows bevatten die tabellen dan (en ook indexen) ?
Bij een wat groter aantal lijkt me dat je een merkbare penalty krijgt op een INSERT op een tabel met zeg 10 miljoen rijen met guids en een unique constraint.

Misschien maar eens testen zo :)
Ik zal het morgen als ik op m'n werk ben eens bekijken, maar een redelijk aantal volgens mij. We gebruiken SQL Server onder andere om logs in te schrijven van onze (SOA) midoffice applicatie, dus dat zal zo tussen de 0 en 1000 rijen per minuut opleveren afhankelijk van gebruik. Insert performance is niet briljant, maar we loggen zoveel mogelijk asynchroon en het is niet alsof we aan iets werken met heel veel throughput. Kan me inderdaad voorstellen dat als je dat wel doet, dit niet erg handig is.

Bij ons is de afweging tussen performance en programmeer- / onderhoudsgemak dan ook bijna altijd richting het laatste.

Acties:
  • 0 Henk 'm!

  • gekkie
  • Registratie: April 2000
  • Laatst online: 17:07
Verwijderd schreef op woensdag 05 augustus 2015 @ 19:18:
[...]
Dat is op zich waar, als je de statements direct uitvoert. Wij maken gebruik van ORM (Entity Framework), waarbij de statements pas worden uitgevoerd als je SaveChanges aangeroepen hebt. Tot die tijd zijn alle IDs dus leeg, als je ze niet zelf al aangemaakt had.
Is dat dan ook gelijk de hoofd motivatie voor het gebruik van de GUID's ?
"Vooraf / tijdens werken met nog niet gepersisteerde data wel een ID hebben bij gebruik van een ORM" waarbij de kans dan zeer groot is dat het ook de permanent ID wordt omdat de kans op een collision vrij klein is (maar je checkt hem wel in de database layer middels de unique constraint)

Kan opzich nog andere use cases bedenken als liever een pseudo random nummer als object id's richting de client sturen wat toch iets moeilijker goed te raden is dan een sequence. Al hangt het nogal van de gekozen implementatie/versie af.

En als je om de een of andere manier echt niet zelf centraal een (server/client) id kunt uitdelen dat je kan combineren met een sequence.
Ik zal het morgen als ik op m'n werk ben eens bekijken, maar een redelijk aantal volgens mij. We gebruiken SQL Server onder andere om logs in te schrijven van onze (SOA) midoffice applicatie, dus dat zal zo tussen de 0 en 1000 rijen per minuut opleveren afhankelijk van gebruik. Insert performance is niet briljant, maar we loggen zoveel mogelijk asynchroon en het is niet alsof we aan iets werken met heel veel throughput. Kan me inderdaad voorstellen dat als je dat wel doet, dit niet erg handig is.
Bij ons is de afweging tussen performance en programmeer- / onderhoudsgemak dan ook bijna altijd richting het laatste.
Opzich is ORM wel vaker niet echt een stimulans voor de performance, dus wellicht dat je dan ook niet echt een verschil merkt. Maar een kleine google op (g|u)uids als PK of FK levert niet al te rooskleurige beelden op:
http://www.sqlskills.com/...andor-the-clustering-key/ bijvb.

Voor deze toepassing is een benchmark met de GUID-COMB dan wel interessant. Waar dat staat tov een normale GUID(v4) en een sequence gebruiken.

[ Voor 3% gewijzigd door gekkie op 05-08-2015 19:56 ]


Acties:
  • 0 Henk 'm!

Verwijderd

Het werken met nog niet gepersisteerde data is wel een van de belangrijkste redenen ja. Eigenlijk de enige goede reden die ik nu kan bedenken die voor ons van toepassing is. Het niet kunnen raden is er ook wel een, maar omdat we met een intranetapplicatie werken iets minder belangrijk.

En inderdaad, de Guids zijn over het algemeen goed en het feit dat er toch een collision op kan treden (wat mij betreft theoretisch) nemen we voor lief omdat we redelijk goede foutafhandeling en recovery hebben. Dit zal dan wel een handmatige herstelactie worden, maar de kans dat het optreedt is zo klein dat we dat liever doen dan overal failsafes inbouwen.

Je hebt inderdaad gelijk dat ORM meestal niet echt helpt met de performance. Zoals gezegd nemen we die penalty over het algemeen voor lief. Specifiek voor dit logging stukje gebruiken we geen ORM en hadden we dus inderdaad geen Guids hoeven gebruiken. Ook voor specifieke zaken zoals zoeken gebruiken we handgeschreven stored procedures i.c.m. PetaPoco (Micro ORM, bijna geen performance overhead maar ook veel minder features dan EF).

Acties:
  • 0 Henk 'm!

  • Douweegbertje
  • Registratie: Mei 2008
  • Laatst online: 27-07 22:50

Douweegbertje

Wat kinderachtig.. godverdomme

Topicstarter
Ja ik reageerde misschien fel, maar ben ik nu gek of zijn de laatste berichten gewoon leuke stof? Jullie hebben het nu allemaal over zaken zonder diep in te gaan over de implementatie. Het is niet direct dat ik de moeite niet wil nemen om gedegen informatie te geven om tot een oplossing te komen, alleen heel het punt is dat ik geen oplossing zoek maar juist jullie "gedachte" wilde hebben over dit euvel. Plus ik kan niet eens diep er op in gaan (contract bijv...)
Het punt is juist dat de algemene of onbeschreven regel bestaat dat je input controleert en uiteraard afvangt. Echter dat is juist het punt, van dat je eigenlijk -weet- dat het uniek is, maar toch stiekem niet uniek hoeft te zijn. Heel mijn insteek gaat daar over, de daadwerkelijk implementatie boeit niet. Verder kun je het over allerlei zaken hebben, die gewoon algemeen zijn, zoals nu ook gebeurde :)

Wellicht raak ik daarom geïrriteerd omdat het vaker voorkomt dat het over één onderwerp gaat en mensen opeens appels met peren gaan vergelijken en veel te diep in de stof duiken terwijl iemand daar niet op zit te wachten. Bekijk het eens van de andere kant, er is een applicatie waar jaren aan gewerkt is, vele manuren zitten daar in, hele plannen zijn uitgedacht en iemand gaat op een forum, in een "random" discussie (snap je hem) even vertellen van "nou.. is je implementatie wel goed?". Kom op. Niet dat ik niets aan allerlei input heb, en ik weet zeker dat als heel Tweakers naar mijn code kijkt dat er tientallen verbeteringen op gevonden worden, maar als ik ergens over wil praten puur over een verkapte stelling: laat mij dan niet mijn interne applicatie gaan beschrijven.
Prima als je doorvraagt indien iemand vast loopt of iets, of direct een oplossing wilt voor zijn probleem, maar nogmaals daar heb ik het niet eens over.
Dus ja, "sorry", in hoeverre dat wat waard is, maar daarom reageerde ik bot.

Wil je echt eens weten waarvoor het allemaal wordt gebruikt en met hoeveel data ik werk en waarom ik waarschijnlijk ook een collision heb gekregen; dat kan met een biertje ergens zonder dat het zwart-wit op papier komt. En tja, anders moet je het met een algemene stelling doen. :)


Verder nog over efficiëntie: we hebben wel een CL PK op de GUID zitten. Qua performance valt het reuze mee:


Afbeeldingslocatie: http://i.imgur.com/MbuQq1M.png

Afbeeldingslocatie: http://i.imgur.com/yTH8WcM.png

En ja, dat is ook met miljoenen rows :)

Acties:
  • 0 Henk 'm!

  • Gomez12
  • Registratie: Maart 2001
  • Laatst online: 17-10-2023
gekkie schreef op woensdag 05 augustus 2015 @ 19:46:
[...]
Maar een kleine google op (g|u)uids als PK of FK levert niet al te rooskleurige beelden op:
http://www.sqlskills.com/...andor-the-clustering-key/ bijvb.
Let er wel op dat wat daar staat niet zozeer met Guid's te maken heeft, maar dat het gewoon algemeen gedrag is met grotere keys die niet sequential-generated zijn.

In principe gaat het overal voor op behalve echte daadwerkelijke (veelal) nietszeggende int-PK's.

En ik ben bijv weer geen voorstander van een nietszeggende int-PK (waardoor ik ook niet echt voorstander ben van Guid, dat is veelal net zo nietszeggend).
Als de requirements al een unique key afdwingen zal ik die veelal eerder gebruiken als PK als er eentje zelf bijmaken waar ik voor de rest niets mee doe.

Ik vind het bijv altijd schitterende databases die bijv een artikel-id hebben en een artikel-nummer. Dan vraag ik altijd : Ziet iemand die id, zoekt iemand op die id? En dan krijg ik steevast te horen : Nee, maar dan zijn we wel lekker flexibel, dan kan een artikelnummer veranderen etc. Maar vraag dan niet door hoe ze de artikelnummers bij de klanten op de facturen gaan aanpassen want dat is dan weer net iets teveel gevraagd.

Acties:
  • 0 Henk 'm!

  • gekkie
  • Registratie: April 2000
  • Laatst online: 17:07
Verwijderd schreef op woensdag 05 augustus 2015 @ 20:26:
En inderdaad, de Guids zijn over het algemeen goed en het feit dat er toch een collision op kan treden (wat mij betreft theoretisch) nemen we voor lief omdat we redelijk goede foutafhandeling en recovery hebben. Dit zal dan wel een handmatige herstelactie worden, maar de kans dat het optreedt is zo klein dat we dat liever doen dan overal failsafes inbouwen.
Maar als ik het goed begreep heb je een unique constraint dus als het goed is check je dus al ?

Het is wel vervelend als er gedurende wat langere tijd er onopgemerkt 2 logins die allebei zelfde guid hebben gekregen bij elkaar zaken gaan overschrijven. Misschien kun je nog wat dingen uit een log reconstrueren maar het lijkt me vrij beroerd. Ik zou zo'n constraint er dus vooral op zetten .. al zou je het niet afvangen en een aantal retries doen .. liever dat de applicatie in die uitzonderingssituatie een foutmelding geeft dan silent corruoption van je gepersisteerde data.
Anders zou ik ook geen ACID compliant Database behoeven.want je kunt je consistentie dus gruwlijk onderuit halen als het je primary keys zijn.
(misschien een beetje als dat verhaaltje van het brugdek wat wel viel .. maar niet op z'n plaats.
het is toch al honderden duizenden keren goed gegaan zo ....)

Acties:
  • 0 Henk 'm!

Verwijderd

De unique constraint checkt het inderdaad, wat ik bedoelde is dat we dan een exceptie krijgen en een proces "vast" loopt. We hebben de mogelijkheid om vastgelopen processen te hervatten, dus dat is niet echt een groot probleem.

Dankzij die unique constraint zou ik er geen probleem mee hebben om dit op de meeste plaatsen toe te passen, tenzij het uiteraard over high availability of realtime systemen gaat. Over het algemeen houden we geen sessies bij in de database (of eigenlijk helemaal niet, lang leve intranet applicaties :)).

Acties:
  • 0 Henk 'm!

  • gekkie
  • Registratie: April 2000
  • Laatst online: 17:07
Douweegbertje schreef op woensdag 05 augustus 2015 @ 22:07:
Ja ik reageerde misschien fel, maar ben ik nu gek of zijn de laatste berichten gewoon leuke stof? Jullie hebben het nu allemaal over zaken zonder diep in te gaan over de implementatie. Het is niet direct dat ik de moeite niet wil nemen om gedegen informatie te geven om tot een oplossing te komen, alleen heel het punt is dat ik geen oplossing zoek maar juist jullie "gedachte" wilde hebben over dit euvel. Plus ik kan niet eens diep er op in gaan (contract bijv...)
Het punt is juist dat de algemene of onbeschreven regel bestaat dat je input controleert en uiteraard afvangt. Echter dat is juist het punt, van dat je eigenlijk -weet- dat het uniek is, maar toch stiekem niet uniek hoeft te zijn. Heel mijn insteek gaat daar over, de daadwerkelijk implementatie boeit niet. Verder kun je het over allerlei zaken hebben, die gewoon algemeen zijn, zoals nu ook gebeurde :)
Misschien dat we wat anders denken over "implementatie" .. dit laatste gaat volgens mij allemaal over implementaties van GUID's ... en soms een specifieke van iemand .. en soms wat abstracter alsin wanneer en waarvoor zou jij het wel willen implementeren en waarneer niet .. en welke GUID versie (of alternatief voor een GUID) is daar wellicht beter geschikt voor dan een andere in die situatie.

Tsja eigenlijk is in het algemeen gezien de naam GUID of UUID niet juist. Het heeft grenzen en die grenzen kun je bereiken. Nou is dat opzich bij een sequence ook zo, vervelende aan een GUID is dat je niet weet wanneer je een collision gaat krijgen. Bij een sequence is het duidelijk wanneer je uit je range gaat lopen en kun je het zonder al te veel kosten monitoren ( je moet het wel heel bont maken wil je in 1 dag uit een bigserial lopen bijvb).
Wellicht raak ik daarom geïrriteerd omdat het vaker voorkomt dat het over één onderwerp gaat en mensen opeens appels met peren gaan vergelijken en veel te diep in de stof duiken terwijl iemand daar niet op zit te wachten. Bekijk het eens van de andere kant, er is een applicatie waar jaren aan gewerkt is, vele manuren zitten daar in, hele plannen zijn uitgedacht en iemand gaat op een forum, in een "random" discussie (snap je hem) even vertellen van "nou.. is je implementatie wel goed?".
Lijkt me nog steeds niets mis mee ... ik zou m'n project er misschien niet voor omgooien .. maar het wel uitzoeken voor een volgend project en alternatieven overwegen.
Kom op. Niet dat ik niets aan allerlei input heb, en ik weet zeker dat als heel Tweakers naar mijn code kijkt dat er tientallen verbeteringen op gevonden worden, maar als ik ergens over wil praten puur over een verkapte stelling: laat mij dan niet mijn interne applicatie gaan beschrijven.
Prima als je doorvraagt indien iemand vast loopt of iets, of direct een oplossing wilt voor zijn probleem, maar nogmaals daar heb ik het niet eens over.
Dus ja, "sorry", in hoeverre dat wat waard is, maar daarom reageerde ik bot.
Owwh ik sla ook voldoende vaak de plank mis .. zowel in reacties als in code .. en ach de botte boer kan ik ook prima uithangen QED .. :> erop (*duik*)
Heb ook met GUID's geworsteld .. o.a. om wat minder logische client side object id's te krijgen, (en ze vervolgens in te zetten als PK) maar ook daar waren voldoende opmerkingen op de randomness .. en dat het als PK ook niet echt briljant was. Dus dat pad heb ik toen maar verlaten.
Wil je echt eens weten waarvoor het allemaal wordt gebruikt en met hoeveel data ik werk en waarom ik waarschijnlijk ook een collision heb gekregen; dat kan met een biertje ergens zonder dat het zwart-wit op papier komt. En tja, anders moet je het met een algemene stelling doen. :)
Met wat abstractie mag ook hoor .. maar bijvb of je het als primary key in zet en waarom (niet of het artikelen of patienten zijn .. maar waarom als PK of FK .. zoals ik nu dus begreep dat ORM een reden kan zijn. (ik peur liever zelf in de DB dus had er niet echt bij stil gestaan).
Het ging me dus om de abstracte implementatie details .. niet over de data die je voor de rest in je tabel hebt staan. Of het wielmoertjes zijn .. vuige purno .. of mijn salaris .. (naja in dat laatste geval valt er misschien nog wat te dealen :p)
Verder nog over efficiëntie: we hebben wel een CL PK op de GUID zitten. Qua performance valt het reuze mee:

[afbeelding]

[afbeelding]

En ja, dat is ook met miljoenen rows :)
En dat moeten we nog bestuderen want de plaatjes doen het natuurlijk niet in het reactie veld :)

Edit: Heb je nog een speciaal kolom type ? en dit is dan met die all random GUIDv4 ?
valt me dan inderdaad verrassend mee qua performance.
Ander puntje wat genoemd wordt tov een sequence is dat je indexsize groter is en daardoor wat sneller niet meer in het geheugen zou kunnen passen. (uiteraard ook weer volstrekt per situatie verschillend). Ik ontwikkel o.a. wat wat ook fijn op een i5je met 8gb geheugen mag draaien .. dat is niet bepaald een monster stamper zeg maar.

[ Voor 4% gewijzigd door gekkie op 05-08-2015 22:39 ]


Acties:
  • 0 Henk 'm!

  • gekkie
  • Registratie: April 2000
  • Laatst online: 17:07
Verwijderd schreef op woensdag 05 augustus 2015 @ 22:22:
De unique constraint checkt het inderdaad, wat ik bedoelde is dat we dan een exceptie krijgen en een proces "vast" loopt. We hebben de mogelijkheid om vastgelopen processen te hervatten, dus dat is niet echt een groot probleem.

Dankzij die unique constraint zou ik er geen probleem mee hebben om dit op de meeste plaatsen toe te passen, tenzij het uiteraard over high availability of realtime systemen gaat. Over het algemeen houden we geen sessies bij in de database (of eigenlijk helemaal niet, lang leve intranet applicaties :)).
Mjah kans dat je gelijk een 2e collision krijgt is ook niet heel groot zolang je niet de hele range op gebruikt hebt. Zolang je daar ver onder blijft hou je dan hooguit een hickupje over (opzich wel fijn om te loggen .. weet je gelijk dat je niet echt verder hoeft te zoeken .. tenzij ze ineens meerdere keren achter elkaar voor komen).
Gomez12 schreef op woensdag 05 augustus 2015 @ 22:09:
[...]
Let er wel op dat wat daar staat niet zozeer met Guid's te maken heeft, maar dat het gewoon algemeen gedrag is met grotere keys die niet sequential-generated zijn.

In principe gaat het overal voor op behalve echte daadwerkelijke (veelal) nietszeggende int-PK's.
Klopt maar het is wel iets wat dus samenhangd met het gebruik van GUID voor sommige toepassingen. En een sequential PK heeft iets meer zeggingskracht in die zin dat het nog aangeeft of iets voor iets of na iets anders in de DB is beland. Zou je eventueel bij debuggen of consistency check nog kunnen helpen. Bij tree-based zou je bijvb geen papa's verwachten met een hoger id dan de descendants (tenzij je dingen laat moven ipv copy).
En ik ben bijv weer geen voorstander van een nietszeggende int-PK (waardoor ik ook niet echt voorstander ben van Guid, dat is veelal net zo nietszeggend).
Als de requirements al een unique key afdwingen zal ik die veelal eerder gebruiken als PK als er eentje zelf bijmaken waar ik voor de rest niets mee doe.

Ik vind het bijv altijd schitterende databases die bijv een artikel-id hebben en een artikel-nummer. Dan vraag ik altijd : Ziet iemand die id, zoekt iemand op die id? En dan krijg ik steevast te horen : Nee, maar dan zijn we wel lekker flexibel, dan kan een artikelnummer veranderen etc. Maar vraag dan niet door hoe ze de artikelnummers bij de klanten op de facturen gaan aanpassen want dat is dan weer net iets teveel gevraagd.
Mjah heb momenteel een beetje een combie van zowel tree-like data ... ja leuk een graph DB dan maar .. maar ook document like ... hmm knopen we er mongo aan ... jolly cijferwerk en statistiek .. toch maar weer een RDBMS.
Maar goed dan zit je in je RDBMS dus toch al gauw met object id's papa's kindjes en alle familie problematiek die je daarbij tegenkomt. Dan gebruik ik daar toch nog liever nietszeggende int's voor dan guid's eigenlijk. Nu een expirimentje of het ltree datatype van postgres een beetje wil performen voor het tree aspect. Maar vindt het nog wat tegenvallen.

[ Voor 52% gewijzigd door gekkie op 05-08-2015 22:54 ]


Acties:
  • 0 Henk 'm!

  • Douweegbertje
  • Registratie: Mei 2008
  • Laatst online: 27-07 22:50

Douweegbertje

Wat kinderachtig.. godverdomme

Topicstarter
Wat voor mij van belang is, en de reden dat ik (of we) guids gebruiken is dat het out of the box werkt. In elke taal waar we in werken heb je het zo gegenereerd, zelfs op DB niveau. Het zorgt ervoor dat het gebruikt kan worden voor de user, denk hierbij aan een bestand dat uitgelezen wordt. Hierbij kun je direct het GUID gebruiken zonder dat men een ander bestand kan "raden".
Daarbij geven 3e partijen ons data, ook met GUID's, en hoef ik niets om te zetten waarbij ik de relaties intact kan houden.

Nog als extra, er worden veel reads op uitgevoerd, en relatief gezien minder inserts. Er worden nooit joins op uitgevoerd en dan kun je er met gemak mee weg komen. Dus ook met de hoeveelheid inserts kun je de fragementation een beetje bijhouden.

Veel blogs wat je leest e.d. gaan uit van simpele ID's, waarbij er eigenlijk geen enkele reden is om een GUID als PK te gebruiken. Vandaar misschien ook de haat voor een GUID als index/key.

Als je ook mijn execution plans ziet, is dat echt peanuts qua i/o en wat dan ook. Qua index size.. daar lig ik eigenlijk al helemaal niet wakker van. Ik heb vele inefficientere tables ertussen zitten. Dus als je puur naar performance kijkt, maakt het eigenlijk geen drol uit.

Ik kan mij voorstellen dat als je richting de 500m records gaat, enorm veel inserts worden gedaan, en de GUID wordt gebruikt voor joins... dat je dan eens moet nadenken waarom je nog voor een GUID als PK gaat. Maar goed, meestal zit je met zoveel data al aan andere oplossingen te denken.

Acties:
  • 0 Henk 'm!

  • Gomez12
  • Registratie: Maart 2001
  • Laatst online: 17-10-2023
gekkie schreef op woensdag 05 augustus 2015 @ 22:33:
[...]
En een sequential PK heeft iets meer zeggingskracht in die zin dat het nog aangeeft of iets voor iets of na iets anders in de DB is beland.
Ik zou zeggen kijk je manual van je db nog eens goed na, want volgens mij heeft geen enkel zinnig RDBMS dit zo in de specs staan...

Het is leuk dat het tijdelijk zo werkt, maar meeste RDBMS'en die ik ken gaan na het hoogste id uitgegeven te hebben gewoon terug naar nul en dan kijken naar het eerst beschikbare id, waardoor er nadat je 1x rond de klok bent gegaan er niets meer te zeggen valt over wanneer iets erin is beland adv het id.

Het lijkt mij ook een ietwat vreemde constraint voor een serieus RDBMS om een totalitair gemaximaliseerd aantal nieuwe records in de db te mogen hebben. Je mag concurrent maar het max aantal records hebben, maar het kan niet zo zijn dat jij 5 jaar geleden een foutje hebt gemaakt (en 99% van de ints opgebruikt) en dat dat allemaal gedelete is en dat je nu geen nieuwe records meer kan toevoegen.

Een sequential PK is gewoon simpelweg compleet nietszeggend als het niet uit de data zelf komt, wil jij een insertion volgorde weten dan zul je die zelf moeten bijhouden, dat doet een sequential PK juist niet.

Acties:
  • 0 Henk 'm!

  • gekkie
  • Registratie: April 2000
  • Laatst online: 17:07
Gomez12 schreef op woensdag 05 augustus 2015 @ 23:07:
[...]
Ik zou zeggen kijk je manual van je db nog eens goed na, want volgens mij heeft geen enkel zinnig RDBMS dit zo in de specs staan...

Het is leuk dat het tijdelijk zo werkt, maar meeste RDBMS'en die ik ken gaan na het hoogste id uitgegeven te hebben gewoon terug naar nul en dan kijken naar het eerst beschikbare id, waardoor er nadat je 1x rond de klok bent gegaan er niets meer te zeggen valt over wanneer iets erin is beland adv het id.
Klopt .. zoals ik hier boven ook al wel ergens aangaf heeft ook een sequence grenzen.
Het voordeel wat ik er aan vindt is dat je weet wanneer je je wraparound en de gevolgen daarvan kunt gaan verwachten. Met een volledig random GUID kun je gelijk je lot uit de loterij trekken.
Theoretisch zou je zelfs een nooit werkende app kunnen krijgen omdat je altijd dezelfde GUID krijgt, hoe uitzonderlijk ook.
Het lijkt mij ook een ietwat vreemde constraint voor een serieus RDBMS om een totalitair gemaximaliseerd aantal nieuwe records in de db te mogen hebben. Je mag concurrent maar het max aantal records hebben, maar het kan niet zo zijn dat jij 5 jaar geleden een foutje hebt gemaakt (en 99% van de ints opgebruikt) en dat dat allemaal gedelete is en dat je nu geen nieuwe records meer kan toevoegen.

Een sequential PK is gewoon simpelweg compleet nietszeggend als het niet uit de data zelf komt, wil jij een insertion volgorde weten dan zul je die zelf moeten bijhouden, dat doet een sequential PK juist niet.
Ik ga ook niet snel met een hele kleine sequence zitten, ook dat is een trade-off want ook die krengen kosten ruimte. Maar tot de redelijk predictable wraparound kun je er dus wel iets (letop iets) meer uithalen dan uit iets volledig randoms .. ik was inderdaad niet van plan m'n applicatie logica er aan vast te knopen. Maar stel dat de handel in de poeier is gevlogen .. en je hebt geen wraparound gehad .. dan zou je er dus wel dingen uit af kunnen leiden die je kunnen helpen in geval van disaster.

In postgresql wrapped tie btw niet by default.

Acties:
  • 0 Henk 'm!

  • gekkie
  • Registratie: April 2000
  • Laatst online: 17:07
Douweegbertje schreef op woensdag 05 augustus 2015 @ 22:54:
Wat voor mij van belang is, en de reden dat ik (of we) guids gebruiken is dat het out of the box werkt. In elke taal waar we in werken heb je het zo gegenereerd, zelfs op DB niveau. Het zorgt ervoor dat het gebruikt kan worden voor de user, denk hierbij aan een bestand dat uitgelezen wordt. Hierbij kun je direct het GUID gebruiken zonder dat men een ander bestand kan "raden".
Daarbij geven 3e partijen ons data, ook met GUID's, en hoef ik niets om te zetten waarbij ik de relaties intact kan houden.
Hmm zo te zien proberen ze het bij SQL server ook wel bruikbaarder te maken:
https://technet.microsoft.com/en-sg/library/ms189786.aspx
Alleen dus wel weer als tradeoff dat je het niet meer moet gaan gebruiken voor het obfuscaten van objectid's voor de clientside.

Dus voor jouw toepassing (raden van user files zoals vroeger wel gebruikelijk door ze in een dir (structuur) te dumpen aan de hand van voorheen md5 of sha1sums) is deze optimalisatie niet echt bruikbaar. (hee hier komen dus m'n implementatie details om de hoek kijken .. sommige versies en optimalisaties maken ze daar dus minder geschikt voor).

Dat laatste kan inderdaad een voordeel zijn, al zijn bij mij de imports meestal beperkt van omvang dus werk ik met een translatie tabel. Bovendien moeten objecten vaak aan al bestaande users of andere users worden gehangen. Dus ik ontkom er eigenlijk toch niet aan om dat te implementeren. Dus dan maar liever een implementatie voor alles. Lijkt me wel vervelend / risicovol als je precies daar een collision in krijgt. Neem aan dat je hele import dan ook 1 grote transactie is die gerollbackt kan worden.
Nog als extra, er worden veel reads op uitgevoerd, en relatief gezien minder inserts. Er worden nooit joins op uitgevoerd en dan kun je er met gemak mee weg komen. Dus ook met de hoeveelheid inserts kun je de fragementation een beetje bijhouden.

Veel blogs wat je leest e.d. gaan uit van simpele ID's, waarbij er eigenlijk geen enkele reden is om een GUID als PK te gebruiken. Vandaar misschien ook de haat voor een GUID als index/key.

Als je ook mijn execution plans ziet, is dat echt peanuts qua i/o en wat dan ook. Qua index size.. daar lig ik eigenlijk al helemaal niet wakker van. Ik heb vele inefficientere tables ertussen zitten. Dus als je puur naar performance kijkt, maakt het eigenlijk geen drol uit.

Ik kan mij voorstellen dat als je richting de 500m records gaat, enorm veel inserts worden gedaan, en de GUID wordt gebruikt voor joins... dat je dan eens moet nadenken waarom je nog voor een GUID als PK gaat. Maar goed, meestal zit je met zoveel data al aan andere oplossingen te denken.
Mjah dat was dus ook mijn insteek .. als je een goede reden hebt zijn GUID's opzich wel prima .. maar het zou niet mijn eerste keuze zijn. Maar het kan best zijn dat aanverwante voordelen zo hard optellen dat eventuele performance invloeden en een occasional hickup door een afgevangen collision een prima of zelfs de betere oplossing is. Maar dat de ene GUID de andere dus ook niet is, als je de randomness echt nodig hebt kun je niet ook van de optimalisaties gebruik maken.

Dus er zitten wel her en der wat misschien niet altijd even evidente haken en ogen aan .. afhankelijk van de RDBMS .. waarvoor je het gebruikt .. wat je database load is (read/write/mixed) .. welke GUID versie je gebruikt ..

Acties:
  • 0 Henk 'm!

Verwijderd

Verwijderd schreef op woensdag 05 augustus 2015 @ 19:18:
Ik zal het morgen als ik op m'n werk ben eens bekijken, maar een redelijk aantal volgens mij.
Zoals beloofd: ben nu op m'n werk, dus:
1 DB met ~3 miljoen rijen, auto increment met ~500 inserts per minuut
1 DB met ~31 miljoen rijen, Guid met ~355 inserts per minuut

Performance merken we weinig van omdat het allemaal óf asynchroon is, of in een achtergrondproces.

Acties:
  • 0 Henk 'm!

  • gekkie
  • Registratie: April 2000
  • Laatst online: 17:07
Hmm heb hier zelf ook wat getracht te benchen met postgres op een relatief simpele en kleine tabel met 10 miljoen rijen.
De variatie in load en de ping vanaf m'n laptop lijken een grotere invloed te hebben dan het verschil in insert tijd, sequence komt er qua gemiddelde altijd wel iets beter uit als de uuid, maar de min en max zijn dermate breed dat er nogal wat verstoring is op de vrij korte insert tijden.
Maar de verschillen zijn dus dermate klein dat je daar inderdaad in iedergeval niet snel een probleem hebt, hou je wellicht de joins over, had een iets groter verschil verwacht. Achja iets met proof en pudding en eten :)

(getest met uuidv4's in uuid veld, text veld met uuid en een bigserial sequence, alle als primary key en dus met not null en unique constraint)

Acties:
  • 0 Henk 'm!

  • creator1988
  • Registratie: Januari 2007
  • Laatst online: 22:17
Hoezo zou je een collision kunnen krijgen? GUIDs zijn ontworpen zodat ze unique in tijd en ruimte zijn.

Om nog maar eens een MSDN blogpost te plaatsen:

http://blogs.msdn.com/b/e.../guid-guide-part-two.aspx


edit: SQL Server gebruikt blijkbaar guid v4, die zijn gewoon random.

[ Voor 17% gewijzigd door creator1988 op 12-08-2015 16:18 ]


Acties:
  • 0 Henk 'm!

  • RobIII
  • Registratie: December 2001
  • Niet online

RobIII

Admin Devschuur®

^ Romeinse Ⅲ ja!

(overleden)
creator1988 schreef op woensdag 12 augustus 2015 @ 16:07:
Hoezo zou je een collision kunnen krijgen? GUIDs zijn ontworpen zodat ze unique in tijd en ruimte zijn.
[...]
edit: SQL Server gebruikt blijkbaar guid v4, die zijn gewoon random.
Los van welke versie GUID er gebruikt wordt: wat als je gegevens importeert en je collega importeert diezelfde gegevens, al dan niet abuis, nogmaals? Het is compleet afhankelijk van het scenario of een check op duplicate keys / collisions nodig (of zelfs lonend) is of niet, zoals in -tig posts in dit topic al aangegeven.

There are only two hard problems in distributed systems: 2. Exactly-once delivery 1. Guaranteed order of messages 2. Exactly-once delivery.

Je eigen tweaker.me redirect

Over mij


Acties:
  • 0 Henk 'm!

  • Douweegbertje
  • Registratie: Mei 2008
  • Laatst online: 27-07 22:50

Douweegbertje

Wat kinderachtig.. godverdomme

Topicstarter
creator1988 schreef op woensdag 12 augustus 2015 @ 16:07:
Hoezo zou je een collision kunnen krijgen? GUIDs zijn ontworpen zodat ze unique in tijd en ruimte zijn.

Om nog maar eens een MSDN blogpost te plaatsen:

http://blogs.msdn.com/b/e.../guid-guide-part-two.aspx


edit: SQL Server gebruikt blijkbaar guid v4, die zijn gewoon random.
Je weet dat in precies dat artikel wat je zelf plaatste ook zat voorbeelden staan waardoor je een collision kan krijgen? :p

In elk geval in mijn situatie; ik had een conversie en ging er eigenlijk wel vanuit dat alles mooi uniek zou zijn. Lucky me kreeg alleen een collision. Je moet dan bedenken dat er ooit een tijd was dat meerdere systemen GUID's aan het maken waren, dus 'naast elkaar'. Jaren later wordt dit gemerged. In zekere zin kun je dan "makkelijker" een collision krijgen. Natuurlijk afhankelijk van een x-aantal factoren om deze kans te vergroten zoals; geen fysieke netwerkkaart (virtuele machines), enorm veel data, vaste tijdstippen van het genereren van de data etc. etc.
Uiteindelijk heb ik ook mijn les geleerd om nu altijd nieuwe GUID's te generen om in elk geval een collision kans vrijwel nihil te maken.

  • Gomez12
  • Registratie: Maart 2001
  • Laatst online: 17-10-2023
creator1988 schreef op woensdag 12 augustus 2015 @ 16:07:
edit: SQL Server gebruikt blijkbaar guid v4, die zijn gewoon random.
Ik hoop niet dat guid v4 random zijn, dan heb je juist collisions...

Random (nouja, bij computers heb je daar nog wat additionele problemen mee maargoed) houdt juist geen rekening met voorgaande waardes.
Tien keer 1 achter elkaar is wel random mogelijk, maar wil je juist niet als GUID hebben.

Oftewel in een goede guid v4 implementatie zit juist een gedeelte voorspelbaar (bijv tijd / mac-adres etc) en een gedeelte random, zodat het voorspelbare gedeelte ervoor zorgt dat het geen probleem is dat je random generaties collisions zijn.

Zie ook een eerdere link hier in dit topic waar uitgelegd wordt dat een GUID enkel een GUID is als je het als totaal bekijkt, ga je enkel een gedeelte pakken (maakt niet zoveel uit welk gedeelte of op welke manier) dan verliest het de waarde van een GUID omdat je kans op collisions explosief gaat stijgen.
Douweegbertje schreef op woensdag 12 augustus 2015 @ 23:15:
[...]
Uiteindelijk heb ik ook mijn les geleerd om nu altijd nieuwe GUID's te generen om in elk geval een collision kans vrijwel nihil te maken.
Deze snap ik even niet, wat bedoel je hiermee? Als ik data zou mergen zou ik een check zetten op uniekheid van een GUID en als die getroffen wordt een nieuwe genereren, maar ik zie de toegevoegde waarde niet in van het per definitie opnieuw uitgeven van een GUID.

Eerlijk gezegd zie ik er alleen maar een mogelijk gevaar in dat als de generatiesnelheid hoog genoeg ligt dat ik alsnog een collision genereer die er eerst niet was.
Een normale GUID generatie wordt geholpen doordat er bijna altijd nog een proces achterhangt wat ook tijd kost waardoor de tijd variabele ook mee gaat veranderen.
Maar ga je echt een situatie creëren dat je bijv 1 miljard GUID's per seconde gaat genereren (omdat je echt niets anders doet dan dat, let op getallen zijn fictief) dan schakel je voor een groot gedeelte het tijd-gedeelte uit waardoor je in principe alleen nog maar rust op je random number generator en je sequence grootte.
Ergens zit er een grens aan en ik heb dan meer zoiets van : herberekenen waar vanwege een toevallige ionen-fluctuatie op pluto er een collision is, maar van de rest lekker afblijven, die is al uniek en ga ik niet unieker kunnen krijgen.

Het is net zoiets als een hash van een hash trekken, je kan het doen om de doorloopsnelheid te vertragen, maar in wezen ga je meer collisions krijgen omdat je eerste hash op een onbeperkte grootte van input werkt, en je 2e hash alleen nog maar op de max hash-grootte die uit de 1e gekomen is.

  • Douweegbertje
  • Registratie: Mei 2008
  • Laatst online: 27-07 22:50

Douweegbertje

Wat kinderachtig.. godverdomme

Topicstarter
Gomez12 schreef op donderdag 13 augustus 2015 @ 00:19:
[...]


[...]

Deze snap ik even niet, wat bedoel je hiermee? Als ik data zou mergen zou ik een check zetten op uniekheid van een GUID en als die getroffen wordt een nieuwe genereren, maar ik zie de toegevoegde waarde niet in van het per definitie opnieuw uitgeven van een GUID.
Nou, ik heb geen invloed noch kennis over hoe die "oude" GUID's gemaakt zijn. Sommige dateren nog uit het steentijdperk qua datum. Ik "vertrouw" ze niet, en maak daarom liever nieuwe aan. Als je uit een xxx-aantal systemen een groot aantal GUID's over letterlijk jaren van genereren krijgt, dan zie ik daar een grotere kans in collisions in, dan dat ik nu met één systeem de "vernieuwde" GUID's ga draaien.

Ter info, ik heb al een grote base met GUID's en daar kwamen die andere (van conversies dus) in


Misschien lul ik nu wel bullshit en is het technisch of wiskundig gezien onzin, maar al met al heb ik dus al één collision gehad :p

  • gekkie
  • Registratie: April 2000
  • Laatst online: 17:07
Douweegbertje schreef op donderdag 13 augustus 2015 @ 00:29:
[...]
Misschien lul ik nu wel bullshit en is het technisch of wiskundig gezien onzin, maar al met al heb ik dus al één collision gehad :p
Ik bewaar de mijne nog even voor de jackpot in de loterij ;)

  • gekkie
  • Registratie: April 2000
  • Laatst online: 17:07
Gomez12 schreef op donderdag 13 augustus 2015 @ 00:19:
[...]

Ik hoop niet dat guid v4 random zijn, dan heb je juist collisions...
Altijd mooi dat er nog mensen zijn met hopen hoop ...
maar helaas ... Wikipedia: Universally unique identifier
v4 nu net niet :)
Random (nouja, bij computers heb je daar nog wat additionele problemen mee maargoed) houdt juist geen rekening met voorgaande waardes.
Tien keer 1 achter elkaar is wel random mogelijk, maar wil je juist niet als GUID hebben.

Oftewel in een goede guid v4 implementatie zit juist een gedeelte voorspelbaar (bijv tijd / mac-adres etc) en een gedeelte random, zodat het voorspelbare gedeelte ervoor zorgt dat het geen probleem is dat je random generaties collisions zijn.
v4 staat of valt dus bij een goede random number generator .. en kan ondanks dat altijd nog vallen .. de kans is klein .. maar het kan.
Zie ook een eerdere link hier in dit topic waar uitgelegd wordt dat een GUID enkel een GUID is als je het als totaal bekijkt, ga je enkel een gedeelte pakken (maakt niet zoveel uit welk gedeelte of op welke manier) dan verliest het de waarde van een GUID omdat je kans op collisions explosief gaat stijgen.
[...]

Deze snap ik even niet, wat bedoel je hiermee? Als ik data zou mergen zou ik een check zetten op uniekheid van een GUID en als die getroffen wordt een nieuwe genereren, maar ik zie de toegevoegde waarde niet in van het per definitie opnieuw uitgeven van een GUID.

Eerlijk gezegd zie ik er alleen maar een mogelijk gevaar in dat als de generatiesnelheid hoog genoeg ligt dat ik alsnog een collision genereer die er eerst niet was.
Een normale GUID generatie wordt geholpen doordat er bijna altijd nog een proces achterhangt wat ook tijd kost waardoor de tijd variabele ook mee gaat veranderen.
Maar ga je echt een situatie creëren dat je bijv 1 miljard GUID's per seconde gaat genereren (omdat je echt niets anders doet dan dat, let op getallen zijn fictief) dan schakel je voor een groot gedeelte het tijd-gedeelte uit waardoor je in principe alleen nog maar rust op je random number generator en je sequence grootte.
Ergens zit er een grens aan en ik heb dan meer zoiets van : herberekenen waar vanwege een toevallige ionen-fluctuatie op pluto er een collision is, maar van de rest lekker afblijven, die is al uniek en ga ik niet unieker kunnen krijgen.

Het is net zoiets als een hash van een hash trekken, je kan het doen om de doorloopsnelheid te vertragen, maar in wezen ga je meer collisions krijgen omdat je eerste hash op een onbeperkte grootte van input werkt, en je 2e hash alleen nog maar op de max hash-grootte die uit de 1e gekomen is.
toon volledige bericht
Met v1 moet je zeker weten dat je mac goed gelezen wordt door je uuid implementatie en dat het keihard faalt als dat niet lukt) en uniek is, en je tijd braaf vooruit blijft tikken (ntp anyone).
v2 tsja uid en gid helpen ook niet echt, zijn vaak ook gelijk als je een systeem image'd
v3 en v5 geven je het voordeel en nadeel boven v1 dat je zelf in control bent over de namespace ipv van systeem variablen, echter wat is dan nog het voordeel boven een unieke namespace + sequence.
En v4 .. fingers crossed and hope for the best 8) .. en geen /dev/urandom-xkcd gebruiken :p

Maar tijd zit dus alleen in v1 en v2, waarbij er van v2 nog wat vanaf geknabbeld wordt.

En ik snap DE z'n punt denk ik wel, als je oude uuid's hebt rondslingeren waarvan je de afkomst niet weet, waarbij wellicht zelfs de implementaties in een taal nog niet helemaal waterdicht waren. (bijvb. het bepalen van het mac-address van de hardware is niet altijd even triviaal, op linux kun je in theorie een ifconfig doen en die parsen .. maarja als ik nou geen ifconfig heb .. of er is iets verandert in de formatting van de uitvoer etc, of zoals al eerder aangegeven virtualmachines). Of als je niet weet hoe er met ntp en tijd is omgesprongen. Dan is de kans op collisions dus wellicht nog steeds klein, maar wel een stuk groter. Opzich zou een unique constraint en inladen in 1 transactie met rollback ook afdoende moeten zijn afhankelijk van de mogelijkheden.

[ Voor 9% gewijzigd door gekkie op 13-08-2015 00:55 ]


  • Gomez12
  • Registratie: Maart 2001
  • Laatst online: 17-10-2023
gekkie schreef op donderdag 13 augustus 2015 @ 00:46:
[...]

Altijd mooi dat er nog mensen zijn met hopen hoop ...
maar helaas ... Wikipedia: Universally unique identifier
v4 nu net niet :)
Tja, wat zal ik zeggen... Ik vind v4 dan een totaal ander iets als een GUID / UUID.
v4 is gewoon een groot random nummer en niets meer dan dat.

Dan heb ik liever een groot genoeg random nummer waarbinnen wel mijn hele data-collectie valt maar wat geen 128 bits meer hoeft te kosten. Wellicht dat ik weg kan komen met 64-bits of wellicht dat ik 256 bits nodig heb, dat is imho redelijk irrelevant voor de rest. Maar v1 en v2 en v5 geven me in ieder een minder grote kans op collisions bij het mergen van meerdere datasets (van meerdere computers).

Ik heb het nooit geweten, maar ik denk dat ik vanaf nu eens ga nadenken of ik wel een guid nodig heb als er een guid v4 aanbevolen wordt, of dat een veel kleiner random nummer ook volstaat.
Als ik namelijk weet dat mijn database maar 100.000 entiteiten aankan, dan veroorzaakt een random nummer onder 1 miljard meer collisions bij aanmaken, maar het zorgt wel dat ik bijv andere keys kan zetten omdat ik meer headroom heb in mijn keyspace.

Het is imho een vrij dure conventie om enkel een random nr te hebben. Met wat domeinkennis kan je imho beter een andere (goedkopere/kleinere of duurdere/grotere) pakken.

Een random nummer van 0 tot 9 is namelijk net zo random als een guidv4, alleen de collision kans bij aanmaken is groter alleen de kosten voor een lookup zijn weer kleiner.

Iets wat alleen maar random is is imho per definitie niet uniek, het is alleen maar random niets meer dan dat.
gekkie schreef op donderdag 13 augustus 2015 @ 00:46:
[...]
En ik snap DE z'n punt denk ik wel, als je oude uuid's hebt rondslingeren waarvan je de afkomst niet weet, waarbij wellicht zelfs de implementaties in een taal nog niet helemaal waterdicht waren.
Maar met v4 heb je in principe per definitie (qua uniekheid) geen waterdicht systeem. Dat is zoals je zelf al zegt : Fingers crossed and hope to die...

In wezen lees ik in jouw post vooral : v1, v2, v3 en v5 zijn niet 100% waterdicht. v4 is per definitie niet waterdicht (daar is zelfs nog niet eens een poging voor gedaan).
Maar toch ben je bang voor "oude" systemen die geen waterdicht systeem gehad zouden hebben, terwijl het er nu nog steeds niet is.
Deal with the old shit as long as you don't have a better solution, don't create new shit which has the old problems just because it is new.

Maarja, het zal ook deels van je werkgebied afhangen denk ik dan, ik kom voornamelijk tegen dat er datasets gemerged moeten worden die per definitie van andere systemen / bedrijven / continenten etc afkomen.
Ik heb bijna niets te maken met dat datasets van geimagede machines afkomen die hetzelfde mac-adres of namespace of uid of gid kunnen hebben.
In de theorie zou ik het met een v1 of v2 of v5 nog wel eens aandurven om een dataset uit japan in te lezen zonder expliciet te checken op collisions (in de praktijk zit het nu in een systeem wat automatisch afvangt en afhandelt dus is voor mij de vraag niet zo relevant meer) maar met een v4 is dat dus per definitie altijd checken.

De kans op zichzelf vind ik namelijk niet zo interessant (zakelijk gezien) wat ik veel interessanter vind is wat de kosten zijn als het fout gaat en hoe snel dat in de realiteit opgemerkt gaat worden (zodat de maximale kosten in de hand blijven).
Als er in januari een collision optreed en die komt pas in december naar boven, dan heb ik dagen/weken speurwerk om dat naar boven te halen. Terwijl gewoon standaard een collisioncheck me gewoon x% capaciteit kost waarop ik hardware budgetten kan aanpassen en het allemaal voorspelbaarder is geworden qua kosten.

[ Voor 37% gewijzigd door Gomez12 op 13-08-2015 01:43 ]


  • gekkie
  • Registratie: April 2000
  • Laatst online: 17:07
Gomez12 schreef op donderdag 13 augustus 2015 @ 01:22:
[...]
Tja, wat zal ik zeggen... Ik vind v4 dan een totaal ander iets als een GUID / UUID.
v4 is gewoon een groot random nummer en niets meer dan dat.

Dan heb ik liever een groot genoeg random nummer waarbinnen wel mijn hele data-collectie valt maar wat geen 128 bits meer hoeft te kosten. Wellicht dat ik weg kan komen met 64-bits of wellicht dat ik 256 bits nodig heb, dat is imho redelijk irrelevant voor de rest. Maar v1 en v2 en v5 geven me in ieder een minder grote kans op collisions bij het mergen van meerdere datasets (van meerdere computers).
Als de mac's uniek zijn, deze goed uitgelezen worden door de implementatie, je tijd braaf vooruit tikt .. en het lot ook nog een beetje meewerkt. Ja, heb je gecheckt of dat zo is en zonodig ingegrepen :)

Maar goed ik vind ze ook maar beperkt nuttig .. want als je kunt garanderen dat die mac's uniek zijn en de tijd altijd vooruit loopt, dan had je vast ook wel een namespace af kunnen spreken ... en als je een namespace af kunt spreken .. waarom dan nog een uuid gebruiken .. en geen namespace + sequence ?
Voornaamste semi-nut wat ik dan nog overhoud is het objectid obfuscaten (in combinatie met een limiet + ban op het aantal tries)
Ik heb het nooit geweten, maar ik denk dat ik vanaf nu eens ga nadenken of ik wel een guid nodig heb als er een guid v4 aanbevolen wordt, of dat een veel kleiner random nummer ook volstaat.
Als ik namelijk weet dat mijn database maar 100.000 entiteiten aankan, dan veroorzaakt een random nummer onder 1 miljard meer collisions bij aanmaken, maar het zorgt wel dat ik bijv andere keys kan zetten omdat ik meer headroom heb in mijn keyspace.

Het is imho een vrij dure conventie om enkel een random nr te hebben. Met wat domeinkennis kan je imho beter een andere (goedkopere/kleinere of duurdere/grotere) pakken.

Een random nummer van 0 tot 9 is namelijk net zo random als een guidv4, alleen de collision kans bij aanmaken is groter alleen de kosten voor een lookup zijn weer kleiner.

Iets wat alleen maar random is is imho per definitie niet uniek, het is alleen maar random niets meer dan dat.
Klopt .. alleen door die 128 bits is de kans (met een goede random number generator) dat het ook uniek is, vrij groot.
Ik zou het wel checken (in de DB layer), omdat ik geen zin heb om hoe hypothetisch ook, de kans te lopen data te moeten gaan rechtbreien die half overschreven is, waarbij je het potentieel ook nog pas na enige tijd op merkt.

Good luck with that, allemaal nieuwe data die potentieel interacteert met die foute data, terug naar je backup ben je die nieuwe data kwijt .. zo laten een deel van de oude ... of je mag oneindige gaan puzzelen met logs en toestanden. Als je er al achter bent dat dat het probleem is.
Gomez12 schreef op donderdag 13 augustus 2015 @ 01:22:
[...]
Maar met v4 heb je in principe per definitie (qua uniekheid) geen waterdicht systeem. Dat is zoals je zelf al zegt : Fingers crossed and hope to die...

In wezen lees ik in jouw post vooral : v1, v2, v3 en v5 zijn niet 100% waterdicht. v4 is per definitie niet waterdicht (daar is zelfs nog niet eens een poging voor gedaan).
Maar toch ben je bang voor "oude" systemen die geen waterdicht systeem gehad zouden hebben, terwijl het er nu nog steeds niet is.
Deal with the old shit as long as you don't have a better solution, don't create new shit which has the old problems just because it is new.
Nouja waterdicht bestaat niet en opzich snap ik de varianten wel, bepaalde varianten geven je zelf deels controle, sommige zijn volledig random, maar allemaal hanteren ze hetzelfde format. Scheelt weer in parsers en implementaties schrijven met een berg potentiele fouten.
Maarja, het zal ook deels van je werkgebied afhangen denk ik dan, ik kom voornamelijk tegen dat er datasets gemerged moeten worden die per definitie van andere systemen / bedrijven / continenten etc afkomen.
Ik heb bijna niets te maken met dat datasets van geimagede machines afkomen die hetzelfde mac-adres of namespace of uid of gid kunnen hebben.
In de theorie zou ik het met een v1 of v2 of v5 nog wel eens aandurven om een dataset uit japan in te lezen zonder expliciet te checken op collisions (in de praktijk zit het nu in een systeem wat automatisch afvangt en afhandelt dus is voor mij de vraag niet zo relevant meer) maar met een v4 is dat dus per definitie altijd checken.
Met japan heb je wellicht wel een tijdzone issue dat het timestamp gedeelte doublures zou kunnen bevatten. Nou moet je dan ook nog toevallig een collision hebben in de mac en in het random gedeelte .. dus de kans is nog steeds niet heel groot ..
De kans op zichzelf vind ik namelijk niet zo interessant (zakelijk gezien) wat ik veel interessanter vind is wat de kosten zijn als het fout gaat en hoe snel dat in de realiteit opgemerkt gaat worden (zodat de maximale kosten in de hand blijven).
Als er in januari een collision optreed en die komt pas in december naar boven, dan heb ik dagen/weken speurwerk om dat naar boven te halen. Terwijl gewoon standaard een collisioncheck me gewoon x% capaciteit kost waarop ik hardware budgetten kan aanpassen en het allemaal voorspelbaarder is geworden qua kosten.
Juist vandaar dat ik dus ook maar wat gebencht had om te kijken of ik een beetje kon inschatten wat nou de gevolgen zijn van een unique constraint op een berg random getallen. Ik had gedacht dat dat wel duidelijk merkbaar zou worden als de dataset aardig zou groeien maar dat viel me dus mee/tegen tis maar hoe je het bekijkt.
Maar op dit punt zijn we het wel eens denk ik ja .. checken is dirt cheap vergeleken met de off chance van een collision.

[ Voor 34% gewijzigd door gekkie op 13-08-2015 01:56 ]


  • RobIII
  • Registratie: December 2001
  • Niet online

RobIII

Admin Devschuur®

^ Romeinse Ⅲ ja!

(overleden)
gekkie schreef op donderdag 13 augustus 2015 @ 00:46:
v4 staat of valt dus bij een goede random number generator .. en kan ondanks dat altijd nog vallen .. de kans is klein .. maar het kan.
Een goede (P/CS)RNG is wel heel fijn/handig hierbij, maar ik geloof niet dat je helemaal beseft hoe astronomisch je er langs zit als je "klein" zegt. Gooi 122* keer een muntje op en noteer een 0 voor kop, 1 voor munt. Doe datzelfde daarna net zo vaak tot je eenzelfde sequence van 122 nullen en enen gooit. Bij elke gooi heb je 50% kans op eenzelfde getal als de gewenste sequence. Effectief dus 50% op 50% op 50% op.... x 122.

* Effectief random bits, de overige 6 zijn versie indicators etc.

En ja, en "XKCD RNG die altijd 42 returned" en alle andere door stagiaires geschreven RNG's gaan daar geheid een keer de mist in. Other than that overschat je, zélfs met de eerder genoemde birthday paradox in acht genomen, de kansen royaal op een collision.
gekkie schreef op donderdag 13 augustus 2015 @ 00:46:
Met v1 moet je zeker weten dat je mac goed gelezen wordt door je uuid implementatie en dat het keihard faalt als dat niet lukt) en uniek is,
Waarin zou het keihard falen als je een macaddress niet goed zou kunnen "lezen" (daarover meer later); ook daar kun je standaard gedrag voor definiëren. Sterker nog, RFC 4122 welke V1 UUID's beschrijft doet dat gewoon.
gekkie schreef op donderdag 13 augustus 2015 @ 00:46:
en je tijd braaf vooruit blijft tikken (ntp anyone)
Again; welke oet*** baseert 't dan ook op de wall-clock time, NTP of systeemtijd? Er zijn gewoon onder élk zichzelf respecterend OS monotonically increasing clocks beschikbaar (lees: altijd alleen maar 'oplopende' ticks).
gekkie schreef op donderdag 13 augustus 2015 @ 00:46:
En v4 .. fingers crossed and hope for the best 8)
:D Dan wil ik jou wel eens zien als je meedoet aan de lotto :D Daar zijn je kansen astronomisch veel groter (bron).
gekkie schreef op donderdag 13 augustus 2015 @ 00:46:
bijvb. het bepalen van het mac-address van de hardware is niet altijd even triviaal, op linux kun je in theorie een ifconfig doen en die parsen .. maarja als ik nou geen ifconfig heb .. of er is iets verandert in de formatting van de uitvoer etc,
:D Again, wie schrijft zulke code? :X
Waarom zou je afhankelijk zijn van ifconfig en/of parsen van diens, al dan niet veranderende, output? Ifconfig is gewoon een tool die wat meuk uit 't OS opvraagt middels de API's die 't OS beschikbaar stelt daarvoor en die presenteert zoals 't de maker ervan 't goeddunkt voor de gebruiker. Userspace meuk dus. Als je een MAC address wil hebben om je UUID generator te voeren voer je zelf gewoon een system call uit (ioctl bijv.) en met de juiste parameters (siocgifhwaddr) krijg je gewoon netjes exact de 12 bytes van het/de MAC address(en) terug waarin je geïnteresseerd bent. Niks geen parsen, ifconfig of überhaupt afhankelijk zijn van 't al dan niet aanwezig zijn daarvan op je systeem.
gekkie schreef op donderdag 13 augustus 2015 @ 00:46:
Opzich zou een unique constraint en inladen in 1 transactie met rollback ook afdoende moeten zijn afhankelijk van de mogelijkheden.
Wat dus al -tig keer is aangegeven in dit topic: unique constraint, dup. key exception vangen als je er noodzaak in ziet en bovenal: het is gewoon afhankelijk van de situatie. En daar laat TS steeds veel te weinig over los (en dan nog; uiteindelijk ligt de beslissing over de uiteindelijke implementatie natuurlijk bij hem).
Gomez12 schreef op donderdag 13 augustus 2015 @ 01:22:
Dan heb ik liever een groot genoeg random nummer ... het mergen van meerdere datasets (van meerdere computers).
Precies: je kiest op basis van de situatie de juiste oplossing, er is geen silver bullet of "one size fits all" oplossing in deze.
Gomez12 schreef op donderdag 13 augustus 2015 @ 01:22:
Ik heb het nooit geweten, maar ... wat domeinkennis kan je imho beter een andere (goedkopere/kleinere of duurdere/grotere) pakken..
Je zou, zoals eerder ook al aangegeven, eens kunnen kijken naar (distributed of niet) key-generation systemen als (wijlen) Twitter's Snowflake achtige implementaties. 64 bits is veul :Y)
Gomez12 schreef op donderdag 13 augustus 2015 @ 01:22:
In wezen lees ik in jouw post vooral : v1, v2, v3 en v5 zijn niet 100% waterdicht. v4 is per definitie niet waterdicht (daar is zelfs nog niet eens een poging voor gedaan).
Geen enkel systeem garandeert ook 100% waterdicht maar biedt wel 99.999999999999999.... % kans op collision vrije identifiers ;)
Gomez12 schreef op donderdag 13 augustus 2015 @ 01:22:
De kans op zichzelf vind ik namelijk niet zo interessant (zakelijk gezien) wat ik veel interessanter vind is wat de kosten zijn als het fout gaat en hoe snel dat in de realiteit opgemerkt gaat worden (zodat de maximale kosten in de hand blijven).
Dat is inderdaad een mooi voorbeeld van een afweging die je maakt bij 't wel/niet afhandelen van dup. keys bijvoorbeeld. Kost een (sporadische) dup. key (of verloren record) je €0.0012 aan omzet of 15 mensenlevens ;) In het eerste geval is 't de extra ontwikkeltijd gewoon niet eens waard, in het tweede geval schrijf je een 180 pagina's tellende spec :)
gekkie schreef op donderdag 13 augustus 2015 @ 01:45:
Klopt .. alleen door die 128 bits is de kans (met een goede random number generator) dat het ook uniek is, vrij groot.
Again: alleen als je meermaals dezelfde dataset importeert of dat soort toestanden. Als je applicatie de enige is die de UUID's uitgeeft/gebruikt dan is het een ander verhaal als dat je (bijv.) rekening moet houden met PEBKAC's. Elke situatie/applicatie vereist een eigen oplossing voor een al dan (bijna) niet bestaand probleem. Geen. Silver. Bullet.
gekkie schreef op donderdag 13 augustus 2015 @ 01:45:
Ik zou het wel checken (in de DB layer), omdat ik geen zin heb om hoe hypothetisch ook, de kans te lopen data te moeten gaan rechtbreien die half overschreven is, waarbij je het potentieel ook nog pas na enige tijd op merkt.
Unique constraint. 15 seconden typen (en de exacte syntax googlen omdat je die altijd vergeet) en be done with it. Laten checken door je RDBMS vind ik dan een betere omschrijving dan "ik zou het wel checken" omdat dat impliceert dat je eerst een select en dan insert doet wat nét zo goed niet waterdicht is vanwege race conditions (ook al eerder besproken, ik blijf niet linken :P , transacties en overige 'creatieve workarounds' even daargelaten)
Ifconfig, parsen van mac-adressen, tijdzones, gare RNG's... Jij implementeert je (G/U)UID generators in Excel of Batch ofzo? Een beetje fatsoenlijke implementatie heeft daar allemaal écht geen last van hoor ;)
Of ben jij ook zo'n NIH/RTW type? ;)
gekkie schreef op donderdag 13 augustus 2015 @ 01:45:
Maar op dit punt zijn we het wel eens denk ik ja .. checken is dirt cheap vergeleken met de off chance van een collision.
Als derde in deze discussie tussen jou en Gomez12 wil ik dan toevoegen, zoals net al aangehaald: laten checken (unique constraint) dus altijd verkiezen boven select + insert. Als je dat bedoelt met die laatste zin dan ben ik 't ook met je/jullie eens ;)

[ Voor 34% gewijzigd door RobIII op 13-08-2015 02:19 ]

There are only two hard problems in distributed systems: 2. Exactly-once delivery 1. Guaranteed order of messages 2. Exactly-once delivery.

Je eigen tweaker.me redirect

Over mij


  • gekkie
  • Registratie: April 2000
  • Laatst online: 17:07
RobIII schreef op donderdag 13 augustus 2015 @ 01:52:
[...]

Een goede (P/CS)RNG is wel heel fijn/handig hierbij, maar ik geloof niet dat je helemaal beseft hoe astronomisch je er langs zit als je "klein" zegt. Gooi 122* keer een muntje op en noteer een 0 voor kop, 1 voor munt. Doe datzelfde daarna net zo vaak tot je eenzelfde sequence van 122 nullen en enen gooit. Bij elke gooi heb je 50% kans op eenzelfde getal als de gewenste sequence. Effectief dus 50% op 50% op 50% op.... x 122.

* Effectief random bits, de overige 6 zijn versie indicators etc.

En ja, en "XKCD RNG die altijd 42 returned" en alle andere door stagiaires geschreven RNG's gaan daar geheid een keer de mist in. Other than that overschat je, zélfs met de eerder genoemde birthday paradox in acht genomen, de kansen royaal op een collision.
Tsja klein of royaal .. beide van de kwaliteit waar je heen meetlat van kan knutselen :+
Maar als je graag aan astronomie doet mag er best astronomisch voor hoor.
Waarin zou het keihard falen als je een macaddress niet goed zou kunnen "lezen" (daarover meer later); ook daar kun je standaard gedrag voor definiëren. Sterker nog, RFC 4122 welke V1 UUID's beschrijft doet dat gewoon.
Again; welke oet*** baseert 't dan ook op de wall-clock time, NTP of systeemtijd? Er zijn gewoon onder élk zichzelf respecterend OS monotonically increasing clocks beschikbaar (lees: altijd alleen maar 'oplopende' ticks).
Ook daar schijnen in wat oudere (2.6 era nog) kernels bugs in gezeten te hebben. Dus misschien Linus maar even mail dat tie een oet*** is ? :+
:D Dan wil ik jou wel eens zien als je meedoet aan de lotto :D Daar zijn je kansen astronomisch veel groter (bron).
Prima dan win ik die .. doen we geen collision in onze uuid's bij de bank zodat het ook braaf op MIJN rekening komt :p
:D Again, wie schrijft zulke code? :X
Waarom zou je afhankelijk zijn van ifconfig en/of parsen van diens, al dan niet veranderende, output? Ifconfig is gewoon een tool die wat meuk uit 't OS opvraagt middels de API's die 't OS beschikbaar stelt daarvoor en die presenteert zoals 't de maker ervan 't goeddunkt voor de gebruiker. Userspace meuk dus. Als je een MAC address wil hebben om je UUID generator te voeren voer je zelf gewoon een system call uit (ioctl bijv.) en met de juiste parameters (siocgifhwaddr) krijg je, uiteindelijk, gewoon netjes exact de 12 bytes terug waarin je geïnteresseerd bent. Niks geen parsen, ifconfig of überhaupt afhankelijk zijn van 't al dan niet aanwezig zijn daarvan op je systeem.
https://bugs.python.org/issue1368955
Duidelijk dat iedereen en alles een oet*** is, maar in het verleden zijn dat soort houtjetouwtje constructies wel her en der geimplementeerd geweest. Vandaar de afdeling, als je niet weet wat die uuid's gegenereert heeft ...
Wat dus al -tig keer is aangegeven in dit topic: unique constraint, dup. key exception vangen als je er noodzaak in ziet en bovenal: het is gewoon afhankelijk van de situatie. En daar laat TS steeds veel te weinig over los (en dan nog; uiteindelijk ligt de beslissing over de uiteindelijke implementatie natuurlijk bij hem).
Tsja je zou het koffiedik kijken kunnen noemen :X
Nah ik was wel voor een dwingend referendum eigenlijk :+

PS: uiteraard gewoon de DB laten doen waar die goed in is .. dus een unique constraint (=check).

  • Gomez12
  • Registratie: Maart 2001
  • Laatst online: 17-10-2023
gekkie schreef op donderdag 13 augustus 2015 @ 01:45:
[...]
Als de mac's uniek zijn, deze goed uitgelezen worden door de implementatie, je tijd braaf vooruit tikt .. en het lot ook nog een beetje meewerkt. Ja, heb je gecheckt of dat zo is en zonodig ingegrepen :)
Dat zie ik als technische onvolkomenheden waarmee ik moet leven en die wellicht in de toekomst kunnen veranderen als de praktijk meer voldoet aan het ideaalbeeld, daar wil ik best op checken.
Echter compleet random is een totaal ander iets :)
Maar goed ik vind ze ook maar beperkt nuttig .. want als je kunt garanderen dat die mac's uniek zijn en de tijd altijd vooruit loopt, dan had je vast ook wel een namespace af kunnen spreken ... en als je een namespace af kunt spreken .. waarom dan nog een uuid gebruiken .. en geen namespace + sequence ?
Het probleem is dat je die garanties niet 100% kan geven vanwege huidige technische onvolkomenheden.
[...]
Ik zou het wel checken (in de DB layer), omdat ik geen zin heb om hoe hypothetisch ook, de kans te lopen data te moeten gaan rechtbreien die half overschreven is, waarbij je het potentieel ook nog pas na enige tijd op merkt.

Good luck with that, allemaal nieuwe data die potentieel interacteert met die foute data, terug naar je backup ben je die nieuwe data kwijt .. zo laten een deel van de oude ... of je mag oneindige gaan puzzelen met logs en toestanden. Als je er al achter bent dat dat het probleem is.
Juist vanwege dit soort scenario's zou ik het altijd checken en als ik een dubbele tegenkom (vanwege welke reden ook) dan zou ik dat afhandelen.
Echter vanwege andere scenario's : relaties binnen database op guid, of zelfs buiten een database op guid zou ik het expliciet niet standaard opnieuw genereren als het niet nodig is (het zou zeg maar niet de 1e keer zijn dat een klant zegt : Hier heb je mijn database 1 en 2 en een maand later zegt hij : Ik heb ook nog een database 3 gevonden die dezelfde keys gebruikt als 1 en 2).
Terwijl DouweEgbertje zoals ik het lees zegt : Geef het maar opnieuw uit ongeacht wat
RobIII schreef op donderdag 13 augustus 2015 @ 01:52:
[...]
Een goede (P/CS)RNG is wel heel fijn/handig hierbij, maar ik geloof niet dat je helemaal beseft hoe astronomisch je er langs zit als je "klein" zegt. Gooi 122* keer een muntje op en noteer een 0 voor kop, 1 voor munt. Doe datzelfde daarna net zo vaak tot je eenzelfde sequence van 122 nullen en enen gooit. Bij elke gooi heb je 50% kans op eenzelfde getal als de gewenste sequence. Effectief dus 50% op 50% op 50% op.... x 122.
De kansgrootte is wmb niet zo relevant bij dit soort dingen, het gaat zakelijk imho meer om de garanties.
En met huidige GUID implementaties is er geen 100% kans dat het goed gaat dus moet je het gaan checken (wat vanwege technische redenen ook geen 100% zekerheid oplevert maar per definitie wel de kans verkleint afhankelijk van de daadwerkelijke implementatie)

Waar jij lijkt te blijven hangen op : De kans is astronomisch klein, daar kan ik tegen klanten zeggen : De kans is astronomisch klein en mocht die optreden dan moeten er nog tig andere dingen fout gaan (waarop de kans bijna nog astronomisch kleiner is) en dan pas gaat het echt fout.
[...]
Waarin zou het keihard falen als je een macaddress niet goed zou kunnen "lezen" (daarover meer later); ook daar kun je standaard gedrag voor definiëren. Sterker nog, RFC 4122 welke V1 UUID's beschrijft doet dat gewoon.
Allemaal niet zo relevant of het guid nou goed opgebouwd is of niet imho, het doel van een guid is uniekheid garanderen, dat kan vanwege allerlei factoren niet 100% dichtgespijkerd zijn dus moet je checken en afhandelen.
En dan is het niet meer zo relevant of een macadress nou "niet goed uitgelezen" is, of dat het een crappy el-cheapo kaartje is van een fabrikant die gewoon duplicate macadressen uitdeelt (been there, done that) of dat er iets anders aan de hand is. Het macadress op zichzelf is niet het doel, het genereren van een uniek nummer is het doel, het macaddress is slechts een middel om dat doel te bereiken.

Dan kan je blijven doorzagen over de middelen en hoe je die beter kan krijgen / maken. Maar dat is redelijk irrelevant als : Je daar niet altijd controle/weet over hebt, het inherent toch niet relevant is omdat het unieke nummer toch onhaalbaar is en je toch moet checken (of kans op onbekende additionele kosten moet accepteren).

Het is net zoiets als zeggen : Ik moet over 5 minuten op de maan zijn. En dat iemand dan gaat discussiëren over of je een shuttle of Sojoez of iets anders moet gaan pakken. Dat is allemaal irrelevant, omdat ik nog niet eens binnen 5 minuten in zo'n ding kan zitten laat staan vertrekken, laat staan op de maan landen.

  • RobIII
  • Registratie: December 2001
  • Niet online

RobIII

Admin Devschuur®

^ Romeinse Ⅲ ja!

(overleden)
Gomez12 schreef op donderdag 13 augustus 2015 @ 02:17:
Waar jij lijkt te blijven hangen op : De kans is astronomisch klein, daar kan ik tegen klanten zeggen : De kans is astronomisch klein en mocht die optreden dan moeten er nog tig andere dingen fout gaan (waarop de kans bijna nog astronomisch kleiner is) en dan pas gaat het echt fout.
Even uitgaande van fatsoenlijke implementaties (bugs dus daargelaten): je houdt ook rekening met 't feit dat een bit door kosmische straling van 0 naar 1 kan flippen of andersom? Want, to be honest, die kans is nog steeds veel groter (meer) ;)
Gomez12 schreef op donderdag 13 augustus 2015 @ 02:17:
Allemaal niet zo relevant of het guid nou goed opgebouwd is of niet imho, het doel van een guid is uniekheid garanderen, dat kan vanwege allerlei factoren niet 100% dichtgespijkerd zijn
"100% for all intents and purposes" wel. Zie vorige alinea.
Maar goed; kansberekeningen e.d. aside:
Gomez12 schreef op donderdag 13 augustus 2015 @ 02:17:
dus moet je checken en afhandelen.
Daar zijn we het inmiddels allemaal wel over eens (even in 't midden gelaten wat men nou steeds bedoelt met "checken": a) inserten en dup. key exception vangen of b) select + insert of c) <anders>...). De vraag is of het de moeite / geld / tijd waard is om een collision af te handelen of de catch gewoon leeg te laten bijvoorbeeld. En dus is het, zoals ik blijf roepen, afhankelijk van de situatie. Mis ik bij een collision een Afbeeldingslocatie: http://static.tweakers.net/ext/f/TwFoGykhHM0fJFkK7Pp5jwRP/full.png in m'n FeestBoek database op de honderziljard overige likes (en dus zijn de stakes nihil)? Of gaan er mensen dood aan radioactieve fallout vanwege een collision die ik niet afhandel / vergeet af te handelen (en dus zijn de stakes hoog). De situatie en de kosten/baten afweging dicteren uiteindelijk, als het goed is, hoe je met een collision omgaat. Dat is mijn hele punt all along. En dan wijs ik even naar de topictitel en topicstart en zeg ik: fuck die check (UC!), het gaat om het hoe om te gaan met collisions. En daarmee ga je er impliciet dus al van uit dat collisions een mogelijkheid zijn (al blijf ik me verbazen over hoe groot men denkt dat die kans is (buggy implementaties, PEBKAC en andere zaken daargelaten, en dan verwijs ik wel nog even naar m'n eerdere NIH/RTW opmerking: ik zou er nog steeds altijd voor kiezen de (G/U)UID generator van het platform waarop ik ontwikkel te gebruiken totdat 'ie buggy blijkt of de stakes/budget moeten hoog genoeg zijn om een onderzoek ernaar te doen / een code review te warranten / ...whatever => situatie/project afhankelijk dus; net zoals er situaties zijn waar een simpele sequence of distributed (namespaced) generated ID van toepassing is).

TL;DR: Uit de topicstart:
Douweegbertje schreef op maandag 03 augustus 2015 @ 21:55:
[...]
zou iemand nu een check moeten doen* of een gegeven GUID al bestaat of niet
[...]
Daargelaten dat de betreffende applicatie niet van levensbelang is, of financieel enorm veel schade kan opleveren bijvoorbeeld.
* Definieer check (select/insert, UC, other); daarna gewoon kiezen hoe je wil omgaan met potentiële collisions; of die nou afkomstig zijn van PEBKAC, gare (G/U)UID generators of whatever.

[ Voor 31% gewijzigd door RobIII op 13-08-2015 03:25 ]

There are only two hard problems in distributed systems: 2. Exactly-once delivery 1. Guaranteed order of messages 2. Exactly-once delivery.

Je eigen tweaker.me redirect

Over mij


  • Wim-Bart
  • Registratie: Mei 2004
  • Laatst online: 10-01-2021

Wim-Bart

Zie signature voor een baan.

RobIII schreef op donderdag 13 augustus 2015 @ 02:27:
[...]

Even uitgaande van fatsoenlijke implementaties (bugs dus daargelaten): je houdt ook rekening met 't feit dat een bit door kosmische straling van 0 naar 1 kan flippen of andersom? Want, to be honest, die kans is nog steeds veel groter ;)


[...]

"100% for all intents and purposes" wel. Zie vorige alinea.
Maar goed; kansberekeningen e.d. aside:


[...]

Daar zijn we het inmiddels allemaal wel over eens (even in 't midden gelaten wat men nou steeds bedoelt met "checken": a) inserten en dup. key exception vangen of b) select + insert of c) <anders>...). De vraag is of het de moeite / geld / tijd waard is om een collision af te handelen of de catch gewoon leeg te laten bijvoorbeeld. En dus is het, zoals ik blijf roepen, afhankelijk van de situatie. Mis ik bij een collision een like in m'n FeestBoek database op de honderziljard overige likes (en dus zijn de stakes nihil)? Of gaan er mensen dood aan radioactieve fallout vanwege een collision die ik niet afhandel / vergeet af te handelen (en dus zijn de takes hoog). Dat is mijn hele punt all along.
toon volledige bericht
Ik ben er lang uit maar check en dan insert is volgens mij niet de juiste methode want in de tijd dat je checked kan een ander al een identieke insert uitvoeren (wat ik wel eens mee gemaakt heb in een brakke applicatie). Volgens mij is de enige juiste methode een exceptie afvangen wanneer er een duplicate key wordt toegevoegd aan de tabel.

Beheerders, Consultants, Servicedesk medewerkers. We zoeken het allemaal. Stuur mij een PM voor meer info of kijk hier De mooiste ICT'er van Nederland.


  • RobIII
  • Registratie: December 2001
  • Niet online

RobIII

Admin Devschuur®

^ Romeinse Ⅲ ja!

(overleden)
Wim-Bart schreef op donderdag 13 augustus 2015 @ 02:33:
[...]


Ik ben er lang uit maar check en dan insert is volgens mij niet de juiste methode
No shit sherlock ;) :P
Wim-Bart schreef op donderdag 13 augustus 2015 @ 02:33:
[...]Volgens mij is de enige juiste methode een exceptie afvangen wanneer er een duplicate key wordt toegevoegd aan de tabel.
Ook hier weer; er is geen silver bullet / "enige juiste methode". Er zijn andere manieren. Maar een UC + exception vangen is wel één van de simpelste en minst "prone to introducing more/new bugs" methode ja.

[ Voor 40% gewijzigd door RobIII op 13-08-2015 03:31 ]

There are only two hard problems in distributed systems: 2. Exactly-once delivery 1. Guaranteed order of messages 2. Exactly-once delivery.

Je eigen tweaker.me redirect

Over mij


  • Gomez12
  • Registratie: Maart 2001
  • Laatst online: 17-10-2023
gekkie schreef op donderdag 13 augustus 2015 @ 02:17:
[...]
https://bugs.python.org/issue1368955
Duidelijk dat iedereen en alles een oet*** is, maar in het verleden zijn dat soort houtjetouwtje constructies wel her en der geimplementeerd geweest. Vandaar de afdeling, als je niet weet wat die uuid's gegenereert heeft ...
Sorry hoor, maar die hele discussie vind ik een schitterend voorbeeld van een stelletje oetl*llen die terug moeten naar de zolderkamer.

Dat de 1e persoon een slecht idee bedenkt en dat niemand het direct ziet, allee. Kan gebeuren.

Maar op het moment dat er iemand gaat melden dat het op een duitse versie niet werkt omdat er geen engels woordje in staat dan moet je toch wel enigszins onraad gaan ruiken. Hoe zit het dan bijv met een russische windows, of een chinese windows, of weet ik veel wat voor lokalised windows / linux er zijn die niet 100% engels uitspugen.
Als je daarbovenop nog iemand krijgt die zegt dat er directory verschillen tussen winxp en w2k zitten dan moet je als serieuze programmeer zo ongeveer iets hebben van : WTF hoe heb ik dat kunnen doen...

Dan maar een environment variable gaan pakken die gewoon aan te passen is op user-nivo en helemaal niet gegarandeerd altijd aanwezig zal zijn (echt blind prutswerk).

En wat is dan de eindconclusie van die dag : C-implementatie is te veel werk en 4 maanden later is het onderdeel van de standaard.

Echt, hoe krijgen die mensen dit voor elkaar 8)7.
Ik vind het best als je het zo doet maar zet dan wel even in giga-grote rode letters een warning dat je product enkel maar geschikt is voor een engelstalige windows-versie die verplicht een environment variable moet waar de windows-directory is. Want anders kunnen er geen GUID's gemaakt worden.

Ach, het positieve eraan is dan wel weer dat ze niet een cmd-prompt openden, daar een screenshot van maakten en die gingen ocr'en om te achterhalen wat er stond, dat was nog net iets erger geweest. Dan had er namelijk in de warning bijgemoeten : U mag ook geen commandprompts standaard minimized openen of offscreen openen en u mag ook niet het klembord afvangen want dan kunnen er wellicht ook geen GUID's gecreëerd worden.
RobIII schreef op donderdag 13 augustus 2015 @ 02:27:
[...]
Even uitgaande van fatsoenlijke implementaties (bugs dus daargelaten): je houdt ook rekening met 't feit dat een bit door kosmische straling van 0 naar 1 kan flippen of andersom? Want, to be honest, die kans is nog steeds veel groter ;)
Je negeert het feit dat ik geen garantie kan geven dat iets gecreëerd is met een fatsoenlijke implementatie.
A : Bugs zijn niet enkel theoretisch
B : Implementatiefouten zijn al helemaal niet enkel theoretisch
C : Een kenmerk van een Guid (dacht ik tenminste totdat iemand me corrigeerde qua v4) is dat die pogen uniek te zijn. Oftewel als ik een guid aangeleverd krijg van derden of van iets totaal anders hoef ik me in theorie helemaal niet druk te maken om of de implementatie fatsoenlijk is geweest (zolang het resultaat maar goed is). Alleen in de praktijk is niet elke implementatie fatsoenlijk.
[...]
"100% for all intents and purposes" wel. Zie vorige alinea.
Mits je je beperkt tot eigen gecreëerde guid's op 1 bekende machine in een algemeen vastgebakend en bekend domein dan wel.
Mijn realtiteit is echter over het algemeen dat ik best een database aangeleverd kan krijgen die entry's van 5 jaar geleden bevat gemaakt op een debian machine die een week ongepatched was.
Of het kan schijnbaar ergens met python gegenereerd zijn (zie boven)
[...]
Daar zijn we het inmiddels allemaal wel over eens (even in 't midden gelaten wat men nou steeds bedoelt met "checken": a) inserten en dup. key exception vangen of b) select + insert of c) <anders>...)
In theorie geen b (want dan moet je opeens de database single-transaction based maken of ervoor zorgen dat je uitvoerende agent maar 1 statement te gelijk kan verwerken)
Maar in principe is het geen definitief a of c, het is afhankelijk van de situatie.

Als je buiten ACID-dbases gaat kijken dan is de kans al weer wat groter dat er helemaal geen dup key exception is (bijv nosqls willen er nog wel eens een handje van hebben met mooie termen als "async inladen" en "eventual consistency" etc)
De vraag is of het de moeite / geld / tijd waard is om af te handelen of de catch gewoon leeg te laten bijvoorbeeld. En dus is het, zoals ik blijf roepen, afhankelijk van de situatie. Mis ik bij een dup. key een like in m'n FeestBoek db op de honderziljard likes (en dus zijn de stakes nihil)? Of gaan er mensen dood aan radioactieve fallout vanwege een dup. key exception die ik niet afhandel / vergeet af te handelen (en dus zijn de takes hoog). Dat is mijn hele punt all along.
Deels waar, alleen is het ook maar net de vraag of je alles kan overzien. Als je FB benoemt, dan denk ik ook dat die niet voorzagen dat logdetails van out of policy items niet bewaren best kostbaar kan worden als het om wraakporno gaat...
Gaat de staatsloterij morgen een miljoen uitdelen aan de persoon die de honderziljardste like doet dan denk ik ook dat de kosten nog wel eens hoog zouden kunnen uitvallen (ik ken niet de exacte voorwaarden van FB en het boeit me ook niet echt voor het voorbeeld), dit soort type acties zijn er al. Enkel de prijzen zijn niet hoog zodat de kosten als het niet aankomt ook niet hoog zijn voor een FB (mochten ze het garanderen)
al blijf ik me verbazen over hoe groot men denkt dat die kans is (buggy implementaties, PEBKAC en andere zaken daargelaten, en dan verwijs ik wel nog even naar m'n eerdere NIH/RTW opmerking: ik zou er nog steeds altijd voor kiezen de (G/U)UID generator van het platform waarop ik ontwikkel te gebruiken totdat 'ie buggy blijkt of de stakes/budget moeten hoog genoeg zijn om een onderzoek ernaar te doen / een code review te warranten / ...whatever => situatie/project afhankelijk dus; net zoals er situaties zijn waar een simpele sequence of distributed (namespaced) generated ID van toepassing is).
Ach ja, omgekeerd blijf ik me dan weer verbazen dat mensen NiH ook toe blijken te passen op guid's.
Terwijl mijn beeld / ervaring juist met guid's is dat die van pas komen juist als ik over meerdere systemen / implementaties etc heen ga werken.

Als het enkel binnen mijn eigen controleerbare domein zou blijven zou ik een guid (zeker nu ik zie hoe v4 werkt, maar daarvoor vond ik het ook al te duur) niet snel gebruiken.

En zeker met de standaard kosten voor een check (in 99% van de gevallen totaal niet relevant) zou ik echt niet wachten met dat een implementatie buggy benoemd is, of de stakes hoog genoeg zijn om een onderzoek te starten.
Gewoon in het grote interne coding guidelines book dat het standaard gechecked en afgevangen moet worden inclusief implementaties etc en ik ben op 1000 projecten waarschijnlijk nog goedkoper uit dan als ik ook maar op 1 project onderzoek moet gaan doen of de implementatie buggy is.

Ik denk dat als ik moet gokken dat bij 60% van de excepties die ik afvang ik er niet vanuit ga dat het ooit op gaat treden als iedereen alles correct implementeert en handelt. Een SQL-server die in hetzelfde gebouw op dezelfde noodstroomvoorziening staat die valt niet zomaar spontaan even weg

  • RobIII
  • Registratie: December 2001
  • Niet online

RobIII

Admin Devschuur®

^ Romeinse Ⅲ ja!

(overleden)
Gomez12 schreef op donderdag 13 augustus 2015 @ 03:28:
Je negeert het feit dat ik geen garantie kan geven dat iets gecreëerd is met een fatsoenlijke implementatie.
8)7 Dat is mijn punt toch potdorie niet?
Maar goed: dan speel ik je spelletje mee:
Gomez12 schreef op donderdag 13 augustus 2015 @ 03:28:
A : Bugs zijn niet enkel theoretisch
B : Implementatiefouten zijn al helemaal niet enkel theoretisch
Ah, dus je bouwt ook je eigen CPU en gebruikt dus ook geen OS of frameworks/libraries? :X Het antwoord is, nogmaals, gewoon niet zwart/wit. Er is nuance. Waar leg je de grens. Als je een kernreactor bouwt heb je andere stakes dan wanneer je likes opslaat.

Kun je wel gaan draaien/"nuanceren" met wraakporno en de staatsloterij en andere ongepatchte machines met oude data en ACID en eventual consistency etc. etc. maar dat is nou juist wat ik nou steeds loop te zeggen: het. is. afhankelijk. van. de. situatie. en. de. stakes/kosten/baten.
...helemaal totaal en utterly niet relevant. Het gaat over die van de TS en zijn vraag die we proberen te beantwoorden: checken of niet. Antwoord: zie TL;DR.
Gomez12 schreef op donderdag 13 augustus 2015 @ 03:28:
In theorie geen b (want dan moet je opeens de database single-transaction based maken of ervoor zorgen dat je uitvoerende agent maar 1 statement te gelijk kan verwerken)
Maar in principe is het geen definitief a of c, het is afhankelijk van de situatie.
:F NEE, ECHT?!?!? :X

Maar goed, ik ben klaar met deze non-discussie ;) Truste! :w :>

There are only two hard problems in distributed systems: 2. Exactly-once delivery 1. Guaranteed order of messages 2. Exactly-once delivery.

Je eigen tweaker.me redirect

Over mij


  • Russel88
  • Registratie: Juli 2009
  • Laatst online: 23:59
Wat ik een voordeel van een Guid als pk zie ten opzichte van een identity integer. Kans op een foute join is stukken kleiner.
Soms zie je dat een ontwikkelaar een verkeerde stamtabel joined omdat de tabelnamen op elkaar lijken. Oke, ik zie wat in m'n output. Comitten maar.

  • Voutloos
  • Registratie: Januari 2002
  • Niet online
Nou, tegen dat soort stupiditeit gaat het echt niet helpen. Het is een technische oplossing voor een niet-technisch probleem (luiheid, laksheid, incompetentie). Dan wordt er gewoon in de volgende basic fout getrapt. En als je dit soort logica je keuzes laat beïnvloeden wordt het er ook niet intuïtiever op, dus creëer je ook een nieuwe categorie fouten..

{signature}


  • gekkie
  • Registratie: April 2000
  • Laatst online: 17:07
Gomez12 schreef op donderdag 13 augustus 2015 @ 03:28:
[...]

Sorry hoor, maar die hele discussie vind ik een schitterend voorbeeld van een stelletje oetl*llen die terug moeten naar de zolderkamer.
Misschien homo sapiens dan maar vervangen door de term oetl*llen ?
Laten we zeggen dat het niet de eerste en de enige keer is en ICT bovendien niet de enige plek waar het voor komt.
Mits je je beperkt tot eigen gecreëerde guid's op 1 bekende machine in een algemeen vastgebakend en bekend domein dan wel.
Mijn realtiteit is echter over het algemeen dat ik best een database aangeleverd kan krijgen die entry's van 5 jaar geleden bevat gemaakt op een debian machine die een week ongepatched was.
Of het kan schijnbaar ergens met python gegenereerd zijn (zie boven)
Python implementatie zal ondertussen ook wel aangepast zijn (niet gecheckt).
Voor de rest zijn het allemaal reducties in de mate van uniek zijn, opzich heb je altijd nog een berg bits die random zijn.
In theorie geen b (want dan moet je opeens de database single-transaction based maken of ervoor zorgen dat je uitvoerende agent maar 1 statement te gelijk kan verwerken)
Maar in principe is het geen definitief a of c, het is afhankelijk van de situatie.

Als je buiten ACID-dbases gaat kijken dan is de kans al weer wat groter dat er helemaal geen dup key exception is (bijv nosqls willen er nog wel eens een handje van hebben met mooie termen als "async inladen" en "eventual consistency" etc)
Mjah daarom ACID en er geen loopje mee willen nemen tenzij je data je minder lief is.

Wat mij eventueel eigenlijk lastiger lijkt is, stel je hebt een servers die allemaal braaf zelf uuid's genereren en je krijgt een collision en die vang je af, maar wat dan ...
A) Enige wat je kunt doen lijkt me is nieuwe uuid genereren voor dat object en fix ik de verwijzingen in relaties.
B) Of weigeren, maarja dan is je applicatie in feite als nog kapoet.

Enige met A) is dat als je het gebruikt om te synchroniseren en je ook weer terug wilt synchroniseren naar waar de collision vandaan kwam of met andere machines die het object met de collision nog niet hadden. Dan lijkt me dat lastig omdat het ene origineel van de collision daar nog bestaat en je toch vrij afhankelijk lijkt van het inderdaad uniek zijn.

Maar goed, iets om je druk over te maken als het zover is (waarschijnlijk nooit) en met een unique constraint is in iedergeval de data per instance nog valide.
Ik denk dat als ik moet gokken dat bij 60% van de excepties die ik afvang ik er niet vanuit ga dat het ooit op gaat treden als iedereen alles correct implementeert en handelt. Een SQL-server die in hetzelfde gebouw op dezelfde noodstroomvoorziening staat die valt niet zomaar spontaan even weg
Hmm al je switches en overige apparatuur ook ? of kan de applicatie (server) gebruik maken van rooksignalen ? (daarnaast iets te veel problemen met noodstroomgezien :X )

  • Blubber
  • Registratie: Mei 2000
  • Niet online
Douweegbertje schreef op maandag 03 augustus 2015 @ 22:08:

meh ja, discutabel. Je checkt het omdat het op zijn bek gaat, niet omdat je iets goed afvangt. Je krijgt meer iets van "er ging iets fout" in plaats van "duplicate, hier is een nieuwe GUID".
Pardon? Die uniekheid van dat veld is een constraint van je data model, die door je data laag (je database) afgedwongen wordt. Het stomweg inserten en de unique constraint zijn werk laten doen is de enige correcte manier om dit te doen.

Zoals al eerder gezegd is, als je dit in je eigen code gaat doen krijg je een race condition, en dan loop je dus tegen exact hetzelfde probleem aan. Je moet gewoon die unique constraint laten staan, en de error goed afvangen, daar kom je niet omheen.

Dat gezegd hebbende, als jij het voor elkaar krijg om twee keer dezelfde GUID te produceren, dan zou mijn eerste gedachte zijn dat er iets fout is. Of je gebruikt het verkeerde algoritme of het algoritme werkt niet zoals het hoort / je denkt.

Edit: dat is niet om te zeggen dat het volstrekt onmogelijk is, want dat is natuurlijk niet het geval. Maar zoals je zelf al aangeeft is de kans op een dupe extreem klein.

[ Voor 7% gewijzigd door Blubber op 13-08-2015 15:18 ]

Pagina: 1