Samengesteld unieke sleutel PHP

[Chadi]

Goede middag,

Ben al een tijd op zoek naar een manier om een unieke sleutel te genereren voor een userid.
Wat ik wil gebruiken (aangezien je BSN niet mag gebruiken of opslaan) om deze uit te rekenen is eigenlijk voornaam+achternaam+DOB+Geboorteplaats.

Laatste wil ik toevoegen om collisions te voorkomen .

Nu zal je wel denken joh laat dat incremental gebeuren maar ik wil dat als ik een user eenmaal registreer dat deze bij een volgende registratie een voorstel krijgt. Daarom is het van belang om deze te herkennen.

Misschien zijn er andere oplossingen. Ben redelijk nieuw op dit gebied.

[Mint]

UUID geen optie?

Edit: zie nu pas dat je bij een nieuwe registratie een voorstel wilt doen, een UUID voegt dan niet zoveel toe. Ik denk echter niet dat je zo'n voorstel moet willen. Wat voor voorstel wil je precies doen? Wat nu als ik jouw voornaam en achternaam weet, kan ik dan meer informatie van jouw account achterhalen door middel van dat voorstel?

Wat is precies de use case om dit te gaan doen?

[ Voor 74% gewijzigd door Mint op 03-10-2017 16:23 ]

[Stoelpoot]

Voornaam + Achternaam: Nope, vraag maar aan Jan Jansen.
+ DOB: Hoeveel kans heb je dat in een groep van 100 man 2 op dezelfde dag jarig zijn? Laatste keer dat ik keek ergens rond de 75%, dacht ik. Nope, zelfs niet bovenop Jan Jansen. Ja, het is echt hoog. Je hebt er echt niks aan qua unique-heid
+ Geboorteplaats: Wat is de dichtstbevolkte gemeente van Nederland ook alweer? Ik denk dat je in Amsterdam al meerdere Jannen Jansen gaat tegenkomen. Met een heel erg verbazende kans op een DB conflict.

Ik denk niet dat je een perfecte Unique key krijgt puur uit dit soort gegevens, tenzij je echt persoonlijke gegevens gaat gebruiken.

Waarom wil je een gebruiker bij de volgende registratie een voorstel doen? Is het niet de bedoeling dat iemand maar 1x hoeft te registeren en dan altijd hun gegevens paraat heeft?

EDIT: Verjaardagenparadox. Ja, dit is veel. Heel veel.

Het blijkt dat, onder enkele lichte veronderstellingen, deze kans al meer dan 50% is voor een groep van maar 23 mensen

Zijn er 23 mensen in Amsterdam die Jan Jansen zullen heten? Daar mag je best van uit gaan. Om op basis van persoonsgegevens een uniek ID te krijgen is echt bijna onmogelijk, dat wil je niet eens proberen.

[ Voor 22% gewijzigd door Stoelpoot op 03-10-2017 16:35 ]

[NMe]

Chadi schreef op dinsdag 3 oktober 2017 @ 16:16:
voornaam+achternaam+DOB+Geboorteplaats.

Is niet per definitie uniek. Zelfs als je haarkleur, schoenmaat en vreemde seksuele voorkeuren meeneemt ben je nog steeds niet gegarandeerd uniek.

Ik zou toch proberen om een manier te verzinnen waarop je met incrementele ID's kan werken, dat scheelt je een hoop kopzorgen.

[Verwijderd]

Waarom niet emailadres? Niet veel mensen zullen die delen met een ander, en de meesten gebruiken telkens hetzelfde emailadres.

Een absoluut zekere manier ga je namelijk toch nooit vinden (typevoudten!), dus waarom niet gewoon pragmatisch gedaan?

[TomsDiner]

Geboorteplaats moet uit een lijst geselecteerd worden? Want bij zelf tikken krijg je 's Gravenhage, Den Haag, A'dam, Amsterdam, Den Bosch, 's Hertogenbosch, en waarschijnlijk ook nog wel wat Friezen die hun lokale spelwijze aanhouden.

