[Databases] Waarom namen gebruiken als PK?

[Frenkpie]

Het is misschien een simpele kwestie voor sommige maar ik ben er zelf al een tijdje over aan het brainstormen geweest en heb al aan verschillende (Informatica) mensen gevraagd waarom je in sommige situaties namen kunt gebruiken en waarom je in sommige situaties nummers gebruikt als identificerende sleutel.

Deze vraag kwam bij mij naar boven, omdat ik toevallig in een boek had gelezen dat men soms ervoor kiest om naam te gebruiken als PK ipv een nummer, maar er stond niet uitgelegd wáárom je dat zou doen.

Ik kan geen een situatie bedenken waarom je een naam zou nemen als PK ipv een nummer. Ik ben zelf alleen tot deze argument gekomen maar imo is het ok niet echt 100% logisch:

- wanneer een veld "naam" van bijv. een tabel "product" altijd uniek zal zijn, kún je dit als PK kiezen omdat je dan geen extra veld hoeft toe te voegen wat weer (onnodig) database ruimte in beslag neemt.

Kan iemand mij uit mijn lijden verlossen?

ps. ik wist niet zeker onder welke sectie dit hoort, dus ik 'gokte' dat ie hier hoort

[ Voor 4% gewijzigd door Frenkpie op 18-06-2007 10:35 ]

[RobIII]

"Naam" moet je denk ik wat breder zien. Je kunt prima een artikelnummer (mits uniek) als PK gebruiken. Het probleem met een naam is dat er meer hondjes zijn die Fikkie heten. Als je die garantie (uniek) hebt met een artikelnummer bijvoorbeeld dan kun je dat dus prima als PK gebruiken. Moet je wel even rekening houden met wat er gebeurd als een artikel een ander artikelnummer toegekend krijgt (dat is iets wat met namen juist weer nooit zelden voorkomt).

[ Voor 23% gewijzigd door RobIII op 18-06-2007 10:38 ]

[Anoniem: 178962]

Je geeft zelf het antwoord al, soms is er al een unieke eigenschap die geschikt is als primary key, waarom dan overhead toevoegen voor een extra nummer?

In de praktijk echter voegen veel mensen voor de zekerheid alsnog gewoon een nummer als primary key toe, die dan uniek is binnen de database. De oude primary key krijgt dan gewoon een unieke index waardoor die net zo goed blijft werken.

Dit helpt in de toekomst als blijkt dat die eigenschap in de praktijk toch niet zo uniek was en dus een slechte keuze was als key.

Er zijn veel discussies over de voor en nadelen en hoe netjes het is om gewoon overal maar een nummer als primary key tegenaan te gooien (soms zelfs waar er een prima primary key van meerdere kolommen beschikbaar is die dus beter zou zijn), maar tegenwoordig is de overhead zo klein dat het niet veel meer boeit.

Ben je purist dan kies je gewoon netjes je keys bij iedere tabel (en denk je er dus goed over na), ben je gewoon snel aan het proggen dan gooi je overal een nummer tegenaan.

Zit je er tussenin dan doe je waar je zelf zin in hebt

[Anoniem: 146163]

Je "zou" 't volgens mij ook kunnen zien vanuit performance oogpunt voor queries? Hoe vaak zoek je op 'naam' en hoe vaak zoek je op een abstract nummertje die je toevallig toevoegt om een record uniek te maken. Daarnaast kan je soms ook joins vermijden als je een 'echte' waarde gebruikt als PK (en dus ook als FK in andere tabellen).
Heel klein voorbeeldje, 2 tabellen:

code:

Gebruikers
----------------
Gebruikersnaam (PK)
Wachtwoord

Berichten
----------------
Berichttitel
Gebruikersnaam (FK)
Bericht

Als je in dit (specifieke) geval een bericht wilt weergeven inclusief degene die het gepost heeft, hoef je geen JOIN te doen om de gebruikersnaam te achterhalen. Wel als meer info wilt natuurlijk. Daarbij, als de gebruiker verwijderd wordt is nog steeds te zien wie het bericht gepost heeft.

[edit]
Zelf gebruik ik toch over 't algemeen gewoon een automatisch genummerd ID, is makkelijker ;-)

[ Voor 6% gewijzigd door Anoniem: 146163 op 18-06-2007 10:45 ]

[RobIII]

Anoniem: 146163 schreef op maandag 18 juni 2007 @ 10:44:
Je "zou" 't volgens mij ook kunnen zien vanuit performance oogpunt voor queries? Hoe vaak zoek je op 'naam' en hoe vaak zoek je op een abstract nummertje die je toevallig toevoegt om een record uniek te maken.

Daar zijn indexes voor uitgevonden

Anoniem: 146163 schreef op maandag 18 juni 2007 @ 10:44:
Daarnaast kan je soms ook joins vermijden als je een 'echte' waarde gebruikt als PK (en dus ook als FK in andere tabellen).
<snip>
Als je in dit (specifieke) geval een bericht wilt weergeven inclusief degene die het gepost heeft, hoef je geen JOIN te doen om de gebruikersnaam te achterhalen. Wel als meer info wilt natuurlijk.

Als je al op dat niveau moet gaan 'optimaliseren' moet je eens nagaan wat er nog meer mankeert aan je database (of DBMS )

[ Voor 5% gewijzigd door RobIII op 18-06-2007 10:47 ]

[Erkens]

Anoniem: 146163 schreef op maandag 18 juni 2007 @ 10:44:
Als je in dit (specifieke) geval een bericht wilt weergeven inclusief degene die het gepost heeft, hoef je geen JOIN te doen om de gebruikersnaam te achterhalen. Wel als meer info wilt natuurlijk. Daarbij, als de gebruiker verwijderd wordt is nog steeds te zien wie het bericht gepost heeft.

Maar als je de gebruikersnaam wilt veranderen heb je een probleem, PK's moet je gewoon nooit (willen) veranderen.

[Janoz]

Anoniem: 178962 schreef op maandag 18 juni 2007 @ 10:38:
Je geeft zelf het antwoord al, soms is er al een unieke eigenschap die geschikt is als primary key, waarom dan overhead toevoegen voor een extra nummer?

Over het algemeen genereert het zoeken op een niet numeriek veld (Zoals een naam, of een artikelnummer met voorloopnullen. Zelfs een telefoonnummer valt in deze context onder niet numeriek) vele malen meer overhead dan een extra kolom.
---
Imho is er maar 1 valide reden om met naam PK te werken en dat is wanneer je aangewezen bent op een legacy systeem waarin je deze fout niet meer ongedaan kunt maken. Ook voor gecombineerde PK's is maar 1 uitzondering, en dat is voor koppeltabellen. In alle andere gevallen is het toevoegen van een, voor het domein niks betekenend, getal de enige juiste weg.

[ Voor 26% gewijzigd door Janoz op 18-06-2007 11:00 ]

[Frenkpie]

Anoniem: 146163 schreef op maandag 18 juni 2007 @ 10:44:
Je "zou" 't volgens mij ook kunnen zien vanuit performance oogpunt voor queries? Hoe vaak zoek je op 'naam' en hoe vaak zoek je op een abstract nummertje die je toevallig toevoegt om een record uniek te maken. Daarnaast kan je soms ook joins vermijden als je een 'echte' waarde gebruikt als PK (en dus ook als FK in andere tabellen).
Heel klein voorbeeldje, 2 tabellen:

code:

Gebruikers
----------------
Gebruikersnaam (PK)
Wachtwoord

Berichten
----------------
Berichttitel
Gebruikersnaam (FK)
Bericht

Als je in dit (specifieke) geval een bericht wilt weergeven inclusief degene die het gepost heeft, hoef je geen JOIN te doen om de gebruikersnaam te achterhalen. Wel als meer info wilt natuurlijk. Daarbij, als de gebruiker verwijderd wordt is nog steeds te zien wie het bericht gepost heeft.

[edit]
Zelf gebruik ik toch over 't algemeen gewoon een automatisch genummerd ID, is makkelijker ;-)

Hier zit wel wat in natuurlijk, bij het schrijven van SQL queries hoef je dan minder gebruik te maken van joins en subqueries waardoor je systeem minder wordt belast. Nu zul je daar tegenwoordig niet veel last van hebben bij een kleine access database met 10 records, maar met bijv. 10.000 records wordt het al een ander verhaal.

Dus stel je hebt deze situaties:

Situatie 1:
Bestelregel: artikelnaam, bestel_ID, aantal
Artikel: artikelnaam, prijs,.... etc.

en je wilt bijv. een query schrijven waarbij je het artikelnaam wilt zien op een formulier bij het aantal doe je gewoon dit:

code:

SELECT artikelnaam, aantal FROM Bestelregel;

Situatie 2:
Bestelregel: artikel_ID, bestel_ID, aantal
Artikel: artikel_ID,artikelnaam, prijs,.... etc.

code:

SELECT B.Artikel_ID, Artikelnaam, Aantal 
FROM Bestelregel B, Artikel A
WHERE B.artikel_ID = A.artikel_ID;

En uiteraard moet het veldje "naam" uniek zijn als PK zijnde

Erkens schreef op maandag 18 juni 2007 @ 10:53:
[...]

Maar als je de gebruikersnaam wilt veranderen heb je een probleem, PK's moet je gewoon nooit (willen) veranderen.

hmm ja daar heb je ook een punt !

[ Voor 6% gewijzigd door Frenkpie op 18-06-2007 11:00 ]

[Janoz]

Met juiste indexen en fatsoenlijke queries denk ik niet eens dat je iets merkt tussen die query met join en de query zonder join. Vergeet bijvoorbeeld niet dat het voor een DB duurder is om een varchar als PK te hebben.

[Janoz]

Dit topic lijkt (oa) mij misschien wel beter in SE&A passen..

[Anoniem: 178962]

