Meningen: email als primary key

[mocean]

Voor een klanten database wil ik eens gaan kiezen voor 'functional keys', dus een key betekend wat en is niet zomaar een autonumber die +1 gaat bij iedere entry. Filosofie is dat tabellen makkelijker leesbaar zijn, er minder joins nodig zijn voor een rapportage (de key zegt al wat over de inhoud, ipv dat het een integer is) en dat soort dingen.

Om voor een klanten tabel te gebruiken dacht ik gelijk aan het email adres. Deze is uniek voor een persoon (in principe) en meerdere registraties op 1 e-mail adres worden sowieso niet toegestaan.

Zijn er voor/nadelen voor het gebruik van 'email' als primary key? Hoe langer ik er over nadenk, hoe meer voordelen ik zie. Iemand ervaringen met het gebruik van dergelijke 'functional keys'

(Ja ik zie ook wel 1 nadeel: als het email adres wijzigt, maar die update query's lijken me te overzien)

[RobIII]

mocean schreef op donderdag 28 juli 2011 @ 23:54:
(Ja ik zie ook wel 1 nadeel: als het email adres wijzigt, maar die update query's lijken me te overzien)

Je zegt 't zelf al. Plus dat je voor een (foreign)key wel heel veel bytes kwijt bent itt een "int" (of whatever) synthetic key.

Gebruikers zijn doorgaans aan nogal wat tabellen gekoppeld. Als een email adres wijzigt kom je waarschijnlijk een shitload aan records in een x-aantal tabellen aan 't wijzigen. En dan hebben we 't nog niet over dat dat helemaal niet (makkelijk) kan als je echte relaties gebruikt*; bij het aanpassen van de ene tabel/record breek je meteen de FK constraint(s) en dus gaat je DB dat niet goed vinden Als je iemand bent die de constraints op de FK's in de BL doet dan is 't andere koek maar dan hou ik me verder niet meer bezig met dit topic want dan is 't een verloren zaak

En bij elke tabel die je toevoegt die een FK naar een user heeft moet je er aan denken dat je "emailwijzigprocedure" die tabel de volgende keer ook meeneemt.

Nee, ik zou mooi voor synthetic keys gaan Dat is in veruit de meeste gevallen gewoon de veiligste keus; uitzonderingen daargelaten. Een email-adres is er daar geen van

* ja je kunt tijdelijk constraints opheffen en die naderhand weer terugzetten en weet-ik-wat voor constructies verzinnen maar die zijn stuk voor stuk ranzig en levensleip als ze halverwege falen.

[ Voor 70% gewijzigd door RobIII op 29-07-2011 00:05 ]

[MueR]

Ik zie het voordeel eigenlijk niet eens. De tabellen zijn beter leesbaar? Daar heb je views voor. Dat het wat meer zoekwerk is wanneer je direct in een phpmyadmin of sql management studio zit te kijken is jammer, maar die dingen zijn ook eigenlijk niet bedoeld als "cms". Daarbij lijkt het me ook nog eens inefficiënt qua performance. Een string comparison zal vrijwel altijd trager zijn.

[RobIII]

MueR schreef op vrijdag 29 juli 2011 @ 00:00:
Een string comparison zal vrijwel altijd trager zijn.

Dat is maar 't topje van de ijsberg: je data is (zoals ik zei) groter dan een int dus er passen minder gegevens in een page in een index waardoor je meer I/O hebt, meer memory belasting en ga zo maar door. Die string-compare is dan wel je minste zorg

Wat je wél misschien kunt doen is "gewoon" een synthetic key gebruiken en een unique constraint/index op emailadres zetten en het emailadres gebruien in, zeg, een url ofzo:

http://mijndomein.nl/users/[e-mail]
i.t.t.
http://mijndomein.nl/users/43400

Daarmee haal je de betreffende user dan uit de users tabel en vervolgens ga je lekker joinen op de synthetic (primary) keys. De eindgebruiker hoeft natuurlijk die synthetic key(s) nooit daadwerkelijk te zien als het je daar om zou gaan. (Neemt niet weg dat ook deze optie, in dit geval althans, niet heel erg handig is: als de user z'n emailadres wijzigt klopt de url niet meer en kunnen mensen met bookmarks oid de user niet meer vinden etc. etc. En dat is nog los van de privacyvraagstukken )

[ Voor 51% gewijzigd door RobIII op 29-07-2011 00:11 ]

[mocean]

Oh ik wilde het performance issue er eigenlijk buiten laten (CPU/Memory is goedkoop). Maar ik vroeg om ervaringen :-).

[RobIII]

mocean schreef op vrijdag 29 juli 2011 @ 00:10:
Oh ik wilde het performance issue er eigenlijk buiten laten (CPU/Memory is goedkoop)

Ja, maar om 't zo te verkwanselen als 't niet nodig is...
Maar goed, dat is idd je minste zorg. De overige issues die ik aankaartte zouden je al moeten overhalen 't niet te doen

mocean schreef op vrijdag 29 juli 2011 @ 00:10:
Maar ik vroeg om ervaringen :-).

Die heb je nu toch? Denk je dat ik dat uit een boekje heb allemaal? Ik heb, jaren geleden weliswaar, ook die fout gemaakt en m'n kop gestoten hoor

[ Voor 10% gewijzigd door RobIII op 29-07-2011 00:13 ]

[HarmoniousVibe]

Je moet nooit semantiek gebruiken in de PK. Zelf iets als een onveranderbare username is af te raden. Natuurlijk kan het ook anders, maar dit is gewoon best practice.

Ik zie verder ook geen enkel voordeel in van het gebruiken van een emailadres als PK.

[Verwijderd]

mocean schreef op vrijdag 29 juli 2011 @ 00:10:
CPU/Memory is goedkoop.

Dit in combinatie met het idee om primary keys te gaan wijzigen is voor mij genoeg reden om iemand naar huis te sturen. Tabellen makkelijker leesbaar? Is dat belangrijk dan? In dat geval deugt je applicatie niet. Waarom zou je immers ooit rauwe data moeten zien? Voor de performance hoef je het niet te laten, zo'n join is flitsend snel.

En als een kolom kan wijzigen dan mag hij geen deel uitmaken van een primary key. Zo simpel is dat in mijn boekje.

Ik ben overigens ex-webdeveloper en nu vooral sysadmin bij een hosting provider en ben van mening dat developers die denken dat ze niet hoeven te optimaliseren een andere hobby moeten zoeken. Je wilt niet weten hoe vaak ik aan onze klanten moet vertellen dat hun developers hun werk niet goed doen en dat wij er echt niets aan kunnen doen dat hun applicatie zo traag is. Maar als developers zo'n houding hebben als jij, dan doe ik dat toch écht.

[RobIII]

HarmoniousVibe schreef op vrijdag 29 juli 2011 @ 00:25:
Je moet nooit semantiek gebruiken in de PK.

Zeg nooit nooit
Ik kan me best wat voorstellen bij een BSN, ISBN of andere (relatief!) vaststaande data. Ook daar kan ik me voorstellen dat 't ooit problemen levert maar lang niet zo snel als bij een emailadres.
Ook een ordernummer dat je zelf genereert oid zou je, in theorie, prima als PK kunnen gebruiken. Granted, ik zou 't ook niet (snel) doen, maar toch. All I'm saying is zeg nooit nooit

[HarmoniousVibe]

Nu ja, in die geval kan wel wel, maar waarom zou je het doen? De argumenten die TS aanvoert snijden in mijn ogen weinig hout.

[MsG]

Bij een gebruikerstabel zoals hier bij Tweakers, waarbij iedereen een userID heeft, zouden jullie daarboven dan nog een abstracte PK doen met auto-increment, of zouden jullie dan wel gewoon de UserID zelf gebruiken.

[RobIII]

MsG schreef op vrijdag 29 juli 2011 @ 00:39:
Bij een gebruikerstabel zoals hier bij Tweakers, waarbij iedereen een userID heeft, zouden jullie daarboven dan nog een abstracte PK doen met auto-increment, of zouden jullie dan wel gewoon de UserID zelf gebruiken.

Hier op T.net is je gebruikers-id gewoon de PK (AFAIK althans). En waarom niet? En wat zou (nog) een extra synthetic key hier als voordeel bij bieden?

[mocean]

Het hele idee van functional keys is dat ze wat betekenen, dus in plaats van een product tabel met:
id, name, description

Doe je
productcode, name, description

Waarbij de productcode al duidelijk is. Ook in koppeltabellen.

[RobIII]

mocean schreef op vrijdag 29 juli 2011 @ 00:46:
Het hele idee van functional keys is dat ze wat betekenen, dus in plaats van een product tabel met:
id, name, description

Doe je
productcode, name, description

Waarbij de productcode al duidelijk is. Ook in koppeltabellen.

Dat was ons al duidelijk, maar is jou nu ook duidelijk wat de nadelen zijn van functional keys?
_{(Overigens, wat jij functional key noemt (en waarvan ik begrijp wat je er mee bedoelt) heb ik altijd geleerd als "Natural key" en wikipedia vindt dat ook )}

[ Voor 20% gewijzigd door RobIII op 29-07-2011 00:55 ]

[Verwijderd]

mocean schreef op vrijdag 29 juli 2011 @ 00:46:

Waarbij de productcode al duidelijk is. Ook in koppeltabellen.

Waarom moet dat in een tabel al duidelijk zijn? Wie gaat dat nodig hebben?
De eindgebruiker in elk geval niet. Presentatie moet je absoluut gescheiden houden van de onderliggende datastructuur.

Stel een fabrikant verandert een productcode. Dat kan echt. Ga je dan alle referring foreign key kolommen af om de wijziging door te voeren?

Er is een kans dat zoiets halverwege misgaat, bijvoorbeeld door een hardwarestoring of overbelasting van de server (doordat de developers niet genoeg hebben geoptimaliseerd bijvoorbeeld). Als je dat met een DBMS doet met ondersteuning voor referentiële integriteit, zul je de update dus in een transactie moeten doen. De indexes moeten behoorlijk worden geüpdatet. Het duurt waarschijnlijk langer dan even dus moet er flink worden gelockt waardoor andere processen moeten wachten.

Is dat nu echt zoveel beter dan gebruik maken van een surrogate key?

[Wolfboy]

RobIII schreef op donderdag 28 juli 2011 @ 23:56:
[...]

Je zegt 't zelf al. Plus dat je voor een (foreign)key wel heel veel bytes kwijt bent itt een "int" (of whatever) synthetic key.

Elke fatsoenlijke database heeft wel een "ON UPDATE CASCADE" optie waarmee dat eerste punt wegvalt.

Het 2e punt daarentegen vind ik wat relevanter, het maakt je indices veel groter op die manier.

[RobIII]

Wolfboy schreef op vrijdag 29 juli 2011 @ 02:24:
[...]
Elke fatsoenlijke database heeft wel een "ON UPDATE CASCADE" optie waarmee dat eerste punt wegvalt.

Waar ik dan weer tegenin wil brengen dat ik niet zo kapot ben van cascading. Bij updates, allee, daar wil ik nog wel eens iets van door de vingers zien. Bij deletes blijf ik er verre van. Dit domweg om 't simpele feit dat als de applicatie (en dus DB) wat complexer wordt en groeit je op een gegeven moment nog maar verdomd moeilijk ziet hoe ver een 'cascading actie' eigenlijk reikt. Je wijzigt heel simpel een emailadres maar staat er niet meer bij stil dat je RDBMS stiekem nog even anderhalf miljoen gerelateerde records verdeeld over X tabellen moet gaan lopen rechttrekken om die actie te ondersteunen en dat bij elk van die tabellen dan ook weer constraints gecontroleerd moeten worden en weet-ik-veel waardoor zo'n actie stiekem (veel) meer impact heeft dan je "op 't eerste oog" beseft.
Laat staan deletes: je mikt een record weg en vervolgens verdwijnen er om "mysterieuze reden" overal door je hele DB records want die hadden "ooit" iets te maken met het net weggemikte record. Dan ben ik liever wat explicieter in mijn code en loop ik liever tegen een fout van het RDBMS aan bij 't verwijderen wanneer ik ergens een relatie over het hoofd heb gezien dan dat het RDBMS dat dan maar even 'voor mij' wegmikkert.

Maar goed; je hebt een terecht punt. Ikzelf ben niet zo kapot van cascades zoals ik zei en uitleg hierboven, maar het kan dus inderdaad wel.

[ACM]

mocean schreef op vrijdag 29 juli 2011 @ 00:46:
Het hele idee van functional keys is dat ze wat betekenen, dus in plaats van een product tabel met:
id, name, description

Doe je
productcode, name, description

Waarbij de productcode al duidelijk is. Ook in koppeltabellen.

In mijn ervaring hebben producten soms vanuit de fabrikant meerdere codes of zelfs geen codes. Of althans, dat wordt dan niet duidelijk gecommuniceerd of is nog niet bekend gemaakt omdat het product nog niet officieel verkocht wordt. En het is trouwens ook nog mogelijk dat meerdere fabrikanten dezelfde code hanteren, daar werkt een EAN dan wel voor, maar die wordt weer niet door alle fabrikanten in de wereld gevoerd...
Kortom, de kans is groot dat productcode een 1:n-relatie heeft met producten (waarbij n >=0), niet een 1:1.

En misschien denk je nu dat dat niet zo is, maar als je zoiets wilt wijzigen zit je met een probleem. Als je een surrogate key gebruikt, kan je domweg de productcode-kolom vervangen door een productcode-tabel die weer verwijst naar het id van je producten en ben je klaar.

Voor wat betreft e-mailadressen, mijn ervaring met 10 jaar tweakers.net, leert dat er dagelijks mensen zijn die hun e-mailadressen zijn vergeten en een nieuwe willen laten instellen. Dat zijn alleen dus al tientallen per jaar die het niet zelf via hun profiel aanpassen...
Zelfs als je een natural key wilt instellen zou ik alsnog niet gauw een zo veranderlijke key kiezen. In het geval van mensen is denk ik enkel de BSN voldoende vast om hem eventueel als PK te kiezen. Maar in werkelijkheid zou ik ook de BSN niet nemen, want dat heeft weer allerlei privacy implicaties en je blijft met je performance-issues zitten van onnodig grote kolommen

Ohja, en zodra je het over miljoenen records hebt... dan zijn cpu, memory en zeker I/O ineens niet meer goedkoop. Je kan er dan wel veel voor weinig geld van kopen, maar het blijft dan alsnog (vziw soms zelfs ordes van groottes) trager dan een goed gekozen numerieke key, juist omdat het de PK is en al je joins ermee gedaan worden.

[ Voor 4% gewijzigd door ACM op 29-07-2011 08:26 ]

[Wolfboy]

RobIII schreef op vrijdag 29 juli 2011 @ 02:55:
[...]

Waar ik dan weer tegenin wil brengen dat ik niet zo kapot ben van cascading. Bij updates, allee, daar wil ik nog wel eens iets van door de vingers zien. Bij deletes blijf ik er verre van. Dit domweg om 't simpele feit dat als de applicatie (en dus DB) wat complexer wordt en groeit je op een gegeven moment nog maar verdomd moeilijk ziet hoe ver een 'cascading actie' eigenlijk reikt. Je wijzigt heel simpel een emailadres maar staat er niet meer bij stil dat je RDBMS stiekem nog even anderhalf miljoen gerelateerde records verdeeld over X tabellen moet gaan lopen rechttrekken om die actie te ondersteunen en dat bij elk van die tabellen dan ook weer constraints gecontroleerd moeten worden en weet-ik-veel waardoor zo'n actie stiekem (veel) meer impact heeft dan je "op 't eerste oog" beseft.
Laat staan deletes: je mikt een record weg en vervolgens verdwijnen er om "mysterieuze reden" overal door je hele DB records want die hadden "ooit" iets te maken met het net weggemikte record. Dan ben ik liever wat explicieter in mijn code en loop ik liever tegen een fout van het RDBMS aan bij 't verwijderen wanneer ik ergens een relatie over het hoofd heb gezien dan dat het RDBMS dat dan maar even 'voor mij' wegmikkert.

Maar goed; je hebt een terecht punt. Ikzelf ben niet zo kapot van cascades zoals ik zei en uitleg hierboven, maar het kan dus inderdaad wel.

Dat ben ik volledig met je eens overigens.

In mijn databases staan de on update/delete dan standaard ook op restrict ingesteld, liever en dikke foutmelding dan dat je per ongeluk ladingen data kwijt bent. Of dat je de hele server platlegt doordat die ene primary key toch wel erg veel foreign key referenties had...

[Remus]

RobIII schreef op donderdag 28 juli 2011 @ 23:56:
[...]
En bij elke tabel die je toevoegt die een FK naar een user heeft moet je er aan denken dat je "emailwijzigprocedure" die tabel de volgende keer ook meeneemt.

Waarom een aparte wijzigingsprocedure 'ON UPDATE CASCADE' doet dat automagisch voor je? Of ondersteunt MySQL dat weer niet?

Neemt niet weg dat gebruik van veranderlijke, domeinspecifieke primary keys over het algemeen niet verstandig is.

[RobIII]

Remus schreef op vrijdag 29 juli 2011 @ 12:24:
[...]


Waarom een aparte wijzigingsprocedure 'ON UPDATE CASCADE' doet dat automagisch voor je? Of ondersteunt MySQL dat weer niet?

Lees effe het héle topic
RobIII in "Meningen: email als primary key"

[MSalters]

Ik kan uit persoonlijke ervaring vertellen dat email als primary key een ramp is. De kosten van een degelijke ontwerpfout kunnen oplopen tot miljoenen euro's per jaar. Mensen hebben de (terechte) verwachting dat ze hun emailadres kunnen wijzigen.

[glrfndl]

Daarnaast zijn er genoeg mensen die hun email adres delen met hun partner. Hoe vaak zie je wel niet een emailadres als [e-mail]
Email adres als primary key is gewoon geen goed idee

[Cyphax]

MSalters schreef op vrijdag 29 juli 2011 @ 12:33:
Ik kan uit persoonlijke ervaring vertellen dat email als primary key een ramp is. De kosten van een degelijke ontwerpfout kunnen oplopen tot miljoenen euro's per jaar. Mensen hebben de (terechte) verwachting dat ze hun emailadres kunnen wijzigen.

Waarom zou dat niet meer kunnen als e-mailadres de primary key is?
Het is misschien niet aan te raden maar het is op zich te implementeren.

Ik zou uiteindelijk kiezen voor een (zeker) unieke waarde die ook niet meer kan wijzigen. Zo'n betekenisloze sleutel is in die situatie waarschijnlijk wel het handigst, of je moet iets als SOFI/BSN hebben.

[ Voor 25% gewijzigd door Cyphax op 29-07-2011 14:27 ]

[RobIII]

Cyphax schreef op vrijdag 29 juli 2011 @ 14:24:
[...]

Waarom zou dat niet meer kunnen als e-mailadres de primary key is?

Zoals al vaker is gezegd in dit topic: het kan wel, maar vrolijk word je er niet van

[Cyphax]

Ik zat alweer een beetje in de naturuurlijk vs surrogaatsleutel-mindset, daar loopt zo'n vraag altijd op uit, maar we kunnen e-mailadres ook wel afraden om andere redenen, hoofdzakelijk omdat het te makkelijk kan veranderen om te zien als ideale identifier van een persoon. De kans is ook meestal niet zo groot dat er een ander veld een goede kandidaat is om iemand te identificeren. Mensen zijn gewoon te veranderlijk.

[glrfndl]

In principe hoef je natuurlijk niet te referencen naar je primary key, je zou nog een unique int column er bij kunnen maken Dan heb je ook geen last meer van die cascaded updates/deletes

[Cyphax]

Ik heb eigenlijk bijna alleen maar lol gehad van cascaded updates en deletes (hoofdzakelijk deletes). Scheelt nogal veel code schrijven. Enige nadeel is dat je wel moet weten wat je aan het doen bent als je je database aan het modelleren bent.
Het is ook wel wat werk om na te gaan hoe de structuur van cascaded updates/deletes helemaal loopt in een database die je niet zelf gemaakt hebt (of je bent het vergeten ) maar aan de andere kant is het misschien nog wel veel meer werk om het in code op te moeten zoeken.

[mocean]

Ik gebruik even het voorbeeld van een order-tabel, met simpele 1 product in 1 order:

code:

Clientnumber - bankcode - orderstatus - price - productcode - vatcode
8815531      - NLABN    - UNPAID      - 6.99  - PRODXYZ     - VATLOW

userId - bankId - statusId - price - productId - vatId
620    - 4      - 3        - 6.99  - 543       - 2

De eerste opzet kan ik bijna 1 op 1 in een export stoppen, of een rapportage etc. Bij oplossing 2 moet ik 4 joins gebruiken.

Gezien eerder commentaar op e-mail als P.I. heb ik een klantnummer gekozen als P.I. (dat e-mail onhandig is snap ik inmiddels, die kan wijzigen). Het gaat me nu meer om functionele keys in het algemeen, zoals gebruik van korte codes waarbij een tabel direct leesbaar is (klanten kunnen makkelijk eigen rapportages, query's maken e.d.). Bij programmeer werk verhoogt het ook de leesbaarheid enorm.

[ Voor 3% gewijzigd door mocean op 29-07-2011 17:44 ]

[RobIII]

mocean schreef op vrijdag 29 juli 2011 @ 17:43:
Ik gebruik even het voorbeeld van een order-tabel, met simpele 1 product in 1 order:

code:

Clientnumber - bankcode - orderstatus - price - productcode - vatcode
8815531      - NLABN    - UNPAID      - 6.99  - PRODXYZ     - VATLOW

userId - bankId - statusId - price - productId - vatId
620    - 4      - 3        - 6.99  - 543       - 2

De eerste opzet kan ik bijna 1 op 1 in een export stoppen, of een rapportage etc. Bij oplossing 2 moet ik 4 joins gebruiken.

Poehee! 4 héle joins! Je weet dat een beetje RDBMS (ja, zelfs MySQL ) daar niet warm of koud van wordt?

Daarbij is je al vaker verteld in dit topic dat (o.a.) productcodes wijzigen, dat "VATLOW" of "UNPAID" duurder is dan een "(int) 3" qua performance/opslag. En zelfs banken fuseren wel eens waardoor "NLABN" dan ook weer problemen kan gaan geven. De enige "natural key" in je voorbeeld die enigszins geschikt is is die waar je zélf controle over hebt; 't clientnumber.

mocean schreef op vrijdag 29 juli 2011 @ 17:43:

Gezien eerder commentaar op e-mail als P.I. heb ik een klantnummer gekozen als P.I. (dat e-mail onhandig is snap ik inmiddels, die kan wijzigen). Het gaat me nu meer om functionele keys in het algemeen, zoals gebruik van korte codes waarbij een tabel direct leesbaar is (klanten kunnen makkelijk eigen rapportages, query's maken e.d.). Bij programmeer werk verhoogt het ook de leesbaarheid enorm.

Granted, "UNPAID" scheelt twee (extra) bytes op een int* dus dat verschil zal niet heel groot zijn. Daar kunnen we dan nog over twisten. Maar wat ik niet zie: als je gebruikers dan toch rapportages e.d. gaan maken (en dus klaarblijkelijk bij de tabellen e.d. kunnen): waarom geef je ze geen view zodat ze daar de rapportages op kunnen baseren? Dan abstraheer je de onderliggende tabellen/joins/PK's/FK's en andere "rommel" die ze toch alleen maar in de weg zit weg en dan heb je best of both worlds. Zij een simpele "leesbare" 'tabel' en jij je synthetic keys en geen zeik als iemand een keer een productcode wijzigt of een bank fuseert of...

* Waarbij je, bij weinig statussen ook nog had kunnen kiezen voor een (tiny)int of enum of... wat dan wel weer een factor 2, 3 of meer scheelt

[ Voor 38% gewijzigd door RobIII op 29-07-2011 18:15 ]

[ACM]

RobIII schreef op vrijdag 29 juli 2011 @ 17:57:
Daarbij is je al vaker verteld in dit topic dat (o.a.) productcodes wijzigen, dat "VATLOW" of "UNPAID" duurder is dan een (int) 3 qua performance en zelfs banken fuseren wel eens waardoor "NLABN" dan ook weer problemen kan gaan geven.

Dat ze van naam en/of bancaire code kunnen wisselen is dan wel lastig, maar je hoeft er niet per se de key voor te wijzigen natuurlijk. Het wordt wel wat verwarrend als je nu de "NLPOSTBANK"-bank hebt bij sommige klanten en "NLING" bij anderen, terwijl beide records "ING Nederland" heten omdat ze ondertussen gefuseerd zijn. Anderzijds is dat probleem waarschijnijk vergelijkbaar met gewone surrogate keys.

Wat ik overigens niet zo goed snap is waarom die bank er uberhaupt bij zou moeten staan? Dat is toch een aspect van de klant of zelfs van de specifieke betaling? Om die er bij te krijgen zou je dus toch al e.o.a. join moeten uitvoeren. Hetzelfde geldt voor de betaalstatus, dat is waarschijnlijk iets dat je op order-niveau wilt bijhouden (of wellicht zelfs in een betalingen-tabel), waardoor je daar toch al joins nodig gaat hebben.

De VATLOW is ook een mooie. Het zou zomaar zo kunnen zijn dat het 6%-tarief verhoogd wordt naar 6.5%. Al je oude orders moeten dan natuurlijk met de 6% gepresenteerd blijven worden. Al je nieuwe met 6.5%. Als je dit met zo'n beschrijvende key zou opslaan, dan loop je dus wederom tegen problemen aan. Of ga je ze dan maar de nieuwe VATLOW_6_5 noemen ofzo? En vijf jaar later moet je nog maar weten dat VATLOW dan overeenkwam met 6%.

En voor producten krijg je ook hele gekunstelde namen met een grote kans op duplicaten die je dan moet zien op te lossen. Zoals APPLE_IPOD_NANO_4_GREEN enzo, of wil je die dan APPIPODN4GR ofzo gaan noemen en hoop je dat het dan nog duidelijk is wat dat precies betekende? En dan krijg je natuurlijk daarna een grijze nano 4... En sowieso, wie gaat al die keys verzinnen, of schrijf je daar een tool voor die hopelijk leesbare namen weet te verzinnen?

De enige "natural key" in je voorbeeld die enigszins geschikt is is die waar je zélf controle over hebt; 't clientnumber.

Sterker nog, als de clientnumber zelf gegenereerd wordt, dan zie ik uberhaupt geen meerwaarde in het hebben van twee surrogate keys (userid en clientnumber) voor dezelfde entiteit. Tenzij een van de twee weer kan wijzigen tzt natuurlijk.

[Remus]

Cyphax schreef op vrijdag 29 juli 2011 @ 14:24:
[...]

Waarom zou dat niet meer kunnen als e-mailadres de primary key is?
Het is misschien niet aan te raden maar het is op zich te implementeren.

Ik zou uiteindelijk kiezen voor een (zeker) unieke waarde die ook niet meer kan wijzigen. Zo'n betekenisloze sleutel is in die situatie waarschijnlijk wel het handigst, of je moet iets als SOFI/BSN hebben.

Is het BSN gegarandeerd uniek? Ik weet bijvoorbeeld dat het in de VS *niet* zo is, terwijl veel ontwikkelaars in de states daar vaak wel van uitgaan. Daarnaast is het gebruik/registratie van BSN volgens mij aan regels gebonden en mag je dat niet zomaar gebruiken en mag het zeker niet voor iedereen met toegang tot je systeem of database zichtbaar zijn.

Hoe het ook zij. Gebruik *nooit* identifiers als primary als die ontstaan en of een eigen leven leiden buiten je eigen systeem. Je kan ze evt wel als alternatieve sleutel (unique key) gebruiken als je denkt dat ze uniek zullen zijn, maar zelfs dan heb je grote kans dat je uiteindelijk bedrogen uitkomt.

[RobIII]

ACM schreef op vrijdag 29 juli 2011 @ 18:19:
Wat ik overigens niet zo goed snap is waarom die bank er uberhaupt bij zou moeten staan? Dat is toch een aspect van de klant of zelfs van de specifieke betaling? Om die er bij te krijgen zou je dus toch al e.o.a. join moeten uitvoeren. Hetzelfde geldt voor de betaalstatus, dat is waarschijnlijk iets dat je op order-niveau wilt bijhouden (of wellicht zelfs in een betalingen-tabel), waardoor je daar toch al joins nodig gaat hebben.

De VATLOW is ook een mooie. Het zou zomaar zo kunnen zijn dat het 6%-tarief verhoogd wordt naar 6.5%. Al je oude orders moeten dan natuurlijk met de 6% gepresenteerd blijven worden. Al je nieuwe met 6.5%. Als je dit met zo'n beschrijvende key zou opslaan, dan loop je dus wederom tegen problemen aan. Of ga je ze dan maar de nieuwe VATLOW_6_5 noemen ofzo? En vijf jaar later moet je nog maar weten dat VATLOW dan overeenkwam met 6%.

En voor producten krijg je ook hele gekunstelde namen met een grote kans op duplicaten die je dan moet zien op te lossen. Zoals APPLE_IPOD_NANO_4_GREEN enzo, of wil je die dan APPIPODN4GR ofzo gaan noemen en hoop je dat het dan nog duidelijk is wat dat precies betekende? En dan krijg je natuurlijk daarna een grijze nano 4... En sowieso, wie gaat al die keys verzinnen, of schrijf je daar een tool voor die hopelijk leesbare namen weet te verzinnen?

Sterker nog, als de clientnumber zelf gegenereerd wordt, dan zie ik uberhaupt geen meerwaarde in het hebben van twee surrogate keys (userid en clientnumber) voor dezelfde entiteit. Tenzij een van de twee weer kan wijzigen tzt natuurlijk.

Allemaal eensch Ik ging even uit van een "vlug vlug" gekozen voorbeeld dat niet helemaal optimaal als voorbeeld was waardoor ik daar maar niet op inging maar bij elk van deze punten sluit ik me aan.

Remus schreef op vrijdag 29 juli 2011 @ 20:05:
Is het BSN gegarandeerd uniek?

Het zou zo moeten zijn (volgens mij) maar ik heb al heel lang geleden daar niet op te vertrouwen Wat vandaag nog uniek is kan morgen, omdat er 1 of andere vage wet wordt aangenomen door een stel incompetente.... euh dus, en morgen kun je alles gaan verbouwen. Neuh, doe mij maar lekker m'n eigen keys dan

[Gomez12]

ACM schreef op vrijdag 29 juli 2011 @ 18:19:
[...]

Dat ze van naam en/of bancaire code kunnen wisselen is dan wel lastig, maar je hoeft er niet per se de key voor te wijzigen natuurlijk. Het wordt wel wat verwarrend als je nu de "NLPOSTBANK"-bank hebt bij sommige klanten en "NLING" bij anderen, terwijl beide records "ING Nederland" heten omdat ze ondertussen gefuseerd zijn. Anderzijds is dat probleem waarschijnijk vergelijkbaar met gewone surrogate keys.

Gewone surrogate keys hebben als voordeel dat je ze nooit direct gebruikt alsof ze een betekenis hebben...

NLPOSTBANK kan een 3e partij best opnemen zolang die bank de postbank heet.
Verandert de 3e partij de NLPOSTBANK opeens in NLING dan kan er opeens een onverwachte uitkomst komen omdat het opzich een geldige key is ( en dus ongemerkt doorvoer kan vinden qua 1e check ) terwijl er in de automatische verdere iets heel anders gebeurt...

Kan leuke effecten hebben als je automatische incasso's oid op deze manier in je systeem laat stromen en je aan het einde van de maand een belletje van ING krijgt dat bankrekening x zwaar in het rood staat terwijl Postbankrekening y nog zwaar in het zwart staat. Je betaalopdrachten komen nog steeds van dezelfde partijen, je betalingen zijn qua hoogte nog evengroot etc. etc. enkel je banksaldo is iets anders dan normaal...

En natuurlijk is het te voorkomen door tegen de 3e partij te zeggen dat ze gewoon NLPOSTBANK moeten blijven sturen (dat is namelijk afgesproken in de interface) maar dan gaat er ooit bij de 3e partij een leuke nieuwe boekhouder komen die denkt dat het toch netter is om van NLPOSTBANK NLING te maken zodat de naamsgeving klopt. Doe mij dan maar gewone nietszeggende id's waarbij niemand de noodzaak ziet om de id te veranderen als er een naamsverandering plaatsvind.

[coldasice]

Wolfboy schreef op vrijdag 29 juli 2011 @ 09:46:
[...]
Dat ben ik volledig met je eens overigens.

In mijn databases staan de on update/delete dan standaard ook op restrict ingesteld, liever en dikke foutmelding dan dat je per ongeluk ladingen data kwijt bent. Of dat je de hele server platlegt doordat die ene primary key toch wel erg veel foreign key referenties had...

of dat je bezig bent in de management studio met een delete constructie
delete persoon where persoonid=1

en je selecteert delete persoon, en hij mikt je hele tabel weg....

[off-topic] is het selecteren van een gedeelte van je query en daarna uitvoeren van dat gedeelte trouwens uit te zetten? Ik heb het bij verschillende mensen al meegemaakt, en het gros krijgt echt een hartverzakking[/off-topic]

[DataGhost]

coldasice schreef op zaterdag 30 juli 2011 @ 22:10:
[...]


of dat je bezig bent in de management studio met een delete constructie
delete persoon where persoonid=1

en je selecteert delete persoon, en hij mikt je hele tabel weg....

[off-topic] is het selecteren van een gedeelte van je query en daarna uitvoeren van dat gedeelte trouwens uit te zetten? Ik heb het bij verschillende mensen al meegemaakt, en het gros krijgt echt een hartverzakking[/off-topic]

offtopic:
Niet direct in je productiedatabase kliederen wil ook nog een boel schelen

[Soultaker]

Los van de genoemde praktische en performancebezwaren vind ik het principieel verkeerd on een veranderbaar veld als primary key te gebruiken. Het idee van een primary key is dat je er een entity uniek mee identificeert. Die hoort dus nooit te kunnen veranderen.

[Ventieldopje]

coldasice schreef op zaterdag 30 juli 2011 @ 22:10:
[...]


of dat je bezig bent in de management studio met een delete constructie
delete persoon where persoonid=1

en je selecteert delete persoon, en hij mikt je hele tabel weg....

[off-topic] is het selecteren van een gedeelte van je query en daarna uitvoeren van dat gedeelte trouwens uit te zetten? Ik heb het bij verschillende mensen al meegemaakt, en het gros krijgt echt een hartverzakking[/off-topic]

Moet je safe mode aan laten staan in de mysql workbench. Mocht je echt de tabel weg willen mieteren dan zet je er gewoon een loze WHERE in als WHERE `id` > 0 Die functie is er niet voor niets!

Wat betreft dit topic, doe wat je zelf wil maar ik zou het nooit doen. Altijd een id veld aan maken als primary key en voor de rest kun je dan prima aanmodderen met indexes en unique constraints Ook belangrijk vind ik het gebruik van een goede ORM

[Gomez12]

Soultaker schreef op zondag 31 juli 2011 @ 00:20:
Los van de genoemde praktische en performancebezwaren vind ik het principieel verkeerd on een veranderbaar veld als primary key te gebruiken. Het idee van een primary key is dat je er een entity uniek mee identificeert. Die hoort dus nooit te kunnen veranderen.

Het probleem is alleen veelal dat veel mensen dan redeneren uit voor hunzelf onveranderbare dingen. Gewoon met de gedachte van : ik heb mijn email adres al x jaar niet veranderd, dan zal niemand dat doen.

Voor mij zijn er weinig onveranderbare dingen dus ik kies altijd voor surrogate keys

Bijv BSN wat hier genoemd is, ik ga ervanuit dat het onveranderbaar is zolang je nederlands burger bent. Maar op het moment dat je zoiets in je dbase hebt staan heb je waarschijnlijk ook wel eens te maken mensen die emigreren en dan 5 jaar later weer immigreren. Dat is een situatie waarbij ik me afvraag of je wel je BSN houdt...
Of mensen die geimmigreerd zijn, dan weer emigreren en toch jouw "klant" willen blijven. Dan heb je op dat moment een key die alleen maar misleidend is

[coldasice]

Ventieldopje schreef op zondag 31 juli 2011 @ 00:31:
[...]


Moet je safe mode aan laten staan in de mysql workbench. Mocht je echt de tabel weg willen mieteren dan zet je er gewoon een loze WHERE in als WHERE `id` > 0 Die functie is er niet voor niets!

ik zal eens kijken of zoiets bestaat voor MSSQL, bedankt!

[Remus]

Gomez12 schreef op zondag 31 juli 2011 @ 00:37:
Bijv BSN wat hier genoemd is, ik ga ervanuit dat het onveranderbaar is zolang je nederlands burger bent. Maar op het moment dat je zoiets in je dbase hebt staan heb je waarschijnlijk ook wel eens te maken mensen die emigreren en dan 5 jaar later weer immigreren. Dat is een situatie waarbij ik me afvraag of je wel je BSN houdt...
Of mensen die geimmigreerd zijn, dan weer emigreren en toch jouw "klant" willen blijven. Dan heb je op dat moment een key die alleen maar misleidend is

Daarnaast mag je het BSN als bedrijf bijna nooit gebruiken of opslaan, behalve voor loonuitbetaling / melding naar de belasting met betrekking tot een werknemer.

[vorlox]

De TS vroeg om ervaringen en zo heb ik er 1 tje.
Een paar jaar geleden besloot ik in al mijn wijsheid om GUID's te gebruiken als PK.
In eerste in stantie leek alles prima te werken, tot ik op een gegeven moment +/- 20K regels in mijn artikel tabel had...en ik dacht wat zijn die joins toch rete traag.
Even een testje opgezet met een int PK en WTF het scheelde factor 10.
Nu is een guid echt wel iets anders als een e-mail adres, maar ik zou het maar gewoon bij joins en views houden.....ga je ons echt voor bedanken over een record of 10.000

[Woy]

vorlox schreef op zondag 31 juli 2011 @ 21:42:
De TS vroeg om ervaringen en zo heb ik er 1 tje.
Een paar jaar geleden besloot ik in al mijn wijsheid om GUID's te gebruiken als PK.
In eerste in stantie leek alles prima te werken, tot ik op een gegeven moment +/- 20K regels in mijn artikel tabel had...en ik dacht wat zijn die joins toch rete traag.
Even een testje opgezet met een int PK en WTF het scheelde factor 10.
Nu is een guid echt wel iets anders als een e-mail adres, maar ik zou het maar gewoon bij joins en views houden.....ga je ons echt voor bedanken over een record of 10.000

Dat is natuurlijk een compleet andere situatie, en op zich zijn GUID's helemaal niet verkeerd als PK. Het verschilt ook niet zoveel van een incrementele PK. De performance zal ook vooral afhankelijk zijn van welk RDBMS je gebruikt, en tegen welke andere Key je getest hebt.

Een nadeel van een GUID is dat die 16 bytes groot is, en een "standaard" key maar 4 of 8 bytes, dus je key zal 2 tot 4 maal zo groot zijn. Er kunnen echter ook voordelen zijn, zoals dat de key generatie makkelijk ergens anders plaats kan vinden.

Je kunt dus niet zondermeer zeggen dat je nooit GUID's moet gebruiken als key.

[RobIII]

Woy schreef op zondag 31 juli 2011 @ 22:22:
Je kunt dus niet zondermeer zeggen dat je nooit GUID's moet gebruiken als key.

Precies; vooral bij situaties waarbij (delen van) tabellen gaat mergen met (bijv.) offline clients of in gevallen waarbij je replicatie gebruikt zijn GUID's verdomd handig. Echter, nog een vervelend nadeel van een GUID (behalve de grootte ervan dus zoals Woy aangeeft) is dat ze niet opeenvolgend zijn ("random") en je dus een aardige fragmentatie van je index krijgt; dat is meestal nog te overzien zolang je niet voor het maximaal haalbare gaat maar als je een clustered index gebruikt (wat onder MSSQL bijv. de default is voor PK's) dan kon je daar ook nog wel eens minder vrolijk van worden Dus wel even opletten dat je "clustered" uit zet en goed wakker blijven bij 't ontwerpen van je DB

[ Voor 21% gewijzigd door RobIII op 31-07-2011 22:35 ]

[-DarkShadow-]

ACM schreef op vrijdag 29 juli 2011 @ 18:19:
[...]
De VATLOW is ook een mooie. Het zou zomaar zo kunnen zijn dat het 6%-tarief verhoogd wordt naar 6.5%. Al je oude orders moeten dan natuurlijk met de 6% gepresenteerd blijven worden. Al je nieuwe met 6.5%. Als je dit met zo'n beschrijvende key zou opslaan, dan loop je dus wederom tegen problemen aan. Of ga je ze dan maar de nieuwe VATLOW_6_5 noemen ofzo? En vijf jaar later moet je nog maar weten dat VATLOW dan overeenkwam met 6%.

Bij de order sla je ook de datum en tijd op waarop deze is geplaatst. In de tabel waarin VATLOW staat opgeslagen, sla je dan ook op in welke periode welke waarde geldig is:

code:

| id     | value | start    | end        |
------------------------------------------
| VATLOW | 6.0   | 1-1-2009 | 31-12-2010 |
| VATLOW | 6.5   | 1-1-2011 | 31-12-2090 |

Schijnt in de accounting wereld wel gebruikelijk te zijn.