[Databases] Waarom namen gebruiken als PK?

[.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

[EfBe]

curry684 schreef op woensdag 27 juni 2007 @ 03:20:
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.

Nee dit is niet zo. GUIDs zijn nl niet sequentieel. Een PK heeft veelal een clustered index (een index die ervoor zorgt dat je values in de index volgorde fysiek zijn opgeslagen) en een insert is dan veelal een veel tragere operatie vaak.

SqlServer 2005 heeft NEWSEQUENTIALID() dat een default constraint functie is waarmee je sequentiele GUIDs kunt maken, en dat lost het probleem op.
-----
Namen als PK values zijn niet handig. Het punt is nl. dat wanneer de user via een applicatie de PK value vult en een tikfout maakt, je het haasje bent want dan moet je een PK value wijzigen, wat theoretisch niet kan (een entity met een gewijzigde pk is een andere entity, immers de PK value identificeert de rest van de attribute waarden). Het is niet altijd zo dat een surrogate key moet worden gekozen maar voor namen en datums bv, zou ik er wel absoluut voor kiezen.

En GUIDs zou ik links laten liggen tenzij je meerdere processes data laat inserten waarbij je er zeker van moet zijn dat de PK values gecreeerd buiten de DB uniek zijn BINNEN de DB.

[Gé Brander]

EfBe schreef op woensdag 27 juni 2007 @ 09:13:
[...]

Nee dit is niet zo. GUIDs zijn nl niet sequentieel. Een PK heeft veelal een clustered index (een index die ervoor zorgt dat je values in de index volgorde fysiek zijn opgeslagen) en een insert is dan veelal een veel tragere operatie vaak.

SqlServer 2005 heeft NEWSEQUENTIALID() dat een default constraint functie is waarmee je sequentiele GUIDs kunt maken, en dat lost het probleem op.

Dank.
Ik was wat kort in mijn opmerking, maar jij begrijpt wat ik bedoel.

[ Voor 36% gewijzigd door Gé Brander op 27-06-2007 09:57 ]

[Janoz]

Niet alleen kort, maar gewoon nog steeds fout. Wat EfBe verteld heeft helemaal niks met het volgende te maken:

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.

Als het opzoeken van een ID meer dan O(Log N) tijd in beslag neemt mogen de ontwikkelaars van die database engine wat mij betreft standrechtelijk afgeschoten worden.

Ook een insert van een nieuwe GUID hoeft niet veel te kosten. Ik zou niet weten waarom een GUID niet in een B+ tree opgeslagen zou kunnen worden.

[Confusion]

EfBe schreef op woensdag 27 juni 2007 @ 09:13:
Nee dit is niet zo. GUIDs zijn nl niet sequentieel. Een PK heeft veelal een clustered index (een index die ervoor zorgt dat je values in de index volgorde fysiek zijn opgeslagen) en een insert is dan veelal een veel tragere operatie vaak.

Maar c70070540 had het niet over inserts.

[joepP]

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.

Heb een keer meegemaakt dat een uniek veld (klantnummer) ineens niet meer zo uniek was door een platformuitbreiding (fusie). Het resultaat was dat ongeveer de helft van de koppeltabellen aangepast moest worden, bijna alle rapportage-queries herschreven moesten worden, plus een aanpassing aan alle dataretrieval/insertion in de hele databaselaag. Als extra bonus was de database ook nog eens behoorlijk groot, zodat de fysieke aanpassing (rebuild) ook nog flink wat tijd kost. Al deze ellende was eenvoudig te voorkomen met een simpele autoincrement PK.

Tegenwoordig voorzie ik zonder nadenken elke tabel van een autoincrement PK. Dus ook koppeltabellen. Soms moet je achteraf weer aan de gemaakte koppeling refereren vanuit een andere tabel, en dan mag je achteraf PK's gaan toevoegen, wat ook niet altijd even makkelijk gaat.

[Confusion]

joepP schreef op woensdag 27 juni 2007 @ 11:50:
[...]
Tegenwoordig voorzie ik zonder nadenken elke tabel van een autoincrement PK. Dus ook koppeltabellen. Soms moet je achteraf weer aan de gemaakte koppeling refereren vanuit een andere tabel, en dan mag je achteraf PK's gaan toevoegen, wat ook niet altijd even makkelijk gaat.

Wanneer gaat een surrogate PK toevoegen aan een koppeltabel niet makkelijk?

[EfBe]

Janoz schreef op woensdag 27 juni 2007 @ 10:24:
Niet alleen kort, maar gewoon nog steeds fout. Wat EfBe verteld heeft helemaal niks met het volgende te maken:

[...]

Als het opzoeken van een ID meer dan O(Log N) tijd in beslag neemt mogen de ontwikkelaars van die database engine wat mij betreft standrechtelijk afgeschoten worden.

Ook een insert van een nieuwe GUID hoeft niet veel te kosten. Ik zou niet weten waarom een GUID niet in een B+ tree opgeslagen zou kunnen worden.

In Sqlserver, de enige db die native GUIDs ondersteunt, is elke PK standaard een clustered index. Inserten van een GUID kost dan bijna altijd veel tijd, want de kans dat deze achteraan kan worden geplaatst wordt met de row kleiner. Dit houdt dus in dat de clustered index een insert voor zn bakkes krijgt en dat kost bijna altijd disk IO buiten de data page om, wat je echt niet wilt.

het voordeel is dan weer wel dat opzoeken van een Guid in die clustered index net zo snel is als het opzoeken van een int in de clustered index van een int PK (iets trager omdat een GUID groter is, maar niet navenant trager). Dus voor het ophalen van de row mbv de GUID is dus niets mis, het probleem zit hem in de inserts.

Heb je dus veel inserts, dan is het debiel voor een Guid als PK te kiezen, tenzij je NEWSEQUENTIALID gebruikt. Met die default nl. is elke nieuwe PK altijd groter dan de laatste in de table, en dus kan achteraan de clustered index worden geplaatst, en dus kost dat niet veel tijd.

Je kunt ook voor een non-clustered index kiezen voor de PK, maar dat is voor het opzoeken bijna altijd nog trager, omdat de clustered index je de row geeft, de normale index slechts een index (Zie BOL).

In veel database applicaties is het echt niet nodig een GUID as PK te kiezen, ik zou er dan ook (tenzij je er echt niet omheen kunt) verre van blijven.

Confusion schreef op woensdag 27 juni 2007 @ 11:05:
[...]

Maar c70070540 had het niet over inserts.

Ik reageerde ook op Curry

[ Voor 7% gewijzigd door EfBe op 27-06-2007 12:16 ]

[EfBe]

joepP schreef op woensdag 27 juni 2007 @ 11:50:
[...]

Heb een keer meegemaakt dat een uniek veld (klantnummer) ineens niet meer zo uniek was door een platformuitbreiding (fusie). Het resultaat was dat ongeveer de helft van de koppeltabellen aangepast moest worden, bijna alle rapportage-queries herschreven moesten worden, plus een aanpassing aan alle dataretrieval/insertion in de hele databaselaag. Als extra bonus was de database ook nog eens behoorlijk groot, zodat de fysieke aanpassing (rebuild) ook nog flink wat tijd kost. Al deze ellende was eenvoudig te voorkomen met een simpele autoincrement PK.

dat valt maar te bezien. Je hebt dan nog steeds bv order rows die refereren naar '1001' als customerid. Die heb je wellicht in beide. het beste is dan ook migreren naar een nieuwe db vanuit beide systemen. Data kan nl. ook in verschillende vormen zijn opgeslagen maar dezelfde fysieke entity representeren!

Tegenwoordig voorzie ik zonder nadenken elke tabel van een autoincrement PK. Dus ook koppeltabellen. Soms moet je achteraf weer aan de gemaakte koppeling refereren vanuit een andere tabel, en dan mag je achteraf PK's gaan toevoegen, wat ook niet altijd even makkelijk gaat.

het objectifyen van relaties omwille van gemak lijkt me niet de juiste weg, tenzij er een noodzaak is voor het objectifyen van een relatie. Het refereren naar zo'n entity is een voorbeeld ervan. Echter, aangezien je maar 1 clustered index per table kunt hebben en die steevast op de PK zit, heb je soms performance problemen wanneer je wel de 2 FK fields hebt maar niet de PK, want dat levert een non-clustered index scan op.

[curry684]

dusty schreef op woensdag 27 juni 2007 @ 05:38:
[...]

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

Dat doe ik dan weer niet, bij een zuivere koppeltabel gaat er gewoon een PK over alle velden

EfBe schreef op woensdag 27 juni 2007 @ 09:13:
[...]

Nee dit is niet zo. GUIDs zijn nl niet sequentieel. Een PK heeft veelal een clustered index (een index die ervoor zorgt dat je values in de index volgorde fysiek zijn opgeslagen) en een insert is dan veelal een veel tragere operatie vaak.

a) ik heb nergens gezegd dat ze sequentieel zijn
b) de persoon die bedacht heeft dat SQL Server z'n PK's default clustered maakt moet aan de hoogste boom. Ik zet het vrijwel altijd uit zodat ik de clustered voor een nuttiger plek kan gebruiken, en je met name op tabellen met grote fields en regelmatige deletes meer performance behoudt.
c) het ging over selects en joins, niet over inserts