Janoz schreef op maandag 18 juni 2007 @ 10:57:
[...]

Over het algemeen genereert het zoeken op een niet numeriek veld (Zoals een naam, of een artikelnummer met voorloopnullen. Zelfs een telefoonnummer valt in deze context onder niet numeriek) vele malen meer overhead dan een extra kolom.

Daarom zeg ik ook soms, het komt niet vaak voor.

Een niet numeriek veld als key kiezen is inderdaad (vaak) waanzin qua performance.

[KabouterSuper]

Interessante vraag. Ik werk al een aantal jaar met Oracle databases, en we gebruik hier zelden een getal (lees: autoincrement kolom) voor een PK. Onze 10 geboden verbieden dit ook, met twee uitzonderingen:
1) Je kunt geen (combinatie van) veld(en) vinden wat de regel uniek maakt.
2) Je primary key bestaat uit een grote varchar, en dit levert performance problemen op.....joins op integers zijn nou eenmaal sneller dan joins op varchars.

Overigens: in MySQL is het een stuk gemakkelijker om een autoincrement kolom aan te maken dan in Oracle......je moet in Oracle dan namelijk een sequence en een trigger aanmaken. Alleen al vanwege het extra onderhoud hiervan zijn we niet dol op autoincrements.

[Salandur]

het hele idee van een PK is dat hij nooit wijzigd. Een gebruikersnaam, artikelnaam, telefoonnummer kunnen wijzigen en zijn derhalve niet geschikt als PK. Op die colommen leg je dan een unieke index zodat ze ten alle tijden maar 1 keer kunnen voorkomen.

Overigens: in MySQL is het een stuk gemakkelijker om een autoincrement kolom aan te maken dan in Oracle......je moet in Oracle dan namelijk een sequence en een trigger aanmaken. Alleen al vanwege het extra onderhoud hiervan zijn we niet dol op autoincrements.
[/quote]
Je kan ook vooraf de waarde van de sequence opvragen en zelf instellen. Dan kan je ook gebruik maken van de increment size van de oracle-sequence waardoor je de waarde kan cachen en zelf kan ophogen wat weer scheelt in database io. maar dat is oracle specifiek

[ Voor 50% gewijzigd door Salandur op 18-06-2007 11:09 ]

[Frenkpie]

Janoz schreef op maandag 18 juni 2007 @ 11:03:
Met juiste indexen en fatsoenlijke queries denk ik niet eens dat je iets merkt tussen die query met join en de query zonder join. Vergeet bijvoorbeeld niet dat het voor een DB duurder is om een varchar als PK te hebben.

Waarom is dat duurder? omdat een Varchar meestal uit meerdere karakters bestaat dan een integer?

[Erkens]

Frenkpie schreef op maandag 18 juni 2007 @ 11:08:
Waarom is dat duurder? omdat een Varchar meestal uit meerdere karakters bestaat dan een integer?

Omdat een varchar geen fixed size heeft misschien?

[Anoniem: 49627]

RobIII schreef op maandag 18 juni 2007 @ 10:46:
Als je al op dat niveau moet gaan 'optimaliseren' moet je eens nagaan wat er nog meer mankeert aan je database (of DBMS )

Ik zou je daar niet op verkijken. Het vermijden van een join kan in redelijk wat scenario's een behoorlijke performance winst opleveren. Het is echt een misconceptie dat een join geen (significante) performance impact heeft.

[Salandur]

en een varchar moet byte voor byte geevalueerd worden terwijl bij een integer alle bytes in 1 keer vergeleken kunnen worden door de processor

[Frenkpie]

Salandur schreef op maandag 18 juni 2007 @ 11:07:
het hele idee van een PK is dat hij nooit wijzigd. Een gebruikersnaam, artikelnaam, telefoonnummer kunnen wijzigen en zijn derhalve niet geschikt als PK. Op die colommen leg je dan een unieke index zodat ze ten alle tijden maar 1 keer kunnen voorkomen.

Waarom zou een PK nooit mogen wijzigen? Kun je het niet zo maken t wanneer je de PK (artikelnaam) wijzigt naar een andere naam, dat het DMS de waardes van de FK in andere tabellen ook update?

[Frenkpie]

Erkens schreef op maandag 18 juni 2007 @ 11:09:
[...]

Omdat een varchar geen fixed size heeft misschien?

Je kan in MySQL een varchar wel een max length geven hoor

Anoniem: 49627 schreef op maandag 18 juni 2007 @ 11:10:
[...]

Ik zou je daar niet op verkijken. Het vermijden van een join kan in redelijk wat scenario's een behoorlijke performance winst opleveren. Het is echt een misconceptie dat een join geen (significante) performance impact heeft.

Maarja, als je weet dat je in je database een naam als PK gebruikt en in een andere Query gaat gebruiken voor een join, kán de totale performance van een database lager zijn dan wanneer je een nummer toevoegd en een extra join moet gebruiken (situatie 2 vorige post)

[ Voor 57% gewijzigd door Frenkpie op 18-06-2007 11:14 ]

[Confusion]

Janoz schreef op maandag 18 juni 2007 @ 10:57:
In alle andere gevallen is het toevoegen van een, voor het domein niks betekenend, getal de enige juiste weg.

Geldt dat ook voor kleine tabellen? Stel ik heb een tabel met 50 unieke tweeletterige codes en hun beschrijving. Zou je dan aan die tabel alsnog een (klein) integer veld toevoegen om als PK te dienen?

[Erkens]

Frenkpie schreef op maandag 18 juni 2007 @ 11:11:
Waarom zou een PK nooit mogen wijzigen? Kun je het niet zo maken t wanneer je de PK (artikelnaam) wijzigt naar een andere naam, dat het DMS de waardes van de FK in andere tabellen ook update?

Natuurlijk kan dat, maar je wilt niet weten wat de impact daarvan is, zeker als je een grote DB hebt. Afgezien het feit dat wellicht andere gebruikers op dat moment gegevens proberen op te vragen dmv die PK.

Frenkpie schreef op maandag 18 juni 2007 @ 11:12:
Je kan in MySQL een varchar wel een max length geven hoor

maxlength != size, je kan beter CHAR's gebruiken ipv VARCHAR's, zeker als je ze als PK zou willen gebruiken

[ Voor 21% gewijzigd door Erkens op 18-06-2007 11:14 ]

[Voutloos]