Dan zou ik voor postcode gaan, daarvan is de spelwijze uniform. Maar namen... Daar is ook genoeg aan onregelmatigheden te bedenken.. Mevrouw A.J.M. Jansen van den Burgt kan zich op heel veel manieren aanmelden.... (voorletters compleet of niet, tussenvoegsel voluit of afgekort, meisjesnaam eerst of niet...)

Postcode en huisnummer (+toev) zijn redelijk betrouwbaar, maar helaas wonen op een adres vaak mensen met een gedeeltelijk zelfde naam. Wel verschillende geboortedatums, behalve als het om tweelingen gaat.

Zoals hierboven al gemeld, gebruikt de hele wereld om die reden het email adres. Deze worden zelden gedeeld, en als je deze verplicht uniek maakt heeft hooguit een tweede gebruiker van een gedeeld emailadres een nieuw adres uit te zoeken. Maar iedereen is uniek, op alleen dit veld.

Let daarbij overigens wel op dat bij diverse maildiensten als Gmail het gebruik van punten in de naam mag, maar dat deze genegeerd worden. Als je dus twee aanmeldingen hebt van [e-mail] en [e-mail], is dat hetzelfde mailadres.

[downtime]

TomsDiner schreef op dinsdag 3 oktober 2017 @ 22:25:

Postcode en huisnummer (+toev) zijn redelijk betrouwbaar, maar helaas wonen op een adres vaak mensen met een gedeeltelijk zelfde naam. Wel verschillende geboortedatums, behalve als het om tweelingen gaat.

Been there, done that. Ooit een registratiepakketje in elkaar gezet voor een vereniging. Helaas: In dat dorp woonde een tweeling met dezelfde voorletter, achternaam, geboortedatum, geboorteplaats, en zelfs wonend op hetzelfde adres. Alleen de voornaam verschilde maar helaas registreerden we alleen voorletters en die waren wel hetzelfde. Dan ben je toch blij dat je gewoon een uniek ID in de database gebruikt hebt.

[momania]

Als je de user id gaat gebruiken op een website, in een url, etc, dan is er maar 1 advies: uuid of andere unieke hash. Zelfs geen sequence.
Als je nadenkt over security moet dat genoeg verklaren

[NMe]

momania schreef op dinsdag 3 oktober 2017 @ 23:04:
Als je de user id gaat gebruiken op een website, in een url, etc, dan is er maar 1 advies: uuid of andere unieke hash. Zelfs geen sequence.
Als je nadenkt over security moet dat genoeg verklaren

Hangt ervan af wat je allemaal opslaat en wat via die URLs publiekelijk zichtbaar wordt. Maar inderdaad, als privacy ook maar een heel klein issue is dan is een incrementeel ID al gauw geen goed idee.

[GertjanO]

Mijn tip: neem ook buitenlandse namen in beschouwing. Jan Janssen mag dan een veel voorkomende Nederlandse naam zijn, je wilt niet weten hoeveel personen "Mohamed" als naam hebben.

Als je dan ook meeneemt dat in die kringen veel vrienden/kennissen samenwonen, dan hou je weinig unieke kenmerken over.

Ik zou hoe dan ook met een unieke teller gaan werken.

Nog een vraagje: het BSN opslaan mag niet. Mogen geboortedatum en geboorteplaats dan wel? Dit zijn toch net zo goed persoonsgegevens?

[momania]

NMe schreef op dinsdag 3 oktober 2017 @ 23:12:
[...]

Hangt ervan af wat je allemaal opslaat en wat via die URLs publiekelijk zichtbaar wordt. Maar inderdaad, als privacy ook maar een heel klein issue is dan is een incrementeel ID al gauw geen goed idee.

Zelfs het feit dat je X users hebt (wat je zou kunnen afleiden aan het id als het incremental is) is soms al genoeg info. Zelfde geldt voor order id's, etc. Idd als je al die id's alleen beschikbaar maakt voor de ingelogde users is het risico klein, maar info is info tegenwoordig

[Gropah]