EfBe schreef op woensdag 27 juni 2007 @ 12:21:
Echter, aangezien je maar 1 clustered index per table kunt hebben en die steevast op de PK zit, heb je soms performance problemen wanneer je wel de 2 FK fields hebt maar niet de PK, want dat levert een non-clustered index scan op.

Ik mag hopen dat jij ook weet dat je dat gewoon uit kunt zetten?

edit:
ik zie dat je dat wel noemt in een andere post ja, dan snap ik de relevantie van je verhaal niet. een clustered PK op GUIDs is inderdaad zot als je veel insert/delete, dat is nogal een open deur die compleet buiten de discussie of mijn verhaal gaat.

[ Voor 21% gewijzigd door curry684 op 27-06-2007 14:33 ]

[whoami]

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.

Dat is onzin. Een GUID column is net zo goed indexeerbaar.
Het enige probleem met GUID's is als je een clustered index op je GUID legt. Een clustered index bepaalt nl. de fysieke opslagvolgorde van je records; daarom dat er 'aangeraden' wordt dat de column waarop je een clustered index legt, best sequentieel incrementeert. Een gewone GUID garandeerd dat niet, waardoor SQL Server dus geregeld page splits zal mogen doen in dat geval.
Maar goed, da's al uitvoerig door EfBe uitgelegd in dit topic.

Ik gebruik zelf GUID's als primary key's hier in m'n DB. (En deze zan dan meteen ook de ROWGUIDCOL voor m'n merge-replication).
Maar, het is idd niet aan te raden om een clustered key daarop te specifieren, dus geen enkele van m'n PK's zijn clustered.

[ Voor 64% gewijzigd door whoami op 27-06-2007 14:43 ]

[EfBe]

curry684 schreef op woensdag 27 juni 2007 @ 14:29:
a) ik heb nergens gezegd dat ze sequentieel zijn
b) de persoon die bedacht heeft dat SQL Server z'n PK's default clustered maakt moet aan de hoogste boom. Ik zet het vrijwel altijd uit zodat ik de clustered voor een nuttiger plek kan gebruiken, en je met name op tabellen met grote fields en regelmatige deletes meer performance behoudt.
c) het ging over selects en joins, niet over inserts

Jij zei:

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.

Dat is dus onzin. Ze zijn inmens trager bij inserts. Indien je de clustered index eraf haalt, dan is je select weer trager.

Ik mag hopen dat jij ook weet dat je dat gewoon uit kunt zetten?

Wat denk je zelf...

edit:
ik zie dat je dat wel noemt in een andere post ja, dan snap ik de relevantie van je verhaal niet. een clustered PK op GUIDs is inderdaad zot als je veel insert/delete, dat is nogal een open deur die compleet buiten de discussie of mijn verhaal gaat.

In het geval van een GUID PK: Indien je geen clustered index op je PK hebt, merk je dat in je selects wanneer je bv je pk vervangt door een identity int en de performance gaat vergelijken. Heb je wel een clustered index op je PK, dan merk je dat weer bij inserts. Jij roept dat het niet uitmaakt qua performance (zie hierboven) en dat is dus kolder.

[Janoz]

Waarom zou een select trager zijn wanneer je de clustered index er af haalt?

[curry684]

Janoz schreef op woensdag 27 juni 2007 @ 15:32:
Waarom zou een select trager zijn wanneer je de clustered index er af haalt?

Dat mis ik inderdaad ook ergens. Dat het trager is omdat het 16 bytes is ipv 4: sure, maar bij claims dat het "aanmerkelijk" trager is zou ik graag onderbouwing zien want het strookt niet echt met mijn ervaring.

[.oisyn]

Het scheelt natuurlijk veelal een extra read van disk. Waar de data bij een clustered index al is ingelezen bij het zoeken naar de juiste ID, heeft een unclustered index slechts een verwijzing naar de data waardoor die data eveneens opgehaald moet worden.

Ik kan me voorstellen dat dit bij een grote database met veel random access (waar caching dus niet heel veel nut heeft) best wel wat kan schelen.

[whoami]

Als je een record ophaalt via z'n clustered index, dan heb je ook direct het record, omdat die clustered index eigenlijk gewoon de 'laagste node' is, wat direct het record is. (clustered index is covering).
Maw, er hoeft geen index meer 'doorlopen' te worden totdat het record zelf bereikt is.

Of het 'aanmerkelijk' trager is .... ik heb het nog niet ondervonden.

[ Voor 4% gewijzigd door whoami op 27-06-2007 22:00 ]

[curry684]

Waarbij het gecombineerde punt van whoami en oisyn imho correct is in dat een tabel die vaak genoeg wordt aangesproken om het snelheidsverschil relevant te laten zijn heel hoogstwaarschijnlijk toch al permanent z'n queries, execution plans en indexen gecached in het RAM heeft zitten, anders heeft de server dringend een paar reepjes extra nodig.

[EfBe]

Ik heb geen benchmarks hier liggen, maar je bent veelal met extra reads bezig, zoals al hierboven gemeldt, Dit houdt dus in dat in gevallen van nood (lees: wanneer IO de bottleneck vormt) je dus vet de pineut bent en je nieuwe HW kunt gaan kopen, terwijl bij een normale ID dat niet zo was geweest

Curry: die handel zal wel in de cache zitten, maar die 15 miljoen records veelal niet.

[curry684]

True, maar dat zitten ze dan net zomin met een clustered identity PK.... wat nu net het hele punt was waar het over ging Sterker nog, een clustered PK zal minder cacheable zijn met 15 miljoen records dan een willekeurige non-clustered PK, waardoor je niet geringe kans hebt dat dan de non-clustered index scans juist sneller zijn

Hoe dan ook blijft het punt staat dat dinges hierboven ergens onzin verkondigde door te stellen dat GUID's als PK per definitie een stom idee zijn omdat ze kut performen. Ik gebruik ook vrijwel altijd identity surrogates for the record, maar in beginsel non-clustered dus tenzij ik een goede reden heb om specifieke waarde aan de identity volgorde te verbinden, of de tabel door toepassing van soft-deletes of andere redenen 99.99% selects zal uitlokken.

[whoami]

Nog een reden om geen 'natural primary' keys in SQL Server te definiëren:
- Ten eerste moet je PK eigenlijk nooit wijzigen, maar stel bv dat het toch voorkomt dat je de waarde van een PK moet wijzigen, dan worden niet enkel de FK's gewijzigd;
Als de primary key een clustered index is, dan moeten alle andere indexen op die tabel ook aangepast worden. De 'sleutel' van de clustered index is nl. ook vervat in alle andere indexen op de tabel -> alle andere indexen aanpassen.
Leuk; zeker als dit lijdt tot een gefragmenteerde tabel.