Frenkpie schreef op maandag 18 juni 2007 @ 10:59:
[Hier zit wel wat in natuurlijk, bij het schrijven van SQL queries hoef je dan minder gebruik te maken van joins en subqueries waardoor je systeem minder wordt belast. Nu zul je daar tegenwoordig niet veel last van hebben bij een kleine access database met 10 records, maar met bijv. 10.000 records wordt het al een ander verhaal.

Ten eerste is 10k rows nog steeds niets, ten tweede zijn goede joins niet duur. Nofi, maar in dit geval is de naam als PK methode alleen een voordeel als je bang bent voor een query met join.

Anoniem: 49627 schreef op maandag 18 juni 2007 @ 11:10:
[...]
Ik zou je daar niet op verkijken. Het vermijden van een join kan in redelijk wat scenario's een behoorlijke performance winst opleveren. Het is echt een misconceptie dat een join geen (significante) performance impact heeft.

Neuh, het gaat hier om een zeer eenvoudige join om een waarde op te halen welke gewoon geen ideale PK is en daarmee gaat het hier niet over een scenario waarin het qua performance uitmaakt (carthesisch product op grote tabel oid).

[Anoniem: 178962]

Salandur schreef op maandag 18 juni 2007 @ 11:10:
en een varchar moet byte voor byte geevalueerd worden terwijl bij een integer alle bytes in 1 keer vergeleken kunnen worden door de processor

Ik ben heel blij dat dat in ieder geval niet waar is, maar feit blijft dat een varchar iets lastiger te verwerken is als een int.

Dit komt voornamelijk doordat er eerst gekeken moet worden naar de lengte (wat vaak al een (short)int is) en daarna pas naar de inhoud. Het is dus altijd een orde van grote trager dan alleen het controleren van een int (wat je al gedaan hebt bij een varchar, alles daarna is verlies).

Anoniem: 49627 schreef op maandag 18 juni 2007 @ 11:10:
[...]

Ik zou je daar niet op verkijken. Het vermijden van een join kan in redelijk wat scenario's een behoorlijke performance winst opleveren. Het is echt een misconceptie dat een join geen (significante) performance impact heeft.

Als je van redelijk sommige maakt zou ik het met je eens zijn. Geen reden imho om dan maar joins te vermijden, ik zou dan eerder kijken naar een slim cache systeem (eventueel met behulp van temp tables).

[bazkar]

Ik ben ook heel sterk VOOR het toevoegen van een nietszeggend nummer als PK bij een tabel, vanwege alle redenen die hierboven genoemd worden.

Bovendien zie je vaak bij bv. artikelnummers die als PK gebruikt 'zouden kunnen worden' dat er een betekenis (delen van) het nummer toegekend wordt: de eerste zoveel cijfers staan voor eigenschap A, de volgende zoveel voor eigenschap B etc. etc. Dit soort zaken zorgt er alleen maar voor dat de PK eerder moet veranderen (oeps, we hadden maar 2 cijfers gereserveerd voor eigenschap B en nu zijn er meer dan 100 verschillende waardes voor die eigenschap ontstaan... probleem...)

Met de performance van machines tegenwoordig en met een verder goed database en query design moet de kleine overheid van de extra nummers en daardoor extra joins geen probleem opleveren.

[Janoz]

Anoniem: 49627 schreef op maandag 18 juni 2007 @ 11:10:
Ik zou je daar niet op verkijken. Het vermijden van een join kan in redelijk wat scenario's een behoorlijke performance winst opleveren. Het is echt een misconceptie dat een join geen (significante) performance impact heeft.

Deze performance problemen zou ik liever middels een view oplossen. Op die manier kan je DBMS de gegevens netjes cachen. Mocht dat niet genoeg zijn dan zou je eventueel redundante data toe kunnen voegen, puur voor performance.

Frenkpie schreef op maandag 18 juni 2007 @ 11:11:
Waarom zou een PK nooit mogen wijzigen? Kun je het niet zo maken t wanneer je de PK (artikelnaam) wijzigt naar een andere naam, dat het DMS de waardes van de FK in andere tabellen ook update?

Bedenk je even wat een enorme impact dit heeft op je complete database. Voor deze actie zul je eerst de constraints uit moeten zetten, vervolgens moet je overal een waarde aanpassen waarbij de index tabellen ook allemaal gewijzigd worden. Om vervolgens ook nog een beetje de integriteit van de database te waarborgen zou je er eigenlijk voor moeten zorgen dat je exclusieve toegang hebt.

Confusion schreef op maandag 18 juni 2007 @ 11:12:
[...]

Geldt dat ook voor kleine tabellen? Stel ik heb een tabel met 50 unieke tweeletterige codes en hun beschrijving. Zou je dan aan die tabel alsnog een (klein) integer veld toevoegen om als PK te dienen?

IMO? Ja, maar eventueel zou je ook een enumeration kunnen overwegen. De staten van amerika (gezien het datatype omschrijving redelijk toepasbaar) lijken me een behoorlijk statisch gegeven .

[bazkar]

Janoz schreef op maandag 18 juni 2007 @ 11:22:
IMO? Ja, maar eventueel zou je ook een enumeration kunnen overwegen. De staten van amerika (gezien het datatype omschrijving redelijk toepasbaar) lijken me een behoorlijk statisch gegeven .

Kijk, daar zou ik inderdaad een valide reden vinden om 'eventueel' zonder extra PK te werken, de tweeletterige code voor een staat in amerika is echt wel uniek, daar zorgt de VS zelf wel voor... Dan zou je je dus niet druk hoeven te maken over codering etc.

Maar stel (advocaat van de duivel) dat er ooit een staat afvalt en die domme amerikanen besluiten om een nieuwe staat toe te voegen en die dezelfde code te geven, dan heb je alsnog een probleem , better safe than sorry. (Ik heb al gekkere dingen gezien in Amerika... wetsvoorstellen waarin staat dat de waarde van Pi 4 is....)

[Anoniem: 49627]

Janoz schreef op maandag 18 juni 2007 @ 11:22:
Deze performance problemen zou ik liever middels een view oplossen. Op die manier kan je DBMS de gegevens netjes cachen. Mocht dat niet genoeg zijn dan zou je eventueel redundante data toe kunnen voegen, puur voor performance.

Ja er zijn legio oplossing en een view is daar een van. Maar een view heeft weer de prerequisitie dat de achterliggende data weinig veranderd, anders ga je net zo hard nat. Ik wilde alleen even benadrukken dat een join simpelweg impact heeft op de performance. Niet altijd significant, maar het afdoen als compleet kostenloos is ook niet terecht.

[KabouterSuper]

bazkar schreef op maandag 18 juni 2007 @ 11:19:
Ik ben ook heel sterk VOOR het toevoegen van een nietszeggend nummer als PK bij een tabel, vanwege alle redenen die hierboven genoemd worden.

Heerlijk gebruik van het woord "nietszeggend". Ik ben heel sterk TEGEN het toevoegen van nietszeggende gegevens, tenzij er een hele goede reden voor is (en daar zijn er imho maar twee van). Het gebruik van unique constraints om uniciteit te garanderen is symptoombestrijding, je kunt het beter bij de bron oplossen, namelijk een goed datamodel.

bazkar schreef op maandag 18 juni 2007 @ 11:19:Met de performance van machines tegenwoordig en met een verder goed database en query design moet de kleine overheid van de extra nummers en daardoor extra joins geen probleem opleveren.

Ofwel andersom geformuleerd: Met de performance van machines tegenwoordig zal het gebruik van varchars in joins in plaats van integers geen probleem opleveren.

[RobIII]

Anoniem: 49627 schreef op maandag 18 juni 2007 @ 11:10:
[...]

Ik zou je daar niet op verkijken. Het vermijden van een join kan in redelijk wat scenario's een behoorlijke performance winst opleveren. Het is echt een misconceptie dat een join geen (significante) performance impact heeft.

Oh, don't get me wrong; ik bedoelde het inderdaad niet zo letterlijk. In 9 van de 10 gevallen heb je die join denk ik toch net zo goed nodig omdat je meer dan een username zult willen hebben (om maar iets te noemen) uit die tabel. En voor de rest: met Janoz

[eamelink]

Janoz schreef op maandag 18 juni 2007 @ 11:22:
Bedenk je even wat een enorme impact dit heeft op je complete database. Voor deze actie zul je eerst de constraints uit moeten zetten, vervolgens moet je overal een waarde aanpassen waarbij de index tabellen ook allemaal gewijzigd worden. Om vervolgens ook nog een beetje de integriteit van de database te waarborgen zou je er eigenlijk voor moeten zorgen dat je exclusieve toegang hebt.

Of je zet gewoon achter al je foreign key definities "ON UPDATE CASCADE" en je RDBMS regelt het allemaal voor je

[Anoniem: 49627]

eamelink schreef op maandag 18 juni 2007 @ 11:47:
Of je zeg gewoon achter al je foreign key definities "ON UPDATE CASCADE" en je RDBMS regelt het allemaal voor je

Ja dat vinden je transactie tabellen ook heeeeel erg fijn

[eamelink]

Anoniem: 49627 schreef op maandag 18 juni 2007 @ 11:27:
[...]
Ja er zijn legio oplossing en een view is daar een van. Maar een view heeft weer de prerequisitie dat de achterliggende data weinig veranderd, anders ga je net zo hard nat. Ik wilde alleen even benadrukken dat een join simpelweg impact heeft op de performance. Niet altijd significant, maar het afdoen als compleet kostenloos is ook niet terecht.

Natuurlijk, dat hangt geheel van de join zelf af . Maar in het geval van een user bij een post zoeken valt het reuze mee; al je condities hangen alleen af van je posts tabel, dan blijft er maar één record over waar alleen nog één record uit de user tabel aan gejoind hoeft te worden op de primary key. Nou, dat valt reuze mee . Maar het is goed om er van tevoren over na te denken inderdaad

[whoami]

KabouterSuper schreef op maandag 18 juni 2007 @ 11:29:
[...]


Heerlijk gebruik van het woord "nietszeggend". Ik ben heel sterk TEGEN het toevoegen van nietszeggende gegevens, tenzij er een hele goede reden voor is (en daar zijn er imho maar twee van). Het gebruik van unique constraints om uniciteit te garanderen is symptoombestrijding, je kunt het beter bij de bron oplossen, namelijk een goed datamodel.

Surrogate PK's horen imho bij een goed datamodel. Ik vind het geen goed idee om een Natural PK te gebruiken; in feite is de PK enkel nodig als 'administratief' iets voor je DB. De gebruiker heeft er helemaal niks mee te maken, en een Primary Key zou ook nooit mogen wijzigen.
Wie weet, als je een natural key gebruikt, wil de gebruiker ooit wel eens de waarde van een key veranderen, en dan heb je een klein probleempje. (Referenties, etc.... Ok, dat kan je oplossen dmv cascading, maar ik vermijd het toch liever).

[Janoz]

KabouterSuper schreef op maandag 18 juni 2007 @ 11:29:
Heerlijk gebruik van het woord "nietszeggend". Ik ben heel sterk TEGEN het toevoegen van nietszeggende gegevens, tenzij er een hele goede reden voor is (en daar zijn er imho maar twee van). Het gebruik van unique constraints om uniciteit te garanderen is symptoombestrijding, je kunt het beter bij de bron oplossen, namelijk een goed datamodel.

Tja, leuk utopisch, maar in de werkelijkheid is 'onveranderlijk en uniek' enorm rekbaard. Met nietszeggend wordt hier nietszeggend in de werkelijkheid bedoeld. Dat is ideaal omdat dat er voor zorgt dat de werkelijkheid er niks over te zeggen heeft en de database beheerder dus de enige is die bepaald wat de waarde is.

De keren dat ik meegemaakt heb dat ik bij een klant expliciet vraag of er geen uitzonderingen zijn, dit stellig wordt beweerd en twee weken later ineens een uitzondering naar boven komt en dit wordt afgedaan met 'ja, maar dat komt eigenlijk nooit voor' zijn legio. Buiten de informatie analyse, en dus voor 'normale' mensen betekenen 'nooit voorkomen' en 'zo goed als bijna nooit voorkomen' gewoon hetzelfde.

[eamelink]

Het consistente gebruik van een primary key is ook gewoon handig voor de leesbaarheid van je database. Als ik een database gebruik van iemand anders, dan heb ik het liefst dat gewoon in elke tabel een id veld zit, en niet in één tabel toevallig niet, omdat daar een ander geschikt veld was om pk te maken.

Tel daar bij op dat mijn OR mapper net zo denkt als ik, en heel blij wordt van een id veld in elke tabel waarvan de records naar objecten gemapt worden, en je snapt wel dat ik gewoon altijd id gebruik, ongeacht de aanwezigheid van geschikte andere pk's.

[Confusion]

eamelink schreef op maandag 18 juni 2007 @ 12:31:
Het consistente gebruik van een primary key is ook gewoon handig voor de leesbaarheid van je database.

Ik vind eerder genoemde tweeletterige codes eigenlijk leesbaarder. De foreign key 'VL' zegt me iets; '14' zegt me niets. Wat betreft queries en data definities maakt het niet uit, als de velden dezelfde, fatsoenlijke, namen hebben. Dit gaat natuurlijk alleen op voor gevallen waarin je dat soort codes hebt; je moet ze niet gaan verzinnen.

[ Voor 10% gewijzigd door Confusion op 18-06-2007 12:56 ]

[KabouterSuper]

Ik zie zowel Whoami als Janoz het over klanten/gebruikers hebben......zouden jullie dezelfde keuzen maken als er geen klanten/gebruikers zouden bestaan? Ik ben erg voor het afvangen van fouten van dummy gebruikers, maar dit betekent niet dat ik mijn gehele database ontwerp hierop aanpas. Zo'n 2 procent van een gemiddelde database waar ik mee werk is toegankelijk voor klanten. Hoe zit dit bij jullie?

De opmerkingen over het niet kunnen aanpassen van PK's zijn denk ik ook gebaseerd op het klant/gebruikers perspectief. Stel je eens voor dat je een applicatie hebt die geautomatiseerd wisselkoersen inleest. De applicatie moet zowel nieuwe koersen kunnen inlezen als wijzigingen met terugwerkende kracht. Ik vind toch echt dat de tabel VALUTA_ID en DATUM als primary key moet hebben, en niet een autoincrement kolom. De natural PK maakt het updaten van backdated wijzigingen ook erg eenvoudig. Ik ben het roerend met iedereen eens dat VALUTA_ID een identifier moet zijn (EUR, USD, JPY, etc), en geen omschrijving. Of dit dan een integer is of een varchar2(3) is lood om oud ijzer wat mij betreft.....ik vind EUR overigens gemakkelijker lezen dan het getal 17.

[Erkens]

KabouterSuper schreef op maandag 18 juni 2007 @ 12:58:
Ik zie zowel Whoami als Janoz het over klanten/gebruikers hebben......zouden jullie dezelfde keuzen maken als er geen klanten/gebruikers zouden bestaan?

geen klanten/gebruikers -> geen software -> geen database

Ik ben erg voor het afvangen van fouten van dummy gebruikers, maar dit betekent niet dat ik mijn gehele database ontwerp hierop aanpas. Zo'n 2 procent van een gemiddelde database waar ik mee werk is toegankelijk voor klanten. Hoe zit dit bij jullie?

daar gaat het niet om, het gaat meer om dat de requirements kunnen veranderen na een bepaalde tijd, en dan is het niet handig als je alle software die gebruik maakt van die database moet gaan aanpassen omdat je destijds een verkeerde keuze hebt gemaakt.

De opmerkingen over het niet kunnen aanpassen van PK's zijn denk ik ook gebaseerd op het klant/gebruikers perspectief. Stel je eens voor dat je een applicatie hebt die geautomatiseerd wisselkoersen inleest. De applicatie moet zowel nieuwe koersen kunnen inlezen als wijzigingen met terugwerkende kracht. Ik vind toch echt dat de tabel VALUTA_ID en DATUM als primary key moet hebben, en niet een autoincrement kolom. De natural PK maakt het updaten van backdated wijzigingen ook erg eenvoudig. Ik ben het roerend met iedereen eens dat VALUTA_ID een identifier moet zijn (EUR, USD, JPY, etc), en geen omschrijving. Of dit dan een integer is of een varchar2(3) is lood om oud ijzer wat mij betreft.....ik vind EUR overigens gemakkelijker lezen dan het getal 17.

het gaat er toch niet om of jij EUR makkelijker kan lezen dan 17? Waar het wel om gaat is dat die naamgeving "EUR" wellicht ooit kan veranderen, als je 100% zeker bent dat dit never nooit niet gaat gebeuren dan staat niets je in de weg om dat ook daadwerkelijk als (onderdeel van) PK te gebruiken.

[Janoz]

Ik heb het niet over klanten/gebruikers, ik heb het over 'de business' . Over het algemeen modeleer je in je database real life data. Hierop heb je geen enkele invloed en je enige doel is om je datamodel zo goed mogelijk te laten matchen met de werkelijkheid. Er is, behalve tijdens een oefening op school of een tutorial op internet, geen situatie waarin het datamodel niet afhankelijk is van 'de business'. Bij mij zijn alle gegevens uiteindelijk extern toegankelijk. Iets anders heeft immers gewoon geen nut.

Voor de rest is het helemaal niet de bedoeling dat mensen de database goed kunnen lezen. Mensen horen naar de views op de database te kijken via je applicatie. Een database zelf is voor de computer om naar te kijken. Ontwerpbeslissingen baseren op een argument als 'Anders is het niet goed te lezen voor een DBA-er' zijn dan ook kul.

Het voorbeeld over wisselkoersen zie ik trouwens meer als een koppeltabel met een gecombineerde PK op DATUM en VALUTA_ID, maar de laatste zou in mijn geval gewoon een integer zijn met een foreign constraint naar de valuta tabel. In die tabel kan ik vervolgens de afkorting, het teken, de uitgeschreven naam en eventueel een koppeling naar de gebieden waar deze valuta bij hoort. Dat alles natuurlijk afhankelijk van wat er precies nodig is.

[Voutloos]

Confusion schreef op maandag 18 juni 2007 @ 12:55:
[...]

Ik vind eerder genoemde tweeletterige codes eigenlijk leesbaarder. De foreign key 'VL' zegt me iets; '14' zegt me niets. Wat betreft queries en data definities maakt het niet uit, als de velden dezelfde, fatsoenlijke, namen hebben. Dit gaat natuurlijk alleen op voor gevallen waarin je dat soort codes hebt; je moet ze niet gaan verzinnen.

Als je van de elementen van een kleine statische set de afko's uit je hoofd leert, prima. Maar bij het gros vd tabellen kom je niet zo ver.
Let ook op dat je nu kijkt naar de extensie van de database terwijl de intensie al duidelijk mag zijn. Eamelink heeft het over de intensie.

[Confusion]

Janoz schreef op maandag 18 juni 2007 @ 13:10:
Voor de rest is het helemaal niet de bedoeling dat mensen de database goed kunnen lezen.
[..]
Ontwerpbeslissingen baseren op een argument als 'Anders is het niet goed te lezen voor een DBA-er' zijn dan ook kul.

Het is geen belangrijke overweging, maar niettemin een overweging. Een leesbare database vergemakkelijkt bijvoorbeeld het vinden van de onvermijdelijke bugs. Je kan op dezelfde manier beargumenteren dat velden geen leesbare namen hoeven te hebben. Natuurlijk mag dat argument de beslissing nooit domineren, maar als er weinig argumenten in het spel zijn (een foreign key op een veld van 2 characters of op een 8bit int maakt zo weinig uit qua performance dat het nog minder als argument telt en de kans dat de VS een extra staat eenzelfde naam geven is ook verwaarloosbaar), dan kan het de doorslag geven.

[ Voor 4% gewijzigd door Confusion op 18-06-2007 13:33 ]

[Janoz]

Confusion schreef op maandag 18 juni 2007 @ 13:30:
Je kan op dezelfde manier beargumenteren dat velden geen leesbare namen hoeven te hebben.

Je kolom een rare naam geven zorgt er niet voor dat je DB efficienter werkt. Het verschil is dat het voor de computer niet uit maakt of je je kolom COL1231 of AfdelingsNaam noemt. Je kunt in dat geval dus rustig terugvallen naar wat voor een gebruiker handiger is. Vandaar dat die vergelijking niet helemaal opgaat .

Het is natuurlijk wel zo dat het door jou aangedragen voorbeeld heel erg op de grens zit, waardoor de keuze inderdaad een stuk minder triviaal is.

[ Voor 12% gewijzigd door Janoz op 18-06-2007 13:38 ]

[Confusion]

Janoz schreef op maandag 18 juni 2007 @ 13:36:
Je kolom een rare naam geven zorgt er niet voor dat je DB efficienter werkt. Het verschil is dat het voor de computer niet uit maakt of je je kolom COL1231 of AfdelingsNaam noemt.

Ik schreef dat vanuit het idee dat het nog net een ietsiepietsie efficienter is om tabellen en kolommen kortere namen te geven. Dat is ook niet helemaal eerlijk want dat is ordes van grootte minder belangrijk dan een PK char(2) of unsigned smallint maken, maargoed, op een randgeval tellen alle beetjes

[ Voor 5% gewijzigd door Confusion op 18-06-2007 13:50 ]

[Voutloos]

Over de lengte van kolomnaam moet je gewoon niet eens na willen denken in de context van optimalisaties. Het tikken van jouw post kost al meer tijd dan alle DB's ter wereld ooit bespaard hadden kunnen hebben.

En zoals gezegd bij een naam als `AfdelingsNaam` is de intensie dus duidelijker dan `COLxyz`. Kolom- en variabelenamen zijn er voor het gemak van de programmeur.

[ Voor 9% gewijzigd door Voutloos op 18-06-2007 13:55 ]

[GarBaGe]

Tja, als je leesbaarheid / onderhoudsbaarheid versus performance wilt afwegen, dan zijn we snel klaar. Leesbaarheid en onderhoudbaarheid boven alles. Zeker voor tabelnamen en kolomnamen.

Ik gebruik praktisch altijd een primary key, met als hele hoge uitzondering (maar ook niet altijd): een koppeltabel. Deze heeft doorgaans als primary key de samengestelde key van de 2 foreign keys.
De naam van een koppeltabel, daarvoor gebruik ik doorgaans de samengestelde naam van de 2 tabellen die gekoppeld worden. Makkelijk en duidelijk.

Ik dacht ook ooit eens slim te zijn en een primary key te "bezuinigen". Maar 2 jaar later moest ie er toch in, omdat door gewijzigde eisen aan het systeem ineens dubbele konden bestaan. Dat doe ik dus nooit meer...
Slim zijn, is doorgaans niet zo slim. En je bespaard praktisch niets kwa performance of opslag.

[KabouterSuper]

Erkens schreef op maandag 18 juni 2007 @ 13:03:
[...]

geen klanten/gebruikers -> geen software -> geen database

haha....ik bedoel dat er klanten zijn die met hun tengels aan de data zitten. Natuurlijk wel klanten die betalen.

Erkens schreef op maandag 18 juni 2007 @ 13:03:
het gaat er toch niet om of jij EUR makkelijker kan lezen dan 17? Waar het wel om gaat is dat die naamgeving "EUR" wellicht ooit kan veranderen, als je 100% zeker bent dat dit never nooit niet gaat gebeuren dan staat niets je in de weg om dat ook daadwerkelijk als (onderdeel van) PK te gebruiken.

Het gaat er inderdaad helemaal niet om dat je EUR gemakkelijker kunt lezen. In principe hoeft de eindgebruiker de database niet te zien. Maar het is wel een stuk duidelijker dan een getalletje. En inderdaad, ik ben zeker dat het nooit gaat veranderen, want in dit geval is het een ISO-code, en die zijn vast. Beter nog, ik ben blij dat mijn applicatie de standaardcodes volgt in plaats van een eigen nummering aan te maken.

@Janoz.... 98% van mijn databases is koppelingstabel, en maar 2% is referentietabel (=id linken aan omschrijving). Ik zou voor geen goud mijn koppelingstabellen (met meerdere PK's) willen aanpassen naar een autoincrement PK met unique constraints....zelfs niet als ik de applicatie vanaf scratch zou opbouwen. De keuze om mijn identifiers in de referentietabellen als varchar2 en niet als integer te definieren is de volgende: in de gevallen dat de marginaal tragere joins geen probleem zijn, is de leesbaarheid namelijk doorslaggevend (en het feit dat Oracle meer onderhoud vergt om autoincrements voor elkaar te krijgen).

[Janoz]

@KabouterSuper: Wel ff goed lezen he ;):

Janoz schreef op maandag 18 juni 2007 @ 10:57:
... Ook voor gecombineerde PK's is maar 1 uitzondering, en dat is voor koppeltabellen....

Verder, je hebt nooit 100% zekerheid dat domein data onveranderlijk is. Je bent immers nog steeds afhankelijk van externe factoren, ondanks dat het een ISO standaard is. Een paar jaar terug zijn er nog flink wat wijzigingen geweest op het monetaire vlak.

Verder begrijp ik het probleem niet zo met het aanmaken van een trigger en een sequence. Daarvoor kun je rustig een templateje aanmaken. Daarnaast, als bepaalde lijstjes toch al bijna onveranderlijk zijn, dan is die PK ook wel handmatig toe te voegen lijkt me.

haha....ik bedoel dat er klanten zijn die met hun tengels aan de data zitten. Natuurlijk wel klanten die betalen.

Klanten hoeven helemaal niet met hun tengels aan de data te zitten om invloed op het datamodel uit te oefenen. Sterker nog, de grootste impact op je datamodel heeft helemaal niks te maken met of je klanten er wel of niet bij kunnen.

[ Voor 19% gewijzigd door Janoz op 18-06-2007 14:47 ]

[Anoniem: 49627]

Janoz schreef op maandag 18 juni 2007 @ 14:45:
Verder begrijp ik het probleem niet zo met het aanmaken van een trigger en een sequence. Daarvoor kun je rustig een templateje aanmaken. Daarnaast, als bepaalde lijstjes toch al bijna onveranderlijk zijn, dan is die PK ook wel handmatig toe te voegen lijkt me.

Precies, en niets weerhoudt je er van om de sequence te benoemen in de insert query (seq.nextval). Dan heb je de hele trigger niet eens nodig.

[KabouterSuper]

@Janoz:
Ik probeerde je niet aan te vallen....volgens mij zijn we het met elkaar eens op het gebied van de koppelingstabellen ;-)