GertjanO schreef op dinsdag 3 oktober 2017 @ 23:14:
[...]
Nog een vraagje: het BSN opslaan mag niet. Mogen geboortedatum en geboorteplaats dan wel? Dit zijn toch net zo goed persoonsgegevens?

Het zijn zeker persoonsgegevens dus je moet er een goede reden voor hebben en ze redelijkerwijs goed genoeg beveiligen. En verwijderen als een persoon daar om vraagt. Echter is het voor het BSN expliciet verboden om gebruikt te worden, tenzij daar een uitzondering voor is gemaakt. Zie ook Autoriteit Persoonsgegevens

[TomsDiner]

GertjanO schreef op dinsdag 3 oktober 2017 @ 23:14:
Nog een vraagje: het BSN opslaan mag niet. Mogen geboortedatum en geboorteplaats dan wel? Dit zijn toch net zo goed persoonsgegevens?

Deze gegevens mogen wel, alleen als het doel de middelen heiligt. En dat zijn maar weinig doelen...

Keer het om: welke instanties geef jij vrijwillig je BSNR? Dat zijn de instanties die ermee horen te werken. En als het goed is, zit je dan ook op een iets hoger niveau van beveiliging.

Maar ik neem ergens aan dat gezien onze TS "echt persoonlijke" dingen aan een account wil koppelen, daar wel een reden voor is. Overigens lees ik in de startpost niet dat het gaat om een website, het kan dus ook de offline ledenadministratie zijn... Zo niet: dan denk ik dat drie tegenstrubbelende leden voldoende zijn om het systeem om zijn gat te krijgen.

[CH4OS]

Zoek je niet gewoon uniqueid()?

[Richh]

Chadi schreef op dinsdag 3 oktober 2017 @ 16:16:
Nu zal je wel denken joh laat dat incremental gebeuren

Precies!

maar ik wil dat als ik een user eenmaal registreer dat deze bij een volgende registratie een voorstel krijgt. Daarom is het van belang om deze te herkennen.

Je kan toch in je applicatie afvangen dat, voordat je een nieuwe registratie laat plaatsvinden, je eerst een search doet naar 'where forename = x and surname = y and dob = z'? Dat moet je sowieso al doen, ook met de door jou bedachte userId.

Afhankelijk van hoeveel gebruikers je verwacht denk ik opzich dat je sleutel vrij uniek zal zijn, maar volgens mij moet je het gewoon echt niet willen dit soort keys lekker incremental integers maken; dat is veel makkelijker en sneller. En logischer als je hier na een paar jaar op terug kijkt

[CH4OS]

Forename? Serieus? * CH4OS mompelt: firstname.

[momania]

CH4OS schreef op dinsdag 3 oktober 2017 @ 23:40:
Forename? Serieus? * CH4OS mompelt: firstname.

Forename is gewoon correct Engels hoor En het is nog altijd first name, geen firstname

[ Voor 9% gewijzigd door momania op 03-10-2017 23:42 ]

[Richh]

CH4OS schreef op dinsdag 3 oktober 2017 @ 23:40:
Forename? Serieus? * CH4OS mompelt: firstname.

Nooit over nagedacht eigenlijk, het komt rechtstreeks uit een database waar ik veel mee heb gewerkt maar niet zelf heb ontworpen...

Dus.. maar even googlen. In principe zijn forename en first name beide correct Engels volgens mij. Je zit wel met een spatie maargoed die heb je bij last name ook al. Daarnaast kan je in principe meerdere voornamen hebben, doopnamen etc. Forenames is dan in principe 'correcter' dan first names, immers, first is first.

Maargoed; keuzes en mierenneuken het ging om het idee

[Gomez12]

momania schreef op dinsdag 3 oktober 2017 @ 23:04:
Als je de user id gaat gebruiken op een website, in een url, etc, dan is er maar 1 advies: uuid of andere unieke hash. Zelfs geen sequence.
Als je nadenkt over security moet dat genoeg verklaren

Dus jouw advies is security by obscurity? En nadenken over security moet verklaren waarom dat een goed principe is?