(Nuja, een beetje DBA heeft wel een maintenance plan op z'n DB die geregeld eens de tabellen re-organiseert).

[Anoniem: 178962]

whoami schreef op woensdag 27 juni 2007 @ 21:38:
Nog een reden om geen 'natural primary' keys in SQL Server te definiëren:

Nog een reden... volgens mij is die reden nu al 1000x genoemd

[mphilipp]

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.

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.

Hele verstandige woorden! In de praktijk blijjkt het vaak gewoon de beste manier. Je wint er enorm mee aan flexibiliteit. En waarom zou dat nummer dan niet door een trigger/seuqence gegenereerd mogen worden? Welke regel - en belangrijker: waarom - schrijft dat voor? (dit wordt een paar posts hierboven gezegd). Een nietszeggend en voor de gebruiker verborgen numeriek veld is een prima PK. Wie tegenwoordig nog wakker ligt van een paar bytes extra opslag weet zeker niet dat we in de 21ste eeuw leven. Qua performance maakt het geen drol uit. Een goed en flexibel ontwerp performt altijd goed (mits aan de andere randvoorwaarden voldaan is).

Een naam als PK lijkt me geen goed idee. Het is natuurlijk altijd lastig om een generiek antwoord te geven op zo'n vraag. Er zal altijd wel weer een situatie te bedenken zijn waarin het wél een goed idee is. In het algemeen echter niet. Maak er een unique key op, en maak een technische sleutel. Die is altijd van jou en niemand kan eraan gaan rommelen of het willen veranderen. Nics mis mee.

@Frankpie: een PK moet je niet willen veranderen omdat het A)verboden is en B)er misschien wel een heleboel andere tabellen aan refereren. Die moet je dan allemaal meeveranderen. Waarom wil je dát dan wél? Niet aan beginnen. Dat is de eerste stap op de weg naar het verprutsen van een db. Pak gewoon een technische sleutel en kom er niet meer aan. Een PK is om een record uniek te maken en referentiële integriteit te kunnen garanderen (door FK's die er naar verwijzen). Het hoeft niets te betekenen en zoeken op andere velden kun je ook door indexen aan te maken. Wees overigens niet te scheutig met indexen; ze kunnen je heel makkelijk parten gaan spelen bij overvloedig gebruik.

[whoami]

Anoniem: 178962 schreef op woensdag 27 juni 2007 @ 22:02:
[...]

Nog een reden... volgens mij is die reden nu al 1000x genoemd

Die reden van het feit dat de clustered index in iedere andere index vervat zit, en updates dus ook tot fragmentatie van de tabel kunnen leiden, is nog niet vernoemd.

[Anoniem: 178962]

whoami schreef op woensdag 27 juni 2007 @ 22:19:
[...]

Die reden van het feit dat de clustered index in iedere andere index vervat zit, en updates dus ook tot fragmentatie van de tabel kunnen leiden, is nog niet vernoemd.

Das waar, maar dat als je de PK key moet aanpassen dat je dan alle FK moet updaten is het probleem (wat al vaker genoemd werd).

Wat jij beschrijft is alleen een extra beetje *piep*heid wat je erbij krijgt mocht het een clustered index betreffen, dus niet echt een nieuwe reden, alleen insult to injury mocht je het wel doen

[.oisyn]

mphilipp schreef op woensdag 27 juni 2007 @ 22:18:
@Frankpie: een PK moet je niet willen veranderen omdat het A)verboden is

Verboden? Door wie? En wat als je het wel doet, komt de databasepolitie je dan oppakken?

B)er misschien wel een heleboel andere tabellen aan refereren

Ja goh, weleens bij stilgestaan dat dit juist de oorzaak is van de door jou genoemde A? Als niemand er namelijk aan refereerde dan kon je ze ook zonder enige problemen veranderen . Het hele idee van een PK is juist dat er naar die entiteit gerefereerd kan worden.

Niet dat ik wil pleiten voor dynamische PKs hoor, maar je argumentatie laat een beetje te wensen over, en klinkt een beetje als wat je ouders weleens tegen hun kinderen hoort zeggen: "Het mag niet omdat ik het zeg"

[ Voor 22% gewijzigd door .oisyn op 28-06-2007 00:50 ]

[curry684]

mphilipp schreef op woensdag 27 juni 2007 @ 22:18:
@Frankpie: een PK moet je niet willen veranderen omdat het A)verboden is en B)er misschien wel een heleboel andere tabellen aan refereren. Die moet je dan allemaal meeveranderen.

Nounou niet meteen overdramatisch. Het is alleszins niet verboden, en fatsoenlijke databases ondersteunen gewoon cascading updates.

Ik heb regelmatig tabellen met semi-constanten (denk bijv. aan de status van iets) waarbij de PK gewoon een editable integer is. Kun je namelijk makkelijk mappen naar je code dan, en ben je niet afhankelijk van wat de DB bedenkt.

[mphilipp]

.oisyn schreef op donderdag 28 juni 2007 @ 00:45:
"Het mag niet omdat ik het zeg"

En dat is ook zo. Klinkt erg lullig, maar ik kan geen enkele zinvolle reden bedenken waarom je het zou willen. Dus je kunt er wel lekker wijs over gaan doen, maar denk eerst eens na over de reden van het bestaan van een PK. Die PK's zijn er om te zorgen dat die arme computer de boel kan vinden. Als jij een leuk naampje wilt hebben om een record aan te kunnen herkennen, moet je dat er gewoon bij stoppen en een UK van maken. Maar laat die PK gewoon met rust en ga er niet aan zitten rommelen. Zolang ik daar geen goede reden voor hoor (en ik heb er de afgelopen 20 jaar niet één gehoord) ist es verboten!

En inderdaad komt de databasepolizei je dan oppakken...

[mphilipp]

curry684 schreef op donderdag 28 juni 2007 @ 01:46:
[...]
Nounou niet meteen overdramatisch. Het is alleszins niet verboden, en fatsoenlijke databases ondersteunen gewoon cascading updates.

Maar waarom wil je dat dan? Noem nou eens een dringende reden om je PK te willen aanpassen? Wat stop je daar dan allemaal in? Maak je het jezelf niet erg moeilijk als je dat soort dingen gaat doen.

Ik werk overigens al 20 jaar met Oracle als ontwikkelaar/docent/dba en ik heb echt nog nooit een systeem onder handen gehad of gebouwd waarbij men heel erg graag updateable PK's had. Ja...het komt wel eens ter sprake, maar dat is dan in een heel vroeg stadium van het design en dan implementeren we gewoon een technische sleutel en die pseudo PK wordt dan een UK. Ik zeg ook niet dat het niet kán, ik zeg dat je het niet moet willen. En nogmaals, zolang ik geen goede reden hoor, ga ik alle complicaties uit de weg. Er zijn genoeg uitdagingen bij het bouwen en (vooral!) onderhouden van een systeem dat ik die er niet nog eens bij kan gebruiken.

[EfBe]

Ik heb al een aantal posts gezien van mensen die anderen aan hele hoge bomen willen opknopen maar wat schetst mijn verbazing? Diezelfde mensen vinden het normaal dat PK fields worden gewijzigd!

Iedereen die PK values wil wijzigen snapt niets van databases. Zo.
(immers, het wijzigen van de PK is semantisch het deleten en re-inserten van een nieuwe entity instance, en dat is precies wat de persoon die de handel wijzigt NIET denkt dat hij/zij aan het doen is )

[ Voor 27% gewijzigd door EfBe op 28-06-2007 09:07 ]

[joepP]

Confusion schreef op woensdag 27 juni 2007 @ 11:55:
[...]

Wanneer gaat een surrogate PK toevoegen aan een koppeltabel niet makkelijk?

In een bijna 24/7 live-omgeving met een gigantische koppeltabel. Dan kost het teveel tijd om een identity veld op een tabel aan te maken, aangezien de complete tabel opnieuw opgebouwd moet worden doordat het een clustered key is. Dat kan al snel een half uurtje kosten. Plus dat je database dan waarschijnlijk niet meer backwards compatible is met de vorige applicatieversie, waardoor je bij het falen van een update helemaal zuur bent. Mag je weer fijn je backup gaan terugzetten, en dat kost dan weer extra tijd. Allemaal extra gezeur omdat je in eerste instantie niet een simpele surrogate PK hebt toegevoed.

Ik zie vooral weinig zwaarwegende reden om de PK niet in eerste instantie al toe voegen. Performance, databasegrootte en leesbaarheid leiden er maar minimaal onder. Er zullen best uitzonderingen te bedenken zijn, maar waarom moeilijk doen als het makkelijk kan? We programmeren tenslotte ook niet meer in assembler

EfBe schreef op woensdag 27 juni 2007 @ 12:21:
het objectifyen van relaties omwille van gemak lijkt me niet de juiste weg, tenzij er een noodzaak is voor het objectifyen van een relatie. Het refereren naar zo'n entity is een voorbeeld ervan. Echter, aangezien je maar 1 clustered index per table kunt hebben en die steevast op de PK zit, heb je soms performance problemen wanneer je wel de 2 FK fields hebt maar niet de PK, want dat levert een non-clustered index scan op.

Zo duur is een non-clustered index scan nou ook weer niet, en de meeste joins hebben niet beide FK fields ter beschikking maar slechts eentje. En dan moet je toch altijd al een non-clustered index scan doen. Er zijn best situaties te bedenken waarin dit uit zal maken, maar het verschil zal nooit groot zijn.