Ok ok...het aanmaken en onderhouden van een trigger is niet zo problematisch. Een sequence is al wat lastiger, omdat deze niet meegenomen wordt bij het importeren van een dump in een andere database user als deze bestaat. Zo kan je sequence plotseling lager zijn dan je id's in je tabel. En dit is het laatste waar je op zit te wachten. De autoincrement van MySQL heeft dit probleem gelukkig niet.

Wat betreft je laatste opmerking...vind je het erg als ik je een purist noem? Ik heb liever een compleet transparante database dan eentje die gemaskeerd wordt met interne nummeringen. Soms heeft dat voordelen, en soms heeft dat nadelen. Mijn klanten zijn superblij dat hun database open en leesbaar is. En dat weegt op tegen een systeem wat het tot 2020 foutloos doet maar waarvan de koppelingstabellen zwaar gecodeerd niet zo leesbaar zijn. En klanten snappen best dat een veranderende wereld soms betekent dat de software meeverandert.

@Mark Platvoet: het is een slechte gewoonte om een sequence mee te geven in een insert statement als je applicatie niet de enige tool is om data te inserten. De trigger zorgt ervoor dat het altijd werkt, of je nou via de applicatie, sql-plus, toad of sql-loader data toevoegt.

[ Voor 12% gewijzigd door KabouterSuper op 18-06-2007 15:31 ]