momania schreef op dinsdag 3 oktober 2017 @ 23:17:
[...]
Zelfs het feit dat je X users hebt (wat je zou kunnen afleiden aan het id als het incremental is) is soms al genoeg info. Zelfde geldt voor order id's, etc. Idd als je al die id's alleen beschikbaar maakt voor de ingelogde users is het risico klein, maar info is info tegenwoordig

Dat geldt leuk als je onder de 1000 zit oid, maar begin dan gewoon bij 100.000 en niemand kan er meer iets van zeggen want waarschijnlijk zitten er sowieso gaten bij die aantallen.

[Chadi]

Dankjulliewel.

Ik ga denk ik toch voor de simpelste en dat is mail. Dat geeft me de beste garanties. Het is voor ene applicatie die nog niet aan het web hangt maar dat kan in de toekomst wel veranderen. Dus andere gegevens brengen andere verplichtingen met zich mee.

[momania]

Gomez12 schreef op woensdag 4 oktober 2017 @ 08:41:
[...]

Dus jouw advies is security by obscurity? En nadenken over security moet verklaren waarom dat een goed principe is?

Obscurity op zich is geen complete security uiteraard, maar bij goed toegepaste security principles hoor zeker wel obscurity (naast uiteraard andere principles).
Elk deel interne informatie is er 1 en is er 1 te veel als het om security gaat.

[DJMaze]

Richh schreef op dinsdag 3 oktober 2017 @ 23:51:
Dus.. maar even googlen. In principe zijn forename en first name beide correct Engels volgens mij. Je zit wel met een spatie maargoed die heb je bij last name ook al. Daarnaast kan je in principe meerdere voornamen hebben, doopnamen etc. Forenames is dan in principe 'correcter' dan first names, immers, first is first.

En daarom gebruik ik Wikipedia: Given name

[downtime]

Of als je politiek incorrect wilt zijn dan gebruik je Wikipedia: Christian name

[TRON]

Chadi schreef op woensdag 4 oktober 2017 @ 08:44:
Dankjulliewel.

Ik ga denk ik toch voor de simpelste en dat is mail. Dat geeft me de beste garanties. Het is voor ene applicatie die nog niet aan het web hangt maar dat kan in de toekomst wel veranderen. Dus andere gegevens brengen andere verplichtingen met zich mee.

Zou je meer willen/kunnen vertellen over wat je exact zou willen bereiken en waarom? Dan kunnen we daar voer meedenken i.p.v. advies geven op jouw oplossing voor een probleem wat voor ons niet bekend is.

[Stoelpoot]

Gomez12 schreef op woensdag 4 oktober 2017 @ 08:41:
[...]

Dus jouw advies is security by obscurity? En nadenken over security moet verklaren waarom dat een goed principe is?

Waarom obscurity? Het gebruik van een UUID e.d. is puur om enumeration attacks tegen te gaan. Het Id kan nog steeds zichtbaar zijn, maar je kan niet meer met een +1 naar een compleet onbekende gebruiker. En iedereen mag dan best weten dat je de UUID generator gebruikt van Gomez12 of Stoelpoot, want de UUID's kan je nog steeds niet raden (mits de generator goed is geschreven).

[...]

Dat geldt leuk als je onder de 1000 zit oid, maar begin dan gewoon bij 100.000 en niemand kan er meer iets van zeggen want waarschijnlijk zitten er sowieso gaten bij die aantallen.

Bij een incremental UserId zitten er als het goed is GEEN gaten in de aantallen. Als ik mezelf registreer als gebruiker 711413, is de gebruiker na mij toch echt degene met Id 711414.

[Verwijderd]

Stoelpoot schreef op woensdag 4 oktober 2017 @ 11:29:
Bij een incremental UserId zitten er als het goed is GEEN gaten in de aantallen. Als ik mezelf registreer als gebruiker 711413, is de gebruiker na mij toch echt degene met Id 711414.

Sure, maar 711412 kan verwijderd zijn.

[ Voor 78% gewijzigd door Verwijderd op 04-10-2017 11:36 ]

[Stoelpoot]

Verwijderd schreef op woensdag 4 oktober 2017 @ 11:35:
[...]