[.oisyn]

mphilipp schreef op donderdag 28 juni 2007 @ 07:31:
Dus je kunt er wel lekker wijs over gaan doen

Misschien moet je mijn post nog eens goed lezen. Want zoals ik al zei, ik ben het met je eens (als in, je moet het niet willen, maar het is niet verboden --selecteren op een kolom die niet voorkomt in een group by, dát is verboden-- en soms noodzakelijk, zoals bij een db merge oid), alleen je beargumentatie klinkt nogal ruk . "Het mag niet omdat ik het zeg" is géén goede beargumentatie, en klinkt op z'n zachtst gezegd nogal dom als er in de draad van 100+ posts al lang en breed is gesproken over de implicaties van het wijzigen van PKs (met wél goede beargumentatie). That's my whole point

[ Voor 14% gewijzigd door .oisyn op 28-06-2007 11:14 ]

[Grijze Vos]

De enige reden dat je een naam als PK wilt gebruiken is om didactische redenen. Dan leest zo'n PK wat makkelijker, en is het handig voor de uitleg. In de praktijk voeg ik zelf altijd gewoon een numeriek ID toe, alhoewel dat natuurlijk ook een GUID zou kunnen zijn, tis niet alsof die key verder enige semantische waarde heeft, buiten het aanwijzen van een record.

[Confusion]

joepP schreef op donderdag 28 juni 2007 @ 10:59:
In een bijna 24/7 live-omgeving met een gigantische koppeltabel. Dan kost het teveel tijd om een identity veld op een tabel aan te maken, aangezien de complete tabel opnieuw opgebouwd moet worden doordat het een clustered key is.

Ah, bedoelde je het zo. Ik dacht 'niet makkelijk', als in: moeilijk qua SQL statements ofzo. Overigens moet het inderdaad wel een gigantische koppeltabel in een omgeving zonder 'low load' momenten zijn, wil je het niet 's nachts kunnen doen. Een 24/7 live omgeving waar je zo'n handeling niet uit kunt halen, die gaat waarschijnlijk sowieso een keer hard op z'n bek.

Plus dat je database dan waarschijnlijk niet meer backwards compatible is met de vorige applicatieversie, waardoor je bij het falen van een update helemaal zuur bent.

Als ergens een select * gedaan wordt, waarbij die nieuwe kolom er uit rolt en de kolommen worden op nummer benaderd: ja, dan kan zoiets mis gaan. Maar ook dat is een systeem dat sowieso van brakheid wel een keer op z'n bek zal gaan. Je kan prima applicaties schrijven die niet op hun bek gaan op het moment dat je een kolom met index aan de database toevoegt.

[curry684]

EfBe schreef op donderdag 28 juni 2007 @ 09:06:
Ik heb al een aantal posts gezien van mensen die anderen aan hele hoge bomen willen opknopen maar wat schetst mijn verbazing? Diezelfde mensen vinden het normaal dat PK fields worden gewijzigd!

Nounou nu spring jij wel heel snel naar conclusies Dat ik zeg dat een goede DB cascading updates ondersteunt om het wijzigen van PK's te faciliteren betekent nog bij lange na niet dat ik het aanraadt, of zelfs dat ik het ooit heb gebruikt, wat namelijk niet zo is.

De zeldzame gevallen waarin ik non-identity PK's heb gebruikt buiten zuivere koppeltabellen zijn 'semi-const endpoints', zoals statusnamen e.d. En nee, ook daar kan ik me niet herinneren ooit een PK te hebben gewijzigd, maar je hebt ook geen gaten in je business logic enums als je een keer een status moet deleten: die kun je gewoon hernummeren met wat simpele queries, zonder ook maar ergens de database te compromitteren. Sterker nog, de impliciete unique constraint van een PK waarborgt dat je er niets aan verneukt.

[mphilipp]

.oisyn schreef op donderdag 28 juni 2007 @ 11:08:
[...]
"Het mag niet omdat ik het zeg" is géén goede beargumentatie, en klinkt op z'n zachtst gezegd nogal dom als er in de draad van 100+ posts al lang en breed is gesproken over de implicaties van het wijzigen van PKs (met wél goede beargumentatie). That's my whole point

Sorry, maar mag ik dan nóg botter uit de hoek komen als ik al eerder deed? Als ik zoiets zeg, moet je dat niet letterlijk nemen... Misschien had ik er een smiley bij moeten zetten, maar ik wil dat ook weer niet omdat het gewoon één van de meest basale zaken is van database ontwerp. Ik zou het erg triest vinden als dat hier nog een keer heel erg zwaar beargumenteerd moet gaan worden. Ik maak er dan maar een beetje een sarcastische opmerking van. Tenslotte wordt er van twiekers wel eea verwacht hoor ik steeds. En dan met zoveel slimme mensen bij elkaar...

Dus ja...ik kan dan lekker suf uit de hoek komen. Maar het blijft Verboten! (Donnerwetter). En er zullen best mensen zijn die er een goede reden voor kunnen bedenken. Ik niet. Ik bedoel: het kan best, maar er zijn meer goede redenen te bedenken om het niet te doen. En er is geen dwingende reden om het te doen, maar velen om het niet te doen. That's my point. Klinkt waarschijnlijk heel erg arrogant (so be it) maar ik heb in 20 jaar nog niet één écht goede reden gehoord waardoor ik meteen aan het werk ging om een updateable PK te implementeren.

[mphilipp]

Grijze Vos schreef op donderdag 28 juni 2007 @ 12:03:
De enige reden dat je een naam als PK wilt gebruiken is om didactische redenen. Dan leest zo'n PK wat makkelijker, en is het handig voor de uitleg.

Tsja...heb je een DB om er wat in op te slaan of om 'm uit te leggen? Gebruikers zien er toch niets van en beheerders hebben niets met het datamodel te maken. Hooguit TAB's die er misschien een keer in moeten grutten. Voor rapportages heb je immers mooie tools die er een laagje overheen leggen.
Een autofabrikant maakt de onderdelen op de motor ook niet zodat je ze beter kunt aanwijzen aan de bestuurders. Sterker nog...bij een A2 kun je niet eens meer bij de motor. Zo hoort het; je hebt er niets te zoeken. Mensen die een DB of datamodel niet snappen, moeten er ook niet naar kijken.

[Grijze Vos]

mphilipp schreef op donderdag 28 juni 2007 @ 20:56:
[...]

Tsja...heb je een DB om er wat in op te slaan of om 'm uit te leggen? Gebruikers zien er toch niets van en beheerders hebben niets met het datamodel te maken. Hooguit TAB's die er misschien een keer in moeten grutten. Voor rapportages heb je immers mooie tools die er een laagje overheen leggen.
Een autofabrikant maakt de onderdelen op de motor ook niet zodat je ze beter kunt aanwijzen aan de bestuurders. Sterker nog...bij een A2 kun je niet eens meer bij de motor. Zo hoort het; je hebt er niets te zoeken. Mensen die een DB of datamodel niet snappen, moeten er ook niet naar kijken.

Ik bedoelde eigenlijk uitsluitend voor les doeleinden. Al mijn database vakken zijn mij helemaal uitgelegd zonder ook maar een cijfer gezien te hebben. Mja, 80 procent ging sowieso over "de bier-database".

[Gomez12]

Grijze Vos schreef op donderdag 28 juni 2007 @ 22:35:
[...]

...
Mja, 80 procent ging sowieso over "de bier-database".

Bestaat daar een database van??? Mij is in mijn studententijd geleerd dat er geen database van bestaat en dat je die zelf proefondervindelijk ( met enkele smaaktesten ) moet aanleggen.

[Confusion]

mphilipp schreef op donderdag 28 juni 2007 @ 20:56:
[...]

Tsja...heb je een DB om er wat in op te slaan of om 'm uit te leggen? Gebruikers zien er toch niets van en beheerders hebben niets met het datamodel te maken. Hooguit TAB's die er misschien een keer in moeten grutten. Voor rapportages heb je immers mooie tools die er een laagje overheen leggen.
Een autofabrikant maakt de onderdelen op de motor ook niet zodat je ze beter kunt aanwijzen aan de bestuurders. Sterker nog...bij een A2 kun je niet eens meer bij de motor. Zo hoort het; je hebt er niets te zoeken. Mensen die een DB of datamodel niet snappen, moeten er ook niet naar kijken.