[Anoniem: 49627]

KabouterSuper schreef op maandag 18 juni 2007 @ 15:10:
@Mark Platvoet: het is een slechte gewoonte om een sequence mee te geven in een insert statement als je applicatie niet de enige tool is om data te inserten. De trigger zorgt ervoor dat het altijd werkt, of je nou via de applicatie, sql-plus, toad of sql-loader data toevoegt.

Het is geen slechte gewoonte, het is een keuze / een voorwaarde die je stelt. Je creeert zelf al een voorwaarde.

[KabouterSuper]

Er staat "het is een slechte gewoonte als..." en niet "het is een slechte gewoonte, omdat...". Het is inderdaad een extra premisse, maar niet een onwaarschijnlijke.

[whoami]

Erkens schreef op maandag 18 juni 2007 @ 11:09:
[...]

Omdat een varchar geen fixed size heeft misschien?

Dat is niet noodzakelijk de reden.
Een INT is bv 4 bytes. Een VARCHAR(10) kan 10 bytes zijn. Dat wil zeggen dat je - in het geval van een index op VARCHAR(10) - minder 'keys' per 'node' hebt, wat dus ook weer wil zeggen dat er meer nodes moeten geinspecteerd worden bij het zoeken.

Stel dat iedere 'leaf'/'node' van je index uit max. 40 bytes kan bestaan.
Als je dan een tabel hebt, met 100 records, dan heb je in het geval van een index op een INT 10 leafs (10 verwijzingen per leaf; 100 records), en in het geval van een index op een VARCHAR(10) heb je in 't slechtste geval 4 verwijzingen per leaf, en dus 25 leafs nodig.
Dat wil dus zeggen dat je bij het zoeken in geval 1 minder leafs / nodes moet traversen om je doel te bereiken.

[RobIII]

"Once a user wants to know a primary key your application is in deep shit" - Joe Celko

Ik ben het eens met de mede-mods hier; in pricipe heeft een user (of devver for that matter) geen fluit te maken met de PK's. Ook al leest het nog zo makkelijk (tijdens devven, debuggen etc.) dan nog is dat geen excuus om daarom je DB maar daar op aan te passen. Een korte code (NL of EUR en dat soort zaken) kunnen handig zijn, maar je bent uiteindelijk nooit 100% zeker van het 'vaststaan' van die code; ISO of niet. En schaffen we straks de code NL af omdat we voortaan "Holland" heten dan is het toch wel heel fijn om geen NL in je DB te hebben staan overal, maar gewoon ID 31

[ Voor 91% gewijzigd door RobIII op 18-06-2007 16:28 ]

[Anoniem: 49627]

RobIII schreef op maandag 18 juni 2007 @ 16:25:
En schaffen we straks de code NL af omdat we voortaan "Holland" heten dan is het toch wel heel fijn om geen NL in je DB te hebben staan overal, maar gewoon ID 31

offtopic:
Volledig offtopic: Holland wordt maar al te vaak misbruikt voor Nederland. Holland (wat staat voor houtland) bevat enkel de provincies noord-holland, zuid-holland en utrecht.

Ik ga door voor een triviant!

[RobIII]

Anoniem: 49627 schreef op maandag 18 juni 2007 @ 16:41:
[...]

offtopic:
Volledig offtopic: Holland wordt maar al te vaak misbruikt voor Nederland. Holland (wat staat voor houtland) bevat enkel de provincies noord-holland, zuid-holland en utrecht.

Ik ga door voor een triviant!

offtopic:
En wat zou ons dan letten om 'Holland' te kiezen i.p.v. 'Nederland'? Of "FooBarLand'? Of 'RobIII-Land'? All bow! Wat ik bedoel is dat, ook al betekent Holland 'houtland' en horen er eig'k maar 3 provincies in, dan nog kunnen we Nederland hernoemen naar Holland.
Ik begrijp je punt, maar daar ging het dus nu niet om Ik probeerde ook een punt te maken

[ Voor 13% gewijzigd door RobIII op 18-06-2007 16:46 ]

[KabouterSuper]

Mmmmm, 31 heeft ook een betekenis stiekem. Als de internationale inbelcode van NL (o sorry, ik bedoel 31 natuurlijk) verandert naar 0071, ben je bijna even zuur.

[Anoniem: 49627]

RobIII schreef op maandag 18 juni 2007 @ 16:45:

offtopic:
Ik begrijp je punt, maar daar ging het dus nu niet om Ik probeerde ook een punt te maken

offtopic:
Ik begreep je punt uiteraard ook wel, en daarin heb je wat mij betreft gewoon gelijk

[RobIII]