Sure, maar 711412 kan verwijderd zijn.

Een goede scraper leest daar gewoon overheen. Misschien kom je dan gaten tegen van 3 users. Bij een goed UUID zal je met een beetje veel geluk na 300 pogingen weer een geldig ID vinden. Om daarna weer 6000 pogingen te moeten doen voor de volgende.

[DJMaze]

Stoelpoot schreef op woensdag 4 oktober 2017 @ 11:39:
Bij een goed UUID zal je met een beetje veel geluk na 300 pogingen weer een geldig ID vinden. Om daarna weer 6000 pogingen te moeten doen voor de volgende.

De UUID in PHP is meestal tijd gebaseerd. Je kan dan beter libsodium gebruiken (PHP>7.2 of PECL)

[Harrie_]

DJMaze schreef op woensdag 4 oktober 2017 @ 12:46:
[...]

De UUID in PHP is meestal tijd gebaseerd. Je kan dan beter libsodium gebruiken (PHP>7.2 of PECL)

De data zit toch in een database, dan kun je toch gewoon UUID() in MySQL of NEWID() in MSSQL gebruiken? Ik weet of andere varianten/dialecten dergelijke functies ingebakken hebben maar voor MySQL / MSSQL lijkt me dit een prima oplossing?

[Stoelpoot]

DJMaze schreef op woensdag 4 oktober 2017 @ 12:46:
[...]

De UUID in PHP is meestal tijd gebaseerd. Je kan dan beter libsodium gebruiken (PHP>7.2 of PECL)

Ik zei dan ook een goed UUID. Het is altijd inderdaad nodig om uit te zoeken of een bepaalde impl. goed is.

[Hydra]

GertjanO schreef op dinsdag 3 oktober 2017 @ 23:14:
Mijn tip: neem ook buitenlandse namen in beschouwing. Jan Janssen mag dan een veel voorkomende Nederlandse naam zijn, je wilt niet weten hoeveel personen "Mohamed" als naam hebben.

Daarnaast; dat zijn fonetische overzettingen naar ons alfabet. Mohammed, Mehmet, Achmed, Achmet e.d. zijn allemaal ongeveer synoniem en het komt dus regelmatig voor dat dezelfde persoon in een systeem als Mohammed staat en in een ander systeem als Mohamed. Dan ben je dus ook al zuur.

Gebruik idd gewoon een mailadres.

Gomez12 schreef op woensdag 4 oktober 2017 @ 08:41:
Dus jouw advies is security by obscurity? En nadenken over security moet verklaren waarom dat een goed principe is?

Nee. Dit is een OWASP best practice om enumeration attacks tegen te gaan. Lees je ff in voordat je met dit soort termen gaat smijten.

[ Voor 22% gewijzigd door Hydra op 04-10-2017 13:30 ]

[Gomez12]

Stoelpoot schreef op woensdag 4 oktober 2017 @ 11:29:
[...]
Waarom obscurity? Het gebruik van een UUID e.d. is puur om enumeration attacks tegen te gaan.

Ik snap je vraag niet. Enumeration attacks ga je over het algemeen te lijf met obscurity. Oftewel ik snap niet wat je vraagt.

Hydra schreef op woensdag 4 oktober 2017 @ 13:27:
[...]
Nee. Dit is een OWASP best practice om enumeration attacks tegen te gaan. Lees je ff in voordat je met dit soort termen gaat smijten.

Grappig, dus een OWASP best practice zou geen security by obscurity kunnen zijn?
Want het is simpelweg security by obscurity, of OWASP het nou een best practice noemt of niet verandert niets aan het 1e feit.

[kwaakvaak_v2]

DJMaze schreef op woensdag 4 oktober 2017 @ 12:46:
[...]

De UUID in PHP is meestal tijd gebaseerd. Je kan dan beter libsodium gebruiken (PHP>7.2 of PECL)

Of in plaats van je eigen wiel uit te vinden, gebruik je gewoon bijna net als iedereen https://github.com/ramsey/uuid