Als we toch de slechte analogieen hoek induiken: het is bepaald geen goede zaak dat automonteurs zelf bijna niets meer kunnen doen en alleen maar in de interne computer kunnen kijken of die denkt dat er iets mis is. Dat je niet bij de motor kan betekent wel dat die motor gegarandeerd onderhoudsvrij moet zijn en dat zijn databases niet.

Hoe makkelijker de database te onderhouden is, hoe beter dat uiteindelijk voor de klanten is.

[mphilipp]

Confusion schreef op vrijdag 29 juni 2007 @ 08:46:
[...]
Dat je niet bij de motor kan betekent wel dat die motor gegarandeerd onderhoudsvrij moet zijn en dat zijn databases niet.

Volgens mij zeg ik dat ook helemaal niet. De bestuurder heeft er niets te zoeken. Je kunt bij een moderne auto niets meer doen, dus moet je er ook vanaf blijven. Ik snap na 20 jaar ook wel dat een db niet onderhoudsvrij is. Maar dat wil niet zeggen dat ik elke kokosnoot eraan moet laten komen met zijn vette vingers. Sterker nog, de meeste 'so called' dba's mogen er wat mij betreft ook maar vanaf blijven...

[Confusion]

mphilipp schreef op vrijdag 29 juni 2007 @ 18:13:
Volgens mij zeg ik dat ook helemaal niet. De bestuurder heeft er niets te zoeken. Je kunt bij een moderne auto niets meer doen, dus moet je er ook vanaf blijven. Ik snap na 20 jaar ook wel dat een db niet onderhoudsvrij is. Maar dat wil niet zeggen dat ik elke kokosnoot eraan moet laten komen met zijn vette vingers. Sterker nog, de meeste 'so called' dba's mogen er wat mij betreft ook maar vanaf blijven...

Het gaat hier niet over de vraag of users aan de database moeten mogen komen. Het gaat er over dat een database gemakkelijker te onderhouden is als de data betekenisvol voor je is, omdat het een paar queries scheelt terwijl je zoekt naar een probleem, waardoor je gemakkelijker overzicht over de samenhang van de data houdt en sneller kan inzien wat er mis. Dat zal lang niet altijd doorslaggevend zijn, maar als jij een FK naar een tabel landen legt en je houdt de ISO standaard voor de landnamen aan als PK, dan lijkt het me niet nodig om daar nog eens een synthetic PK bij te leggen.

[mphilipp]

Confusion schreef op vrijdag 29 juni 2007 @ 18:22:
[...]
Het gaat hier niet over de vraag of users aan de database moeten mogen komen. Het gaat er over dat een database gemakkelijker te onderhouden is als de data betekenisvol voor je is, omdat het een paar queries scheelt terwijl je zoekt naar een probleem, waardoor je gemakkelijker overzicht over de samenhang van de data houdt en sneller kan inzien wat er mis. Dat zal lang niet altijd doorslaggevend zijn, maar als jij een FK naar een tabel landen legt en je houdt de ISO standaard voor de landnamen aan als PK, dan lijkt het me niet nodig om daar nog eens een synthetic PK bij te leggen.

Sorry, maar dat vind ik grote onzin. Als je een systeem gaat ontwerpen is onderhoudbaarheid een belangrijk issue natuurlijk. Maar om daarom maar een Mickey Mouse systeem te maken lijkt me een onzinnige beslissing en totaal overbodig. Is het teveel gevraagd om een heeeeel klein beetje intelligentie van de mensen die er aan moeten knutselen te verwachten? Is het werkelijk zo ingewikkeld om een querietje te schrijven waarin een join voorkomt met een kolom die PERS_PK heet ipv PERSONSNAAM? Ik vraag me af voor welke organisatie je dan een systeem aan het ontwikkelen bent. Ik ga me haast superieur voelen met mijn 4 jaar MAVO met pretpakket, want ik snap het volledig. Sterker nog: ik heb dergelijke systemen ontworpen, geïmplementeerd, onderhouden en gemigreerd. En dan voor behoorlijke organisaties. Nooit een eis gehoord dat de boel voor de Josti band begrijpelijk moest zijn.

Nee. Ik kan me daar niet in vinden. Een goed doordacht en logisch ontwerp is aan elke verstandige, intelligente volwassene die enig begrip en inzicht heeft in basale db technologie te begrijpen. Ik snap werkelijk niet waarom er hier zó lang gedelibreerd moet worden over een non-issue. Er worden alleen maar onzinnige redenen bedacht om tóch maar niet aan die technische sleutels te hoeven. Is het stugheid, koppigheid, eigenwijsigheid of gewoon dommigheid? Neem nou gewoon aan dat je jezelf een hoop ellende bespaart als je het gewoon op die manier doet. Uiteraard zijn er best situaties denkbaar waarbij een andere manier nooit voor problemen zal zorgen. Prima, geen problemen mee. Maar uit mijn ervaring kan ik je melden dat er nog al eens dingen veranderen die nooit eerder voorzien zijn. En dán het je kans dat dit soort a-typische oplossingen voor gigantische problemen gaan zorgen. Ik heb dat nou als zó vaak gezien, en maak het nog steeds mee. Ook zeggen klanten vaak dat een bepaalde situatie nooit zal veranderen of dat een bepaalde optie die een flexibel design mogelijk maakt nooit nodig zal zijn. Ik geloof dat nooit. Soms willen ze het ineens wél binnen 3 maanden na go-live... Niemand heeft een kristallen bol, snap je? Dus het vasthouden aan bepaalde basisregels van db design doet in dat soort gevallen geen pijn.

Dus nogmaals: zolang er geen dwingende reden is...doe het dan gewoon niet.

[Confusion]

mphilipp schreef op vrijdag 29 juni 2007 @ 19:44:
[...]
Neem nou gewoon aan [..]

Gelukkig hoeven we dat niet van je aan te nemen, want er zijn al vroeg in de discussie argumenten voor genoemd, waaruit we zelf kunnen concluderen dat het voordelen heeft om overal synthetic PK's aan te knopen (voorzover we daar niet al van overtuigd waren voor deze discussie). Dat betekent niet dat we ons niet af kunnen vragen of er uitzonderingsgevallen zijn, waarin het gunstig kan zijn om van die regel af te wijken. Dat jij er voor jezelf uit bent en mensen die dat soort suggesties doen afblaft en doelen toeschrijft die ze niet hebben om je eigen ego te boosten, betekent niet dat het geen zinnige suggestie is.

[ Voor 87% gewijzigd door Confusion op 30-06-2007 21:05 ]

[mphilipp]

Confusion schreef op zaterdag 30 juni 2007 @ 20:46:
Gelukkig hoeven we dat niet van je aan te nemen

Nee...stel je voor...je zult een keer iets opsteken van iemand met ervaring.
Volgens mij probeert er hier maar één zijn ego te boosten, moderator. And it isn't me. Als ik mijn ego zou willen boosten, verpilde ik mijn tijd niet om iemand iets te leren.

Het interesseert me geen reet wat jullie die arme databases allemaal aan willen doen. Het irriteert me alleen dat zoveel wijsneuzen bij elkaar allerlei rare kronkels proberen te bedenken om een non-issue zinnig te laten lijken. Wat is het fokking probleem nu eigenlijk? Probeer een écht database issue op te lossen ipv slim te lijken door er een te verzinnen. Een key is een key en that's it. Er zijn belangrijker issues in database technologie om je hoofd over te breken. Daar is dit verhaal veel te onbelangrijk voor. Eigenlijk is dat het enige dat mijn aandacht zo lang bij dit topic hield...het onbegrip...

En voor nu...debatteer gerust verder. Ik ga mijn ego elders een beetje boosten...

[ Voor 72% gewijzigd door mphilipp op 01-07-2007 01:03 ]

[EfBe]

Ik wil aan deze nutteloze herhaling van zetten toevoegen dat deze discussie over wel/niet artifical PK's NOG ouder is dan of stored procedures wel/niet moeten. Heb dus niet de illusie dat hier een consensus bereikt wordt, dat is nl. nog niemand gelukt.

[.oisyn]

mphilipp schreef op zondag 01 juli 2007 @ 00:58:
Als ik mijn ego zou willen boosten, verpilde ik mijn tijd niet om iemand iets te leren.