KabouterSuper schreef op maandag 18 juni 2007 @ 16:49:
Mmmmm, 31 heeft ook een betekenis stiekem. Als de internationale inbelcode van NL (o sorry, ik bedoel 31 natuurlijk) verandert naar 0071, ben je bijna even zuur.

En daarom koos ik bewust 31. Kijken of iemand het begreep. Jij dus nog niet Die 31 had net zo goed 28661290 kunnen zijn Het gaat er juist om dat een ID betekenisloos moet zijn. Dat jij in die 31 een landcode ziet...tja.

[ Voor 11% gewijzigd door RobIII op 18-06-2007 17:01 ]

[D4Skunk]

Ik heb hier al heel wat argumenten zien passeren maar HET argument voor mij is dit :
Consistentie & transparantie.

Ik vindt het gewoon veel eenvoudiger te devven als mijn PK altijd ID noemt en autoincremental is.
Wanneer je dan spreekt over enkele honderden tabellen heb je dan toch tenminste niet te maken met zaken zoals
-"hoe heet die pk kolom nou ook weer van die tabel"
-"was de PK nou 'ID' of 'naam' van tabel FOO"

De reden dat dit vroeger nog anders aangeleerd werd, heeft imho vooral te maken met performance etc, maar dit is nu in 99,99% v/d gevallen ABSOLUUT geen issue meer...

IMHO is elke extra vorm van consistentie die minimale impact heeft op performantie/onderhoud een must in een DB.

Als je geen surrogate gebruikt, gebruik dan tenminste overal hetzelfde type/veldnaam/...

PS : over het al dan niet gebruiken van varchar of int : lees eens wat lectuur over hoe indexen werken, en je zal direct begrijpen hoe klein de impact hiervan is...

[ Voor 9% gewijzigd door D4Skunk op 18-06-2007 17:05 ]

[KabouterSuper]

oooh, je hebt me hoor....ik ben erin getrapt.... maar even serieus, ik heb even de Oracle dictionary bekeken, die werken zo te zien ook met integers. Ze hebben wel views om gemakkelijker te kunnen querien. Dus Oracle is zowel consistent als pragmatisch. Zullen wij dat dan ook maar zijn?

[MicroWhale]

Waarom geen namen:
1. Gegarandeerde uniciteit: een automatisch gegenereerd nummer van een PK is "altijd uniek",
2. Consistentie: Bij namen moet de FK van deze PK in de hele database aangepast worden,
3. Snelheid: Op elke PK komt een index. Numerieke indexen zijn vele malen sneller!!!

Wat men helaas vaak vergeet is om bij een tabel met autonumerieke PK de andere (gecombineerde) unieke velden in te voeren.

Waarom geen autonumerieke nummers:
- Met een DBmanagement-tool (of slechte software) kan dat "altijd uniek" om zeep geholpen worden,
- Migratie of upgrade van database wordt bemoeilijkt,
- De PK heeft geen informatieve waarde buiten zijn verwijzingsfunctie,

[Gé Brander]

MrWilliams schreef op donderdag 21 juni 2007 @ 14:00:
Waarom geen namen:
1. Gegarandeerde uniciteit: een automatisch gegenereerd nummer van een PK is "altijd uniek",
2. Consistentie: Bij namen moet de FK van deze PK in de hele database aangepast worden,
3. Snelheid: Op elke PK komt een index. Numerieke indexen zijn vele malen sneller!!!

Eens.

Wat men helaas vaak vergeet is om bij een tabel met autonumerieke PK de andere (gecombineerde) unieke velden in te voeren.

Ik begrijp even niet helemaal wat je hiermee bedoelt. Kan je dat verklaren?

Waarom geen autonumerieke nummers:
- Met een DBmanagement-tool (of slechte software) kan dat "altijd uniek" om zeep geholpen worden,
- Migratie of upgrade van database wordt bemoeilijkt,
- De PK heeft geen informatieve waarde buiten zijn verwijzingsfunctie,

Die eerste en laatste begrijp ik, echter waarom die middelste dan?

[RobIII]

MrWilliams schreef op donderdag 21 juni 2007 @ 14:00:
- Met een DBmanagement-tool (of slechte software) kan dat "altijd uniek" om zeep geholpen worden,

Ik begrijp deze niet helemaal; als je DB die nummers uitdeelt dan kan je client-software hoog/laag springen maar zie ik niet hoe het dan om zeep geholpen kan worden.

MrWilliams schreef op donderdag 21 juni 2007 @ 14:00:
- De PK heeft geen informatieve waarde buiten zijn verwijzingsfunctie,

Moet dat dan?

[Erkens]

MrWilliams schreef op donderdag 21 juni 2007 @ 14:00:
Waarom geen autonumerieke nummers:
- Met een DBmanagement-tool (of slechte software) kan dat "altijd uniek" om zeep geholpen worden,

tja, als dat een reden is om het niet te doen vraag ik me af of met dergelijke tools/software de uniekheid van een non-autonumerieke PK wel gegarandeerd blijft (Maar aan de andere kant kan het "altijd uniek" als het goed is nooit gesloopt worden omdat het toch uniek moet blijven voor de database zelf, je kan niet eens een dubbele waarde invoeren, je krijgt dan een error.)
nee dus, dus dit is niet echt een goed argument om er wel of niet voor te kiezen.

- Migratie of upgrade van database wordt bemoeilijkt,

ook hier zie ik weinig problemen, bij een upgrade al helemaal niet

- De PK heeft geen informatieve waarde buiten zijn verwijzingsfunctie,

en dat is imo juist een enorm grote informatieve waarde

[Hydra]

Anoniem: 146163 schreef op maandag 18 juni 2007 @ 10:44:
Je "zou" 't volgens mij ook kunnen zien vanuit performance oogpunt voor queries?

Dat is volgens mij de voornaamste reden om niet een 'naam' te gebruiken. In het geval van een forum of webshop bijvoorbeeld heb je toch altijd een unieke 'naam' (nickname of e-mail) die prima als PK gebruikt zou kunnen worden. Het voornaamste voordeel van het gebruik van een numeriek ID is gewoon performance, een index gebaseerd op strings zal over het algemeen een stuk groter zijn. Als je d.m.v. NIAM een analyse uitvoert zal een 'persoon' sowieso niet snel een 'ID' krijgen, aangezien dat geen natuurlijk attribuut is.

[.oisyn]

Niet te vergeten dat je bij je FKs ook allemaal strings loopt op te slaan wat ook weer extra ruimte inneemt.

[whoami]

Niet alleen qua performance; stel nu eens dat je je e-mail adres wijzigt, of je nickname wijzigt.