Zit support in voor voor type 1,3,4 en 5 conform RFC 4122 in, en voor randombytes ook support voor bovengenoemde Libsodium.

Gomez12 schreef op woensdag 4 oktober 2017 @ 14:06:
[...]

Ik snap je vraag niet. Enumeration attacks ga je over het algemeen te lijf met obscurity. Oftewel ik snap niet wat je vraagt.


[...]

Grappig, dus een OWASP best practice zou geen security by obscurity kunnen zijn?
Want het is simpelweg security by obscurity, of OWASP het nou een best practice noemt of niet verandert niets aan het 1e feit.

Beter obscurity dan geen security

[ Voor 35% gewijzigd door kwaakvaak_v2 op 04-10-2017 14:09 ]

[Stoelpoot]

Gomez12 schreef op woensdag 4 oktober 2017 @ 14:06:
[...]

Ik snap je vraag niet. Enumeration attacks ga je over het algemeen te lijf met obscurity. Oftewel ik snap niet wat je vraagt.

Security by Obscurity is je implementatiedetails verbergen. Zoals ik al zei: Je kan best je UUID-generator publiek maken. Dat is geen probleem. Een goede UUID gen maakt namelijk geen voorspelbare ID's. En onvoorspelbare ID's is hoe je een enumeration attack tegengaat.

Zoals je het nu stelt, is password hashing ook security through obscurity. Terwijl dit juist niet zo is, een password wat goed gehasht is kan je in principe zonder blikken of blozen beschikbaar maken omdat je het goed genoeg in elkaar hebt gezet dat een gehasht wachtwoord geen waarde heeft (even daarbuiten gelaten dat je users nog steeds wachtwoorden als Welkom1 of jager2 zullen gebruiken). Het wordt al aangemoedigd om je hashing algorithm publiek te maken om aan te kunnen tonen dat je beveiliging goed is.

kwaakvaak_v2 schreef op woensdag 4 oktober 2017 @ 14:07:
[...]


Of in plaats van je eigen wiel uit te vinden, gebruik je gewoon bijna net als iedereen https://github.com/ramsey/uuid

Zit support in voor voor type 1,3,4 en 5 conform RFC 4122 in, en voor randombytes ook support voor bovengenoemde Libsodium.

Libsodium is ook gewoon een library. Dus je hoeft het wiel er niet opnieuw voor uit te vinden.

[ Voor 18% gewijzigd door Stoelpoot op 04-10-2017 14:16 ]

[Hydra]

Gomez12 schreef op woensdag 4 oktober 2017 @ 14:06:
Grappig, dus een OWASP best practice zou geen security by obscurity kunnen zijn?
Want het is simpelweg security by obscurity, of OWASP het nou een best practice noemt of niet verandert niets aan het 1e feit.

Je bent voor 't gemak maar even het stukje "enumeration attack" vergeten en hebt je ook overduidelijk niet ingelezen. Maarja; gelijk hebben is natuurlijk een stuk belangrijker dan bijleren he.

Stoelpoot schreef op woensdag 4 oktober 2017 @ 14:14:
Security by Obscurity is je implementatiedetails verbergen.

Doe geen moeite. Gewoon glimlachen en jaknikken. Hij komt er vanzelf wel een keer achter.

[ Voor 20% gewijzigd door Hydra op 04-10-2017 14:28 ]

[Harrie_]

Zonder dit topic verder te willen trekken in de discussie over 'security through obscurity' wil ik nog wel even dit kwijt:

quote: Wikipedia Engelstalig

In security engineering, security through obscurity (or security by obscurity) is the reliance on the secrecy of the design or implementation as the main method of providing security for a system or component of a system.

quote: Wikipedia Nederlandstalig

Security through obscurity is een beginsel uit de beveiliging. Men beoogt daarmee beveiligingsrisico's te beperken door (de werking van) beveiligingsmaatregelen geheim te houden. De achterliggende gedachte is, dat als het beveiligingsmechanisme niet bekend is, de beveiliging moeilijk door derden kan worden doorbroken.