Aangezien we toch al in een nutteloze discussie aanbeland zijn: mensen leer je dingen met argumenten, niet met "omdat ik het zeg" en "neem nou maar van mij aan". Dat soort termen komen alleen maar arrogant en belerend over, en bovendien leert niemand er wat van.

Je gebruik van het woord "moderator" alleen al spreekt boekdelen.

[dusty]

.oisyn schreef op zondag 01 juli 2007 @ 14:51:
[...]
mensen leer je dingen met argumenten, niet met "omdat ik het zeg" en "neem nou maar van mij aan". Dat soort termen komen alleen maar arrogant en belerend over, en bovendien leert niemand er wat van.
[...]

Dan is zijn houding t.o.v. mensen dingen proberen te leren prima te verklaren:

mphilipp schreef op donderdag 28 juni 2007 @ 07:38:
[...]
Ik werk [...] als ontwikkelaar/docent/dba
[...]

[RobIII]

Zullen we weer wat minder op de man gaan spelen? Om eerlijk te zijn begint deze manier van discussiëren me de keel uit te hangen in dit topic. We zijn toch allemaal volwassen, of niet soms?

[mphilipp]

.oisyn schreef op zondag 01 juli 2007 @ 14:51:
[...]
Aangezien we toch al in een nutteloze discussie aanbeland zijn: mensen leer je dingen met argumenten, niet met "omdat ik het zeg" en "neem nou maar van mij aan". Dat soort termen komen alleen maar arrogant en belerend over, en bovendien leert niemand er wat van

Klopt. Maar ik had geloof ik al aangegeven waarom ik dat deed. Lijkt me duidelijk genoeg.

Overigens ben ik jaren geleden al met het trainen van mensen gestopt. En de échte kinderachtige mensen sugereren alweer dat ik op deze manier niemand iets heb kunnen leren. Ik laat ze lekker in die waan. Ik weet gelukkig beter en ben niet verantwoordelijk voor conclusies die anderen trekken. Ik heb volgens mij genoeg gezegd. Ik ga niet uitleggen waarom er puntjes op de I moeten. Als je dat niet snapt, moet je je niet met databases bezig houden. That's it...

We zijn toch allemaal volwassen, of niet soms

Hmmm....niet allemaal denk ik gezien de kinderlijke reacties.

[ Voor 6% gewijzigd door mphilipp op 01-07-2007 18:39 ]

[Confusion]

mphilipp schreef op zondag 01 juli 2007 @ 00:58:
Het irriteert me alleen dat zoveel wijsneuzen bij elkaar allerlei rare kronkels proberen te bedenken om een non-issue zinnig te laten lijken.

Goede mensen kennen de regels. Betere mensen weten wanneer ze een uitzondering op de regel moeten maken. Ik zoek dus of er uitzonderingen zijn. En iemand die stug 'regel is regel' blijft herhalen, die overtuigt mij er bepaald niet van dat er geen uitzonderingen zijn. Een landentabel met ISO codes is geen bedachte 'rare kronkel'. Ik heb gewoon zo'n tabel in een database zitten, die momenteel is gekoppeld op de ISO code. Ik zie er een voordeel aan om het zo te laten, terwijl de kans dat deze PK in de problemen komt zo'n beetje nul is. Ik vraag me af hoe anderen daar mee omgaan. Jouw antwoord is duidelijk, maar mijn vraag was algemeen en jij kan niet het antwoord voor iedereen geven.

[Gomez12]

Confusion schreef op zondag 01 juli 2007 @ 19:53:
[...]

Goede mensen kennen de regels. Betere mensen weten wanneer ze een uitzondering op de regel moeten maken. Ik zoek dus of er uitzonderingen zijn. En iemand die stug 'regel is regel' blijft herhalen, die overtuigt mij er bepaald niet van dat er geen uitzonderingen zijn. Een landentabel met ISO codes is geen bedachte 'rare kronkel'. Ik heb gewoon zo'n tabel in een database zitten, die momenteel is gekoppeld op de ISO code. Ik zie er een voordeel aan om het zo te laten, terwijl de kans dat deze PK in de problemen komt zo'n beetje nul is. Ik vraag me af hoe anderen daar mee omgaan. Jouw antwoord is duidelijk, maar mijn vraag was algemeen en jij kan niet het antwoord voor iedereen geven.

Zoals ik al eerder zei zou ik bij een landentabel met isocodes toch gewoon een extra kolom aanmaken als pk. Gewoon voor het overzicht in de dbase, als ik 50 tabellen in mijn dbase heb staan en 49 daarvan hebben een pk genaamd id die altijd uniek is en 1 kolom heeft geen pk id. Dan vind ik het een onoverzichtelijk rommeltje.

Weet jij het voor elkaar te krijgen om alle 50 tabellen precies zo'n unieke isocode te geven dan mag je je gang gaan ( en is het imho zelfs overzichtelijker op query / view niveau ) maar heb jij 1 tabel waarbij je een "standaard" pk nodig hebt gebruik dan ook in de andere 49 tabellen een "gewone" pk.

[Confusion]

Gomez12 schreef op zondag 01 juli 2007 @ 21:22:
Zoals ik al eerder zei zou ik bij een landentabel met isocodes toch gewoon een extra kolom aanmaken als pk. Gewoon voor het overzicht in de dbase, als ik 50 tabellen in mijn dbase heb staan en 49 daarvan hebben een pk genaamd id die altijd uniek is en 1 kolom heeft geen pk id. Dan vind ik het een onoverzichtelijk rommeltje.

Hmmm, daar had ik niet aan gedacht, terwijl ik zelf altijd fan ben van consistentie . De meerwaarde van consistentie tussen alle tabellen sluit uitzonderingen op de 'gebruik een synthetic PK'-regel dan uit.

[RobIII]

mphilipp schreef op zondag 01 juli 2007 @ 18:38:
Hmmm....niet allemaal denk ik gezien de kinderlijke reacties.

Ja maar, ja maar, hij deed het ook
Gewoon kappen met dat geflauwekul en ontopic zonder op de man te spelen een normale discussie (met argumenten) voeren.

[dusty]

Confusion schreef op zondag 01 juli 2007 @ 19:53:
[...]
Goede mensen kennen de regels. Betere mensen weten wanneer ze een uitzondering op de regel moeten maken. Ik zoek dus of er uitzonderingen zijn. En iemand die stug 'regel is regel' blijft herhalen, die overtuigt mij er bepaald niet van dat er geen uitzonderingen zijn.
[...]

Op elke regel is bijna wel een uitzondering te bedenken.

Een landentabel met ISO codes is geen bedachte 'rare kronkel'. Ik heb gewoon zo'n tabel in een database zitten, die momenteel is gekoppeld op de ISO code. Ik zie er een voordeel aan om het zo te laten, terwijl de kans dat deze PK in de problemen komt zo'n beetje nul is. Ik vraag me af hoe anderen daar mee omgaan.
[...]

Ik neem aan dat je ISO 3166 bedoeld met de ISO Code, daar heb je dus drie codes voor elke land voor, 2 letters, 3 letters en een 3 cijferige combinatie. Juist omdat een database nog steeds beter is in getalletjes dan in letters is het beter om de 3 cijferige combinatie te nemen uit dezelfde ISO-standaard. Ik ben in de loop van de jaren echter al heel wat databases tegengekomen die zich dus wel netjes aan de ISO standaard houden ECHTER ook een synthetic PK erbij doen daar gaat dan je ISO-standaard uit de raam..

[RobIII]

dusty schreef op zondag 01 juli 2007 @ 21:51:
daar gaat dan je ISO-standaard uit de raam..

Hoezo? Een synthetic PK heeft geen enkele betekenis en verandert wat dat betreft dus niet aan de entity. Ik zie niet waarom je daarom je ISO standaard uit het raam zou gooien. Wie weet wordt die ISO code wel in de GUI gebruikt. Daarnaast is ook die ISO standaard aan wijzigingen onderhevig als er weer 1 of andere bananenrepubliek in 2 gedeeld wordt ofzo.

quote: http://en.wikipedia.org/wiki/ISO_3166-1

A country or territory generally gets new alpha codes if its name changes, whereas a new numeric code is associated with a change of boundaries. Some codes in each series are reserved, for various reasons; obsolete codes may be kept as reserved, borders may be considered likely to change, and some overseas territories have reserved codes of their own.