Lekker hoor ... mag je al je foreign keys gaan updaten.
Een Primary Key is voor mij enkel een 'administratief gegeven' in de DB, en is enkel nodig voor administatieve doeleinden in je DB. Een primary key zou geen andere betekenis mogen hebben, en zou dus geen betekenis mogen hebben in het business-domein.
(Wat als bepaalde business-regels wijzigen die dan plots impact hebben op de keuze van je PK's ? ), een de waarde van een primary key zou nooit mogen wijzigen.
Daarom kies ik voor surrogate PK's.

Maar ik denk dat die discussie hier wel al eens eerder gevoerd is.

[Gomez12]

Btw, ik zie wel in dat een amerikaanse staat als pk kan functioneren, maar hoe maak je dan de rest van dbase model? Want als je ergens anders wel autogegenereerde pk's hebt dan zou je van mij zo ongeveer een rotschop krijgen omdat het niet consistent is.

Als jij het voor elkaar krijgt om bij elke tabel een 100% unieke kolom te vinden ( dus nu en in 2020 uniek ) die niet te groot is , dus geen varchar(50) etc. , en die ook een zinnige representatie is dan zou je van mij best mogen kiezen voor niet autogegenereerde pk's. Maar ja ik ben nog nooit een zinnige applicatie tegengekomen die dit 100% kan garanderen dus daarom zeg ik gewoon altijd autogegeneerde pk's gebruiken vanwege consistentie

[RobIII]

Gomez12 schreef op vrijdag 22 juni 2007 @ 23:17:
Btw, ik zie wel in dat een amerikaanse staat als pk kan functioneren, maar hoe maak je dan de rest van dbase model?

Totdat ze besluiten 2 staten te 'mergen' of een staat in 2 op te splitsen. Heb jij dat in de hand? Nee, dus maak je lekker een surrogate key

[Gomez12]

RobIII schreef op zaterdag 23 juni 2007 @ 02:48:
[...]

Totdat ze besluiten 2 staten te 'mergen' of een staat in 2 op te splitsen. Heb jij dat in de hand? Nee, dus maak je lekker een surrogate key

Lees ook even de rest van mij reactie, omdat ik in 100% van de gevallen toch al een andere tabel zou hebben waar ik dit geintje niet toe zou kunnen passen zou ik vanwege consistentie toch wel een surrogate key gebruiken.

[MicroWhale]

c70070540 schreef op donderdag 21 juni 2007 @ 14:31:
[...]
Eens.
[...]
Ik begrijp even niet helemaal wat je hiermee bedoelt. Kan je dat verklaren?

Ik verzin maar ff iets:
Een naamtabel heeft een PK die ID heet en autonumeriek is, echter de combinatie van Voornaam, Tussenvoegsel, Achternaam, E-mailAdres moet ook uniek zijn.

Dat wordt vaak vergeten.

[...]
Die eerste en laatste begrijp ik, echter waarom die middelste dan?

Bij een migratie van autonumerieke PK moet je goed opletten dat al je foreign keys (welke ook autonumerieke PKs hebben) bij het opvoeren niet een nieuwe, andere waarde PK waarde krijgen dan de FK in de mastertable. Of de FK moet opnieuw ingevuld worden natuurlijk.

[MicroWhale]

RobIII schreef op donderdag 21 juni 2007 @ 14:39:
[...]

Ik begrijp deze niet helemaal; als je DB die nummers uitdeelt dan kan je client-software hoog/laag springen maar zie ik niet hoe het dan om zeep geholpen kan worden.

In een DBMS management tool kun je de autonummering "resetten" of op een willekeurig ander getal zetten. Dit brengt op z'n zachtst gezegd risico's met zich mee.

[...]
Moet dat dan?

Nee.

[RobIII]

MrWilliams schreef op dinsdag 26 juni 2007 @ 13:35:
[...]

In een DBMS management tool kun je de autonummering "resetten" of op een willekeurig ander getal zetten. Dit brengt op z'n zachtst gezegd risico's met zich mee.

Een geresette autonummering kan geen kwaad (althans: ik zou niet weten waarom) zolang ID's niet opnieuw gebruikt worden. Dat doet een beetje DBMS niet, en dan nog zorgt de Unique constraint er dan voor de het niet KAN. En als je 'm op een willekeurig ander getal zet krijgen nieuwe records gewoon dat andere "willekeurige" getal; omdat het ID echter geen betekenis heeft boeit het niet of het 1213896 is of 21871324 of 89. Ik zie dus totaal 0 risico in wat jij beweert.

Daarnaast kun je autonummering ook zonder DBMS management tools resetten (TSQL bijv.) en dien je gewoon te zorgen dat de 'gebruikers' dat soort zaken niet eens mogen. Wat jij doet is dus symptoombestrijding van een symptoom dat in de eerste plaats niet eens had mogen bestaan

[Janoz]

MrWilliams schreef op dinsdag 26 juni 2007 @ 13:35:
In een DBMS management tool kun je de autonummering "resetten" of op een willekeurig ander getal zetten. Dit brengt op z'n zachtst gezegd risico's met zich mee.

Tja, een autonummerveld dat anders gezet is zorgt er niet voor dat je data inconsistent raakt. Je krijgt gewoon geen gegevens de database meer in. Ik zie fouten met betekenis volle PK eerder voorkomen. Daarvoor gelden dezelfde dba fuckup mogelijkheden, maar betekenis volle PK hebben daarnaast ook nog de invloeden van buitenaf.

[.oisyn]

MrWilliams schreef op dinsdag 26 juni 2007 @ 13:33:

Ik verzin maar ff iets:
Een naamtabel heeft een PK die ID heet en autonumeriek is, echter de combinatie van Voornaam, Tussenvoegsel, Achternaam, E-mailAdres moet ook uniek zijn.

Dat wordt vaak vergeten.

Het e-mailadres moet uniek zijn, maar de naam hoeft niet uniek te zijn.

[Erkens]

.oisyn schreef op dinsdag 26 juni 2007 @ 14:06:
[...]

Het e-mailadres moet uniek zijn, maar de naam hoeft niet uniek te zijn.

Dat ligt natuurlijk aan de requirements Vaak is het wel zo, maar hoeft niet.

[.oisyn]

I know, maar ik bedoelde meer dat de requirements zoals MrWilliams die beschrijft een beetje vaag zijn. Hij zegt dat de combinatie naam+e-mailadres uniek moet zijn, maar da's natuurlijk onzin. Dan mogen Jan Jansen en Kees Dirksen hetzelfde e-mailadres hebben. Als dat zo is, waarom mag pa Jan Jansen dan niet op hetzelfde e-mailadres zitten als zoon Jan Jansen?

[Erkens]

.oisyn schreef op dinsdag 26 juni 2007 @ 14:43:
I know, maar ik bedoelde meer dat de requirements zoals MrWilliams die beschrijft een beetje vaag zijn. Hij zegt dat de combinatie naam+e-mailadres uniek moet zijn, maar da's natuurlijk onzin. Dan mogen Jan Jansen en Kees Dirksen hetzelfde e-mailadres hebben. Als dat zo is, waarom mag pa Jan Jansen dan niet op hetzelfde e-mailadres zitten als zoon Jan Jansen?

Tja, als dat zijn requirement is dan klopt het toch: "mensen met dezelfde naam mogen niet hetzelfde e-mail adres hebben, maar e-mail adressen mogen wel door mensen met andere namen gedeeld worden"

/offtopic

[.oisyn]

Ja, als dát een requirement is, moet je dat vooral doen. Kun je ook een real-life scenario noemen voor een dergelijke requirement?

[Erkens]

.oisyn schreef op dinsdag 26 juni 2007 @ 14:57:
Ja, als dát een requirement is, moet je dat vooral doen. Kun je ook een real-life scenario noemen voor een dergelijke requirement?

nee, ik ben niet een wazige opdrachtgever die dit soort dingen kan bedenken
uiteraard zal je op dit soort requirements moeten doorvragen om duidelijkheid te hebben voor beide partijen, want waarschijnlijk zal die opdrachtgever dan ook wel inzien dat het vrij onzinnig is wat hij wil (wat het bijna altijd wel is )

[RobIII]

.oisyn schreef op dinsdag 26 juni 2007 @ 14:57:
Ja, als dát een requirement is, moet je dat vooral doen. Kun je ook een real-life scenario noemen voor een dergelijke requirement?

Rob Janssen [e-mail]
Piet Janssen [e-mail]
Oisyn Janssen [e-mail]



Neemt niet weg dat ik het met je eens ben; de constraint is, zacht gezegd, een beetje raar gekozen

Erkens schreef op dinsdag 26 juni 2007 @ 15:33:
[...]

Je vergeet die andere "Rob Janssen" die ook bij somecompany werkt, die kan niet meedoen met deze constaint

Joh

[ Voor 20% gewijzigd door RobIII op 26-06-2007 16:09 ]

[Erkens]

RobIII schreef op dinsdag 26 juni 2007 @ 15:31:
[...]

Rob Janssen [e-mail]
Piet Janssen [e-mail]
Oisyn Janssen [e-mail]



Neemt niet weg dat ik het met je eens ben; de constraint is, zacht gezegd, een beetje raar gekozen

Je vergeet die andere "Rob Janssen" die ook bij somecompany werkt, die kan niet meedoen met deze constaint

[SPee]

Sinds enige tijd hebben we een applicatie in beheer waarachter een database hangt met namen als PK.

Dat is echt lastig. Een product van een productgroep heeft een gecombineerde PK nodig. Wil je dit product in een andere tabel gebruiken, heb je al een extra kolom in je tabel nodig.
Ook leuk als ze een 1-op-veel relatie hebben met een PK van 4 kolommen
Had dan bij die ene een autoid aangemaakt, dan had je bij de andere tabellen maar 1 kolom nodig.

Ook leuk (andere applicatie) is het "voorbereid op alles" zijn. Dat datamodel is zo generiek opgezet, terwijl maar een kleine vaste set wordt gebruikt, dat het daardoor traag is geworden. Om dat te veranderen is zo'n grote wijziging nodig met grote impact, die de klant niet wil/gaat betalen.
Ook werken met de GUID (unieke ID's) als PK, terwijl een (simpele) index al voldoende is, helpt niet veel. Zekere niet omdat ze als VARCHAR worden opgeslagen. Op enkele plekken was het wel goed geweest, maar niet voor elke PK. Ook niet als je 'eigen' waardes ertussen gaat zetten.

Dus je moet echt goed nadenken over die PK/naam.

[REDFISH]

Als je nu eens netjes voornaam en achternaam scheidde dan had je de hele problematiek al niet. Een naam als geheel opnemen is IMO geen mooi databaseontwerp, alleen al omdat je gekke fratsen moet gaan uithalen om iets als: 'geachte heer Janssen' te kunnen schrijven in een automatische brief/email noem maar op.

Wat vinden jullie de beste manier om Foreign Keys te noemen? Ik zit hier vaak mee in de knoei.

[user109731]

REDFISH schreef op dinsdag 26 juni 2007 @ 18:21:
Als je nu eens netjes voornaam en achternaam scheidde dan had je de hele problematiek al niet. Een naam als geheel opnemen is IMO geen mooi databaseontwerp, alleen al omdat je gekke fratsen moet gaan uithalen om iets als: 'geachte heer Janssen' te kunnen schrijven in een automatische brief/email noem maar op.

Dat ligt aan de situatie imho, soms wil je de gebruiker niet opzadelen met twee velden maar volstaat een 'naam' veld. Bovendien: je zit dan weer met het voorvoegsel, weer een ander veld?

Wat vinden jullie de beste manier om Foreign Keys te noemen? Ik zit hier vaak mee in de knoei.

Het moet iig duidelijk zijn om welke fk het gaat, ik noem ze daarom zo: fk_posts_users, waarbij het in 1 keer duidelijk is dat de fk in posts verwijst naar de key in users...

[.oisyn]

waarom zou je een kolom prefixen met de tabelnaam? Als je je queries duidelijk wilt opschrijven kan dat ook wel met tabelnaam.kolomnaam ipv gewoon kolomnaam. Naarnaast, waarom noem je 'm users? Het gaat toch maar om 1 user? Of heb je het daar over de usertabel?

Mijn FK heet gewoon user_id in de table posts. Hieruit blijkt vrij duidelijk dat het een FK is (want _id, al m'n PKs zijn gewoon IDs) en die wijst naar een user

[user109731]

.oisyn schreef op dinsdag 26 juni 2007 @ 20:40:
waarom zou je een kolom prefixen met de tabelnaam?

Het is geen kolom; het is een constraint die een 'kolom koppelt' toch? Ik dacht dat de vraag op de naam van de FK sloeg. Nu ik het zo zie vat jij de vraag misschien beter op, en dan heb je gelijk natuurlijk. Mijn kolom heet idd ook user_id...

Als je je queries duidelijk wilt opschrijven kan dat ook wel met tabelnaam.kolomnaam ipv gewoon kolomnaam. Naarnaast, waarom noem je 'm users? Het gaat toch maar om 1 user? Of heb je het daar over de usertabel?

Jep

[ Voor 15% gewijzigd door user109731 op 26-06-2007 20:51 ]

[charlie]

Wat ik hier in de discussien nog zien heb passeren zijn de GUID's, ofte de Generic Unique Identifiers...
Zeker als je ooit off-line wil werken en nadien synchroniseren is een gewone incremental primary key niet meer voldoende, een andere gebruiker kan immers inmiddels al hetzelfde Id gemaakt hebben... In tegenstelling tot een gewone integer zou deze GUID altijd uniek moeten zijn, en kan je nadien extra records eenvoudig mergen met een bestaande database.

[.oisyn]

JanDM schreef op dinsdag 26 juni 2007 @ 20:46:
[...]

Het is geen kolom; het is een constraint die een 'kolom koppelt' toch? Ik dacht dat de vraag op de naam van de FK sloeg.

Is een FK geen kolom dan (of meerdere natuurlijk)?

[user109731]

.oisyn schreef op dinsdag 26 juni 2007 @ 20:57:
[...]

Is een FK geen kolom dan (of meerdere natuurlijk)?

Ik zie het meer als een constraint die je 'op een kolom legt'. Zo'n constraint kan ook een naam hebben, zodat je bijvoorbeeld zoiets kunt doen:

SQL:

ADD CONSTRAINT fk FOREIGN KEY posts (user_id) REFERENCES users (id)

ALTER TABLE posts DROP FOREIGN KEY fk;

Ik had het over de 'fk' in dit voorbeeld, jij hebt het over 'user_id'

[.oisyn]

Ah natuurlijk op die fiets, dan interpreteerde ik je verkeerd

[Gomez12]

charlie schreef op dinsdag 26 juni 2007 @ 20:56:
Wat ik hier in de discussien nog zien heb passeren zijn de GUID's, ofte de Generic Unique Identifiers...
Zeker als je ooit off-line wil werken en nadien synchroniseren is een gewone incremental primary key niet meer voldoende, een andere gebruiker kan immers inmiddels al hetzelfde Id gemaakt hebben... In tegenstelling tot een gewone integer zou deze GUID altijd uniek moeten zijn, en kan je nadien extra records eenvoudig mergen met een bestaande database.

Ach tja hangt ervanaf wat je bedoeld met offline gebruiken, meeste offline gebruik wat ik moet maken gaat toch alleen maar over een mini-versie waarbij de wijzigingen altijd teruggevoerd moeten worden naar de hoofdappen dan kies ik gewoon of voor een tijdelijk bestand waar de wijzigingen in terecht moeten komen of voor een dusdanig hoge GUID in de offline app dat het niet conflicteert (vb main app werkt met guid rond de 10.000, 1000 mutaties per dag, dan gooi ik de offline guid's op 1.000.000 ) offline guid's die kunnen conflicteren maakt me nooit iets uit, omdat ik altijd toch werk met een "conversie" naar de hoofdapp. Dus offline app met guids 1.000.000 t/m 1.000.099 worden na inlezen in hoofdapp toch guid's 10.000 tot 10.099.

Een offline app is bij ons toch altijd maar een beperkte versie van de mainapp die een voorgedifinieerde output heeft, 10 mensen die offline een klant kunnen wijzigen, dan maak ik mij niet meer druk over guid maar eerder over race-condities en wie heeft er gelijk

[Gé Brander]

En GUID's zijn draken voor wat betreft indexen. Snel zoeken op basis van een PK-FK relatie met een GUID is niet grappig voor een database. Ze zijn niet opvolgend, dus snel het juiste record er bij zoeken is er niet bij. Er volgt een scan voor de hele tabel, terwijl dat bij een integer die automatisch oploopt niet het geval is.

[Gomez12]

c70070540 schreef op dinsdag 26 juni 2007 @ 23:57:
En GUID's zijn draken voor wat betreft indexen. Snel zoeken op basis van een PK-FK relatie met een GUID is niet grappig voor een database. Ze zijn niet opvolgend, dus snel het juiste record er bij zoeken is er niet bij. Er volgt een scan voor de hele tabel, terwijl dat bij een integer die automatisch oploopt niet het geval is.

??? 1e keer dat ik dat hoor, een integer waarde die niet 100% opvolgend is zou dus een draak zijn voor een index ??? Nooit iets van gemerkt.

En hoe moet het dan als ik 1 tabel heb met daarin 10.000.000 records met daaraan 10 afhankelijke tabellen en ik wil record 2 en record 5.000.000 verwijderen, met een cascaded delete naar de afhankelijke tabellen.
Moet ik daarna alle PK's opnieuw uitdelen voor 9.999.998 records en gelijk ook de FK's voor de afhankelijke tabellen?
Heeft u even...

En nee, soms is het setten van een delete flag echt niet genoeg maar moet iets gewoon echt weg uit de dbase.

Als dit serieus is is er dan ook ergens een serieuze bron van te vinden, want ik doe redelijk wat met dbases maar dit heb ik echt nog nooit gehoord en is imho ook complete onzin.

[.oisyn]

Ze zijn niet opvolgend, dus snel het juiste record er bij zoeken is er niet bij. Er volgt een scan voor de hele tabel, terwijl dat bij een integer die automatisch oploopt niet het geval is.

Sorry maar dat is dus totale onzin, verdiep je anders even in zoek-algoritmen .

[Gomez12]

c70070540 schreef op dinsdag 26 juni 2007 @ 23:57:
En GUID's zijn draken voor wat betreft indexen. Snel zoeken op basis van een PK-FK relatie met een GUID is niet grappig voor een database. Ze zijn niet opvolgend, dus snel het juiste record er bij zoeken is er niet bij. Er volgt een scan voor de hele tabel, terwijl dat bij een integer die automatisch oploopt niet het geval is.

Btw nog even een vraagje wat bij mij opkomt, als ik een tabel heb met 10 records met id's 1 t/m 10. Nu verwijder ik record 2.
Hoe verander ik dan de andere id-nrs, want

code:

update tabel set id=2 where id=3
update tabel set id=3 where id=4
update tabel set id=4 where id=5
update tabel set id=5 where id=6
update tabel set id=6 where id=7
update tabel set id=7 where id=8
update tabel set id=8 where id=9
update tabel set id=9 where id=10

zorgt wel voor een mooie aansluiting maar levert 8 draken van query's op want voordat ze klaar zijn is het geen automatisch oplopend integer...

[.oisyn]

UPDATE tabel SET id=id-1 WHERE id>2

Dit natuurlijk even compleet afgezien van het feit dat zijn statement bogus is

[ Voor 54% gewijzigd door .oisyn op 27-06-2007 00:52 ]

[Gomez12]

.oisyn schreef op woensdag 27 juni 2007 @ 00:52:
UPDATE tabel SET id=id-1 WHERE id>2

Dit natuurlijk even compleet afgezien van het feit dat zijn statement bogus is

Vind je het heel erg als ik niet even 1 picoseconde nagedacht heb voordat ik dat uitschreef?
Volgens hem is het nog steeds een draak van een query...

[curry684]

Anoniem: 49627 schreef op maandag 18 juni 2007 @ 11:10:
[...]

Ik zou je daar niet op verkijken. Het vermijden van een join kan in redelijk wat scenario's een behoorlijke performance winst opleveren. Het is echt een misconceptie dat een join geen (significante) performance impact heeft.

Dat hangt van de join en van de databaseopstelling af. Indien alle indexes goed staan is een join in een goed DBMS (MySQL met z'n idiote 1-index-per-join limit tellen we niet mee) altijd een index scan in tandem over de betrokken tabellen, en daarmee van verwaarloosbare invloed op de query. Wat dat betreft klopt de statement gewoon dat als een join wel een merkbare performancehit levert je allereerst eens goed naar je execution plans en daarna je database moet kijken.

Zelf ben ik verder een absolute surrogate-key purist, en heb ik door de jaren enkel bewijzen gezien dat dit een goed idee is, nog nooit andersom.

c70070540 schreef op dinsdag 26 juni 2007 @ 23:57:
En GUID's zijn draken voor wat betreft indexen. Snel zoeken op basis van een PK-FK relatie met een GUID is niet grappig voor een database. Ze zijn niet opvolgend, dus snel het juiste record er bij zoeken is er niet bij. Er volgt een scan voor de hele tabel, terwijl dat bij een integer die automatisch oploopt niet het geval is.

Uhm een GUID is niets anders dan een 16 byte integer die net zo goed indexeerbaar is als een willekeurige identity of auto_increment int. De enige reden dat GUID's marginaal en verwaarloosbaar trager zijn dan ints is dat er 4 keer zoveel data rondgeschoven wordt door de indexen. Het voordeel daarentegen is dat GUID's iedere neiging om ooit corrupte logica aan een PK te verbinden nog sterker de grond inboort, denk hierbij aan idiote queries die ik op dit forum wel eens langs heb zien komen als "select top 1 * from table order by table_id desc" om het nieuwst toegevoegde item te vinden.

Zoals oisyn al zegt, ga je eerst even bijlezen over hoe een DB en zoekalgoritmes werken voor je dit soort misleidende uitspraken doet

[ Voor 47% gewijzigd door curry684 op 27-06-2007 03:25 ]

[dusty]

curry684 schreef op woensdag 27 juni 2007 @ 03:20:
[...]
Zelf ben ik verder een absolute surrogate-key purist, en heb ik door de jaren enkel bewijzen gezien dat dit een goed idee is, nog nooit andersom.
[...]

Er zijn zelfs zulke surrogate-key puristen die zelfs een surrogate-key gaan maken voor een koppeltabel, uiteraard gevolgd door een contraint die aangeeft dat de combinatie van de twee keys wel uniek moet zijn