[SQL]Primary key

[shades684]

We hebben de volgende situatie. Een klant bij een bank kan een deel van zijn rente besteden aan een of meedere goede doelen. Dit wordt bijgehouden in een tabel waarin het clientid, instellingsnaam en instellingspercentage wordt bijgehouden.
Als ik van deze tabel iets op wil vragen is het zo dat ik altijd van een bepaalde klant wil weten wat hij aan welke instelling doneert. Het is dus logisch dat er een index moet komen te liggen op het clientid.
Nu is mij altijd geleerd dat het een 'best practice' is om een primary key in een tabel te hebben.Dat zou in dit geval betekenen dat je clientid, instellingsnaam als primary key zou krijgen (of een nieuwe kolom maakt waar een teller in zit). In beide gevallen niet echt nuttig lijkt me zo.

De vraag dus, is het aanleggen van een primary key echt een best practice(en waarom dan wel, want in het voorbeeld hierboven lijkt het mij dat dit helemaal niet nodig is), of heb ik ergens iets geleerd wat volledige onzin is?

[P_de_B]

Je moet een primary key hebben. Of je daar een surrogaat key voor kiest (een nieuwe kolom met een oplopend nummer) of een 'natural key' (jouw suggestie van clientid/naam) is een punt waar niet iedereen het overeens is. Daar zijn al veel discussies over geweest (zoek maar eens op surrogaat vs. natural key). Persoonlijk geef ik de voorkeur aan een autonummer kolom als PK.

[CH4OS]

shades684 schreef op donderdag 27 juli 2006 @ 13:55:
We hebben de volgende situatie. Een klant bij een bank kan een deel van zijn rente besteden aan een of meedere goede doelen. Dit wordt bijgehouden in een tabel waarin het clientid, instellingsnaam en instellingspercentage wordt bijgehouden.
Als ik van deze tabel iets op wil vragen is het zo dat ik altijd van een bepaalde klant wil weten wat hij aan welke instelling doneert. Het is dus logisch dat er een index moet komen te liggen op het clientid.
Nu is mij altijd geleerd dat het een 'best practice' is om een primary key in een tabel te hebben.Dat zou in dit geval betekenen dat je clientid, instellingsnaam als primary key zou krijgen (of een nieuwe kolom maakt waar een teller in zit). In beide gevallen niet echt nuttig lijkt me zo.

De vraag dus, is het aanleggen van een primary key echt een best practice(en waarom dan wel, want in het voorbeeld hierboven lijkt het mij dat dit helemaal niet nodig is), of heb ik ergens iets geleerd wat volledige onzin is?

Hoe is je DB structuur? Heb je die al genormaliseerd?

Het lijkt mij, dat je een (losse) tabel hebt, waar die donaties in bijgehouden worden... Dan lijkt het mij niet meer dan logisch, dat je ook een DonateID hebt... Dan wijs je daar je PK aan...

Je Donatie-tabel kan dan als volgt zijn:
DonatieID
ClientID
Datum
Bedrag_Oud
Bedrag_Nieuw
Percentage_Donatie
Afgeschreven (Niet per se nodig, kan je nu immers ook zo uitrekenen )
Naar_Instelling (Alhoewel ik me afvraag waarom je dit wilt weten...)

[ Voor 3% gewijzigd door CH4OS op 27-07-2006 14:09 ]

[NMe]

Natural keys zijn in principe veranderbaar. Als er iemand naar de burgerlijke stand gaat, dan kan hij zijn naam laten veranderen. Een surrogaat-ID blijft altijd hetzelfde en zal dus veel beter als key functioneren. En een PK is niet alleen handig, maar simpelweg nodig in de meeste databases. Een surrogaatkey toevoegen is ook niet zo'n geweldig probleem, dus dat zou ik wel doen.

[Kristof]

(Om de reactie van GJ-tje wat te verduidelijken)
Volgens mij mist er iets in je opstelling. Als ik je uitleg goed interpreteer, werk je met 2 tabellen.
Maar...
Als je het volledig neemt, moet je zeggen:
* Een klant besteedt zijn rente aan 1 of meer goede doelen én
* Een goed doel krijgt rente van 1 of meerdere klanten
Je hebt dus een veel-op-veel relatie.
Om dit op te lossen, zet je er een bridge tabel tussen. Je krijgt dan:

1/ Klant: klantnr, reknr, rekeningstand, ...
2/ Instelling: instellingID, naam, ...
3/ Donatie: klantnr, instellingID, bedrag, ...

De sleutels heb ik in het vet gezet. Zoals je zie is de 3de tabel de bridge tabel en heeft dus als sleutel een dubbele sleutel.
Door die bridge tabel maak je van 1 veel-op-veel relatie 2 een-op-veel relaties.

[CH4OS]

Kristof schreef op donderdag 27 juli 2006 @ 14:36:
(Om de reactie van GJ-tje wat te verduidelijken)
Volgens mij mist er iets in je opstelling. Als ik je uitleg goed interpreteer, werk je met 2 tabellen.
Maar...
Als je het volledig neemt, moet je zeggen:
* Een klant besteedt zijn rente aan 1 of meer goede doelen én
* Een goed doel krijgt rente van 1 of meerdere klanten
Je hebt dus een veel-op-veel relatie.
Om dit op te lossen, zet je er een bridge tabel tussen. Je krijgt dan:

1/ Klant: klantnr, reknr, rekeningstand, ...
2/ Instelling: instellingID, naam, ...
3/ Donatie: klantnr, instellingID, bedrag, ...

De sleutels heb ik in het vet gezet. Zoals je zie is de 3de tabel de bridge tabel en heeft dus als sleutel een dubbele sleutel.
Door die bridge tabel maak je van 1 veel-op-veel relatie 2 een-op-veel relaties.

Je verduidelijkt me niet, ik was de helft gewoon vergeten

[SPee]

Je zou dan op het naam veld een unieke index kunnen zetten, zodat deze toch altijd uniek moet zijn.
Maar in een PK van een int-veld kan veelal sneller naar de juiste veld gezocht worden als met een string veld.

[CH4OS]

SPee schreef op donderdag 27 juli 2006 @ 15:01:
Je zou dan op het naam veld een unieke index kunnen zetten, zodat deze toch altijd uniek moet zijn.

Zou 't niet doen... Stel ik doneer bij het WNF... En jij wilt dat ook... Veld moet nog steeds uniek zijn? Uniek wil namelijk zeggen, dat wat je in dat veld invoerd, maar 1 keer voor mag komen in je tabel... En daar heb je dus niets aan in dit geval, aangezien het mogelijk diend te zijn, om een instelling vaker te kunnen invullen...

Wat wél eventueel kan, is dat je een tabel maakt met instellingen er in en daar dan naar verwijst in je donatie tabel, maar dan krijg je het probleem wat Kristof al eerder aanhaalde: een meer op meer relatie...

Maar in een PK van een int-veld kan veelal sneller naar de juiste veld gezocht worden als met een string veld.

Volgens mij is het pas echt sneller / effectief, als je dan het getal in je query ook behandeld als integer...

[ Voor 31% gewijzigd door CH4OS op 27-07-2006 15:36 ]