Zo zijn er vorig jaar nog wat wijzigingen geweest, en die komen 'regelmatig' voor. Hoe doe je dat dan met records die (bijv.) nog verwijzen naar voormalig Joegoslavië? Want die is uit de ISO lijst gewipt. Nu staat dat natuurlijk redelijk los van de feitelijke ISO tabel (kwestie van die records doodleuk bewaren ofzo), maar je eigen 'wrapper-tabel' (feitelijk: synthetic key) om zo'n ISO tabel kan dan IMHO geen kwaad.

[ Voor 51% gewijzigd door RobIII op 02-07-2007 09:40 ]

[.oisyn]

RobIII schreef op maandag 02 juli 2007 @ 09:26:
Daarnaast is ook die ISO standaard aan wijzigingen onderhevig als er weer 1 of andere bananenrepubliek in 2 gedeeld wordt ofzo.

Dan moet je het entiteit dat aan dat land refereert sowieso aanpassen, dus dat boeit natuurlijk niet

[ Voor 4% gewijzigd door .oisyn op 02-07-2007 11:13 ]

[RobIII]

.oisyn schreef op maandag 02 juli 2007 @ 11:13:
[...]

Dan moet je het entiteit dat aan dat land refereert sowieso aanpassen, dus dat boeit natuurlijk niet

Niet als je historische data hebt Of begrijp ik je nu verkeerd?

[Erkens]

RobIII schreef op maandag 02 juli 2007 @ 12:13:
[...]

Niet als je historische data hebt Of begrijp ik je nu verkeerd?

Maar je wilt dan weten dat het uit bananenrepubliek kwam en niet uit bananenrepubliek.part2 en dus zal je voor zowel bananenrepubliek.part1 als bananenrepubliek.part2 een nieuwe entry moeten maken voor alle toekomstige zooi.

Adresgegevens moet je dan wel bijwerken maar dat had je dan toch moeten doen voor de mensen uit bananenrepubliek.part2 omdat die tenslotte niet in bananenrepubliek.part1 wonen wat voorheen bananenrepubliek was.

[.oisyn]

Als je historische data hebt dan kan het land ook wel blijven bestaan, waarom zou je dan PKs aan moeten passen?

(Tenminste, nu ga ik er even vanuit dat bij dergelijke reorganisaties van landen niet de hele ISO lijst op de schop gaat, maar het oude land ID gewoon verdwijnt en daar nieuwe voor in de plaats komen)

.edit: en wat Erkens zegt

[ Voor 4% gewijzigd door .oisyn op 02-07-2007 12:26 ]

[RobIII]

.oisyn schreef op maandag 02 juli 2007 @ 12:26:
Als je historische data hebt dan kan het land ook wel blijven bestaan, waarom zou je dan PKs aan moeten passen?

Omdat 'meneer ISO' misschien wel besluit om 1 v/d 2 de huidige ISO code te laten houden?

.oisyn schreef op maandag 02 juli 2007 @ 12:26:
.edit: en wat Erkens zegt

Ben ik het ook wel mee eensch hoor; ik speel enkel even advocaat van de duivel (en ik zou zelf voor een synthetic key gaan, al is het maar omdat ik geen enkele instantie vertrouw in "standaardvastheid" )

[Grijze Vos]

.oisyn schreef op maandag 02 juli 2007 @ 12:26:
Als je historische data hebt dan kan het land ook wel blijven bestaan, waarom zou je dan PKs aan moeten passen?

(Tenminste, nu ga ik er even vanuit dat bij dergelijke reorganisaties van landen niet de hele ISO lijst op de schop gaat, maar het oude land ID gewoon verdwijnt en daar nieuwe voor in de plaats komen)

Da's natuurlijk wel gevaarlijk he. Stel Bananenrepubliek met code BR splitst op, en krijgt nu de namen BR1 en BR2. Jij houdt je historische database bij en bewaart BR, en maakt BR1 en BR2 aan.

Nu gaat Bananenrepubliek met code AR opbreken in drie stukken, en die krijgen codes AR, BR, CR. Probleem! **

Tenzij meneer ISO natuurlijk garandeert dat ie ISO-codes niet hergebruikt, maar ik weet niet of die garantie al dan niet bestaat, ik weet niet of meneer ISO op eventuele garanties terugkomt, en ik wil daar eigenlijk gewoon niet van afhankelijk zijn in mijn DB ontwerp.

**dubbel probleem zelfs in dit voorbeeld, nu ik het nog eens lees.

[ Voor 4% gewijzigd door Grijze Vos op 02-07-2007 12:46 ]

[Grijze Vos]

Gomez12 schreef op donderdag 28 juni 2007 @ 23:11:
[...]

Bestaat daar een database van??? Mij is in mijn studententijd geleerd dat er geen database van bestaat en dat je die zelf proefondervindelijk ( met enkele smaaktesten ) moet aanleggen.

Hehe, nah, het is gewoon een database met een aantal simpele tabellen, aan de hand waarvan we tuple calculus, relationele algebra en SQL hebben uitgelegd gekregen. Komt op een gegeven moment ook nog in logisch programmeren terug: klik.

Beetje flauwe Eindhovense humor.

[ Voor 3% gewijzigd door Grijze Vos op 02-07-2007 13:06 ]

[dusty]

Grijze Vos schreef op maandag 02 juli 2007 @ 12:37:
[...]
Tenzij meneer ISO natuurlijk garandeert dat ie ISO-codes niet hergebruikt, maar ik weet niet of die garantie al dan niet bestaat, ik weet niet of meneer ISO op eventuele garanties terugkomt, en ik wil daar eigenlijk gewoon niet van afhankelijk zijn in mijn DB ontwerp.

Codes worden in ISO standaardheden aangepast en codes die zijn gebruikt worden niet hergebruikt. (althans niet binnen dezelfde ISO standaard.)

[ta_chi79]

dusty schreef op woensdag 04 juli 2007 @ 06:38:
[...]
Codes worden in ISO standaardheden aangepast en codes die zijn gebruikt worden niet hergebruikt. (althans niet binnen dezelfde ISO standaard.)

Ze worden helaas (we zijn hier al eens tegenaan gelopen) wel hergebruikt, zie http://www.niso.org/standards/resources/3166.html#3166-3

Formerly used ISO 3166-1 code elements may be reassigned after a five year period so the Part 3 list is very useful to users of ISO 3166-1 who keep archive records on country-related information.

[dusty]

En daar komt dus deel 3 om de hoek kijken juist voor de 'archive-records.'

[Anoniem: 88813]

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?

Zou ik niet doen. De winst die je hiermee zou halen is te klein, je hebt te veel nadelen; andere tabellen moeten naar PK refereren ipv. de iso country code.
Daarnaast wil je vaak sorteren op iso country code.

Bij kleine tabellen kan een index (laat staan meerdere) soms juist vertagend werken, de hele tabel zit al in het geheugen van de dbms, en om een record op te halen moet ie eerst in de index kijken.

[Confusion]

Anoniem: 88813 schreef op maandag 16 juli 2007 @ 15:30:
Zou ik niet doen.

Ik ben er eigenlijk door dit topic van overtuigd dat voortaan wel te doen. Mijn post is bijna een maand oud; het is wel zinvol de reacties daarna door te lezen .

[.oisyn]

Anoniem: 88813 schreef op maandag 16 juli 2007 @ 15:30:
Bij kleine tabellen kan een index (laat staan meerdere) soms juist vertagend werken, de hele tabel zit al in het geheugen van de dbms, en om een record op te halen moet ie eerst in de index kijken.

Hij moet sowieso in een index kijken. Of denk jij dat de database ineens magischerwijs een geheugenadres kan uitrekenen, gegeven een getal dat op een van de kolommen van de tabel slaat?

[ Voor 4% gewijzigd door .oisyn op 16-07-2007 17:13 ]

[curry684]

Anoniem: 88813 schreef op maandag 16 juli 2007 @ 15:30:
[...]


Zou ik niet doen. De winst die je hiermee zou halen is te klein, je hebt te veel nadelen; andere tabellen moeten naar PK refereren ipv. de iso country code.
Daarnaast wil je vaak sorteren op iso country code.

Bij kleine tabellen kan een index (laat staan meerdere) soms juist vertagend werken, de hele tabel zit al in het geheugen van de dbms, en om een record op te halen moet ie eerst in de index kijken.

Je bedoelt die index die langer gecached blijft als de table content en die rechtstreeks naar de goede page wijst zodat ie niet meerdere pages van disk hoeft te reloaden?

[ACM]

.oisyn schreef op maandag 16 juli 2007 @ 17:12:
Hij moet sowieso in een index kijken. Of denk jij dat de database ineens magischerwijs een geheugenadres kan uitrekenen, gegeven een getal dat op een van de kolommen van de tabel slaat?