Tussen die twee definities zit dus een wezenlijk verschil. De definitie van de engelstalige Wikipedia is natuurlijk altijd een slecht idee. Wanneer het echter gaat om bijv. enumeration attacks (zoals hierboven beschreven) dan is de obscurity gewoon een extra maatregel. Je handelt in je code af dat iemand niet zomaar ?id=x kan bekijken als diegene daar niet de rechten toe heeft. De obscurity met een UUID zorgt er vervolgens voor dat als er bijv. tóch een lek blijkt te zijn iemand niet zomaar id's kan gaan raden...

Een beetje hetzelfde principe als een kluis achter een schilderij verstoppen. De kluis moet uiteindelijk door het dikwandig staal etc. zorgen voor de veiligheid. Door de kluis te verstoppen voorkom je dat elke willekeurige voorbijganger op de kluis gaat lopen hameren...

[ Voor 9% gewijzigd door Harrie_ op 04-10-2017 14:36 ]

[kwaakvaak_v2]

Stoelpoot schreef op woensdag 4 oktober 2017 @ 14:14:
[...]


Libsodium is ook gewoon een library. Dus je hoeft het wiel er niet opnieuw voor uit te vinden.

Idd.. maar toch, niet iedereen mag/kan PECL extensies installeren en PHP 7.2 in productie klinkt pas als een goed plan als de final release er is. Voordeel van het gebruiken van een abstractie is dat je dan niet na hoeft te denken over het wel/niet hebben van bepaalde extensies.

[MSalters]

Stoelpoot schreef op dinsdag 3 oktober 2017 @ 16:24:
EDIT: Verjaardagenparadox.
Zijn er 23 mensen in Amsterdam die Jan Jansen zullen heten? Daar mag je best van uit gaan.

(Laat....)
Nee. DOB is Date of Birth, geen Birthday. Essentieel verschil: DOB is YYYY-MM-DD, Birthday is MM-DD. Een MM-DD collision is ruwweg 100 keer zo waarschijnlijk als een YYYY-MM-DD collision.

Een betere schatting moet alleen rekening houden met de YYYY-afhankelijke frequentie van voornamen. Jan was populairder in 1956 dan in 2006.

Ik zie een groter probleem met de exacte match. Is Raóul dezelfde persoon als Raoul? Hoe ga je Spaanse achternamen behandelen? Klassieker

[Chadi]

NMe schreef op dinsdag 3 oktober 2017 @ 16:25:
[...]

Is niet per definitie uniek. Zelfs als je haarkleur, schoenmaat en vreemde seksuele voorkeuren meeneemt ben je nog steeds niet gegarandeerd uniek.

Ik zou toch proberen om een manier te verzinnen waarop je met incrementele ID's kan werken, dat scheelt je een hoop kopzorgen.

Een unieke key in die zin dat ik mensen kan herkennen.
Een unieke incremental ID hebben ze sowieso .

Ben als leek met een opdracht bezig om voor ons zaalvoetbal teams te maken. Deze teams kunnen uit leden bestaan die ook in andere teams zitten. Teams schrijven in eerste instantie hun leden zelf in.Erg vaak komen er gasten mee doen die er zin in hebben. Deze moeten wel van te voren aangemeld worden. Heel vaak is de samenstelling van de teams anders en dat wil ik hiermee opvangen.

Je kan per weekend maar voor 1 team uitkomen.

Elk team mag onbeperkt leden toevoegen. Deze leden komen in eerste instantie onder dat team te zitten. Komt dat lid bij een ander team dan wordt hij daar ook lid van.

Al onze leden zijn vrijwilligers. Vaak zijn er klusjes die echt op het lijf zijn geschreven van een lid. Aan de hand van skills wil ik dat inzichtelijk maken.Als je een loodgieter onder je leden hebt , kan je die natuurlijk het best als eerste benaderen. Met dat idee en of die er wel zin in heeft.
Zo ook met scheidsrechters enz...


Het is eigenlijk spielerei maar als het lukt is het wel leuk om misschien te delen met anderen die hier ook tegen aan lopen. Verder lijkt het me leuk om nu echt door te pakken op het gebied van PHP.