Het kan goedkoper zijn om in geen index te kijken en die paar pages van de tabel gewoon allemaal even te scannen Uiteraard afhankelijk van de queries, tabellen en overige omstandigheden

[Olaf van der Spek]

curry684 schreef op woensdag 27 juni 2007 @ 03:20:
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.

Hmm, nu wil ik toch graag weten waarom dat zo'n idiote query is. Ik heb niet graag zoveel idiote queries in mijn code.
Ik neem wel even aan dat we het hebben over iets dat equivalent is met een MySQL auto increment primary key.

[ Voor 11% gewijzigd door Olaf van der Spek op 27-07-2007 20:04 ]

[whoami]

Omdat dit niet echt efficient te noemen is; in het geval van SQL Server bv moet er al een clustered index scan gebeuren om dat record op die manier terug te vinden (als er al een clustered index op dat id-veld ligt; indien dat er niet is, dan gebeurt er -in het beste geval- een non-clustered index scan).

Daarnaast is het ook nog eens zo dat je op die manier niet gegarandeerd het laatste record krijgt dat jij geinserted hebt.

Als je echter gewoon het ID van het laatst toegevoegde record bepaald (door gebruik te maken van een select @@identity, select scope_identity() of ident_current), en daarna gewoon een select doet met een filter op dat ID, dan wordt dat record:

a) veel sneller teruggevonden (clustered index seek of index seek)
b) kan je garanderen dat het record dat je krijgt, het juiste record is. (Het laatste dat jij toegevoegd hebt, of het laatst toegevoegde record in die tabel tout - court; afhankelijk wat jij wil en dus van de manier waarop je het ID ophaalt.

Aangezien ik geen MySQL draaien heb hier, denk ik dus dat het het beste is als je eens kijkt wat MySQL precies doet met die queries, en de mogelijkheid om het laatste ID uit te vissen en op die manier het record op te halen.

[ Voor 10% gewijzigd door whoami op 27-07-2007 20:26 ]

[Olaf van der Spek]

whoami schreef op vrijdag 27 juli 2007 @ 20:23:
Omdat dit niet echt efficient te noemen is; in het geval van SQL Server bv moet er al een clustered index scan gebeuren om dat record op die manier terug te vinden (als er al een clustered index op dat id-veld ligt; indien dat er niet is, dan gebeurt er -in het beste geval- een non-clustered index scan).

De laatste waarde in een tree index vinden lijkt me niet zo duur.

Daarnaast is het ook nog eens zo dat je op die manier niet gegarandeerd het laatste record krijgt dat jij geinserted hebt.

Nee, daar heb je gewoon mysql_insert_id() voor. Dan is het wel een idiote query ja.

[ACM]

whoami schreef op vrijdag 27 juli 2007 @ 20:23:
Omdat dit niet echt efficient te noemen is

Het is alleen maar inefficient als het gebruikt wordt als vervanger voor het opzoeken van de gegenereerde id voor je net geinserte record. Als je echter om een andere reden de 'laatste toevoeging' wilt hebben, dan zie ik geen efficientere manier om het te doen... Hoe wil je anders, efficienter, het laatste record van je tabel opsnorren?

in het geval van SQL Server bv moet er al een clustered index scan gebeuren om dat record op die manier terug te vinden (als er al een clustered index op dat id-veld ligt; indien dat er niet is, dan gebeurt er -in het beste geval- een non-clustered index scan).

Ik vraag me af waarom in veel van de opmerkingen over SQL Server de term 'clustered index' geroepen wordt. Is dat nou echt zo'n heilige performance graal voor SQL Server?

Je kan zowel het eerste als de laatste leaf van een tree toch triviaal opzoeken door altijd links danwel rechts af te slaan bij een vertakking? En met een binary tree is het dan toch triviaal om achterwaards de index te scannen? Ik snap ook niet waarom het inefficient zou zijn om op een non-clustered index te zoeken... Het is niet dat je meerdere records nodig gaat hebben in dit geval, dus maakt het geen bal uit dat je wel of niet op volgorde random in je tabel moet springen, tenzij SQL Server natuurlijk als optimalisatie heeft dat ie in zo'n geval uberhaupt niet de index benadert maar direct het laatste record retourneert

Of slaat clustering op hoe de index-pages zijn geplaatst? Zelfs dan kan ik me niet voorstellen dat de eerste en laatste pages van je index niet doorgaans toch wel in het geheugen zitten...

Daarnaast is het ook nog eens zo dat je op die manier niet gegarandeerd het laatste record krijgt dat jij geinserted hebt.

Dat is zeker een goede reden om zo'n query niet daarvoor te gebruiken. Het aardige is natuurlijk wel zo dat in die situaties waar de gebruiker nooit tegen dit probleem aangelopen is, ook gelijk de situaties zijn waar de performanceverschillen die er zijn ook maar weinig uitmaken

Aangezien ik geen MySQL draaien heb hier, denk ik dus dat het het beste is als je eens kijkt wat MySQL precies doet met die queries, en de mogelijkheid om het laatste ID uit te vissen en op die manier het record op te halen.

In PostgreSQL is deze query zelfs een stukje langzamer (0.74 vs 0.60 ms):
select * from files where fileid = (select last_value from files_fileid_seq);
dan deze:
select * from files order by fileid desc limit 1;

Die tabel files heeft 557913 records.

Volgens mij maakt het bij MySQL ook maar weinig uit of je eerst het laatste ID uit een stukje metadata vist en daarna in een SELECT verwerkt, of dat je gewoon achterwaarts gesorteerd het laatste record er uit vist. Maar ik weet zo gauw niet uit mijn hoofd hoe je het laatste id opvraagt voor een tabel en bovendien heeft MySQL's CLI-tool niet genoeg precisie met zijn timer om het verschil te zien tussen de ene query die 0.00 en de andere die 0.00 seconde duurt

[whoami]

ACM schreef op zaterdag 28 juli 2007 @ 12:54:
[...]

Het is alleen maar inefficient als het gebruikt wordt als vervanger voor het opzoeken van de gegenereerde id voor je net geinserte record. Als je echter om een andere reden de 'laatste toevoeging' wilt hebben, dan zie ik geen efficientere manier om het te doen... Hoe wil je anders, efficienter, het laatste record van je tabel opsnorren?

In SQL Server is het mogelijk om het laatst gegeneerde ID in een tabel te bepalen.
(select ident_curent('tabelnaam') ).
Dit geeft je dus het ID van het laatst geinserte record -door eender wie, en eender wanneer het geinsert is-. Op die manier kan je dus gewoon een select * from tabel where id = bla doen.

Ik vraag me af waarom in veel van de opmerkingen over SQL Server de term 'clustered index' geroepen wordt. Is dat nou echt zo'n heilige performance graal voor SQL Server?

Tja, een 'performance graal' zou ik het niet echt durven noemen.
Feit is wel dat de clustered index de fysieke opslagvolgorde van de records bepaalt. In sommige gevallen kan een goed gekozen clustered index bepaalde queries dus nogal een performance boost geven. (Bv queries die een bepaalde 'range' moeten selecteren, of een veld waar je een ORDER BY op wilt doen).
zie ook:

A clustered index is particularly efficient on columns that are often searched for ranges of values. After the row with the first value is found using the clustered index, rows with subsequent indexed values are guaranteed to be physically adjacent. For example, if an application frequently executes a query to retrieve records between a range of dates, a clustered index can quickly locate the row containing the beginning date, and then retrieve all adjacent rows in the table until the last date is reached. This can help increase the performance of this type of query. Also, if there is a column(s) that is used frequently to sort the data retrieved from a table, it can be advantageous to cluster (physically sort) the table on that column(s) to save the cost of a sort each time the column(s) is queried.

Echter, aangezien de clustered index ook de fysieke opslagvolgorde bepaalt, kan een slecht gekozen clustered index ook voor performance problemen zorgen. Als je clustered index op een veld ligt dat vaak wijzigt bv, dan is het bijwerken van die clustered index behoorlijk duur. (record(s) verplaatsen, page splits, ... ).
Daarom is het dus aan te raden om de clustered index te plaatsen op een veld dat niet vaak wijzigt, en waarvan de waarde van dat veld sequentieel oploopt / afloopt. (Een identity column voldoet daar bv aan, of bv een datetime field dat de creatie-datum van een record bevat).