primary key

Status
Niet open voor verdere reacties.
A

andreaugust

Gebruiker
Lid geworden
7 jan 2012
Berichten
105
Simpele vraag (ben nieuw)
Bij het ontwerpen van een tabel heb ik twee numerieke velden die beiden samen de primary key moeten uitmaken.
Bij de context menu van een veld kan ik primary key aanstippen maar dit lukt slechts bij 1 van de velden.
Hoe kan ik beiden als primary key aanduiden.
Dank voor enig antwoord.
 
Simpel. Niet. Er kan slechts 1 veld de primary key zijn.
 
Ik ben wel nieuw maar dat kon ik niet geloven.
Heb dan Internet onderzocht en vond de oplossing.
Oplossing is Ctrl key.
In elk geval dank voor uw antwoord.
 
@Rogers: een tabel kan best een samengestelde sleutel als primaire sleutel hebben. De velden zelf zijn dan niet uniek, de combinatie wèl.
@TS: als je de twee velden die je wilt gebruiken onder elkaar zet, kun je simpel naar beneden slepen. Heb je de <Ctrl> toets niet nodig. Overigens raad ik het gebruik van een samengestelde sleutel niet aan als je de tabel aan andere tabellen koppelt. Je maakt het gebruik ervan dan een heel stuk lastiger. Beter kun je dan een Autonummerveld toevoegen als sleutelveld en dat gebruiken. Voor je sleutelcombinatie is het al voldoende als je er een unieke index op zet, dan kun je ook geen dubbele waarden invoeren.
 
@Rogers: een tabel kan best een samengestelde sleutel als primaire sleutel hebben. De velden zelf zijn dan niet uniek, de combinatie wèl.
@TS: als je de twee velden die je wilt gebruiken onder elkaar zet, kun je simpel naar beneden slepen. Heb je de <Ctrl> toets niet nodig. Overigens raad ik het gebruik van een samengestelde sleutel niet aan als je de tabel aan andere tabellen koppelt. Je maakt het gebruik ervan dan een heel stuk lastiger. Beter kun je dan een Autonummerveld toevoegen als sleutelveld en dat gebruiken. Voor je sleutelcombinatie is het al voldoende als je er een unieke index op zet, dan kun je ook geen dubbele waarden invoeren.
Overigens ben je ook weer niet zó nieuw op HelpMij ;)
 
Octafish
De autonummering is m.i. niet aangewezen omdat de data base ontstaat door het importeren van externe data.
De samengestelde primary key lijkt mij wel nodig omdat schematisch er het volgende is.
Men gaat uit van personen (tabel1 met 1 veld P.K.)
Deze voeren verschillende handelingen uit (tabel2 met 2 velden P.K)
Bij elk van deze handelingen zijn er meerdere mogelijkheden waargenomen die ook beschreven worden (tabel3 met 3 velden P.K)
Dank voor antwoord
 
Gaat toch naar mijn mening iets fout in het ontwerp van de tabellen en ben het wel met Octa eens...

Maar naar mijn mening (met inclusief de meest recente post) is dat er nog meer mis gaat in de vorm van normalisatie.

Zgn. natuurlijke sleutels en al helemaal die bestaan uit meedere delen... Zijn meestal niet zo contant als dat ze lijken en zijn om die reden geen goede kandidaat voor een PK... In plaats daarvan kan je (toch) beter een autonummer gebruiken al is het alleen maar voor intern aan de database... Ik kan je niet vertellen hoe veel geld ik daarmee bespaard heb in de loop der jaren om de natuurlijke sleutel in mijn database NIET te gebruiken.....
 
Ik importeer EENMALIG een grote lijst van personen in met een bepaald nummer.
Waarom zou ik dat nog vervangen door een ander (autonummer) nummer?
 
Ik snap je probleem niet, en in ieder geval niet wat de import ermee te maken heeft. Als je personen importeert, zou je die import tabel in mijn ogen niet moeten gebruiken i.c.m. je andere data tabellen. Simpele reden: een import tabel heeft a) doorgaans niet juist opgemaakte velden en b) je zou de geïmporteerde data toch eerst moeten controleren en opschonen. Zeker bij een personen tabel lijkt mij dat je eerst een ontdubbelingsslag moet doen met de reeds bestaande personen.
De opgeschoonde import voeg je dan toe aan de bestaande personen tabel met een check op reeds bestaande personen. Je Personentabel koppel je aan de tweede tabel op basis van een Persoonsnummer vermoed ik (PK in de tabel Personen) en in de tweede tabel heb je blijkbaar dan nog een koppeling met een andere tabel, en blijkbaar mag die combinatie niet dubbel voorkomen. Vandaar mijn suggestie om op die twee velden een index te zetten, en geen PK. Die tweede tabel kan makkelijk een Autonummerveld hebben als sleutel, niks mis mee.
Maar wat tabel 3 in jouw vraag doet? Wellicht dat een voorbeeldje wat licht in deze duistere dagen schenkt...
 
De database ontstaat volledig nieuw met het importeren van data die deels digitaal is en deels manueel.
Ik heb reeds testen gedaan dat het kan met behulp van tekst bestanden en met behulp van Excel werkbladen.
De verschillende soorten data is te omvangrijk om het uit te leggen en doet er m.i. niet toe.

Waarom 3 tabellen?
Dat het kan en moet als louter fictief voorbeeld volgend maar schematisch

tabel 1
NrPersoon(PK)
Leeftijd

tabel 2
NrPersoon(PK)
NrReis(PK)
BezochtLand
Reiskost

tabel 3
NrPersoon(PK)
NrReis(PK)
PersoonOntmoet(PK)
LeeftijdPersoonOntmoet
AdresPersoonOntmoet


Opmerking: Bij iedere reis kunnen meerdere personen ontmoet zijn
Met de mogelijkheid van meerdere PKvelden (die ik in het begin niet kon aanstippen) heb ik nu voor deze phase voor zover ik zie geen problemen meer tenzij u mij kunt overtuigen dat voorgaand voorbeeld foutief is.
Dank voor uw interesse.
 
Dat kan inderdaad simpeler.

tabel 1
NrPersoon(PK)
Geboortedatum

tabel 2
ReisNR (PK)
|NrPersoon (unique index)
|NrReis (unique index)
BezochtLand
Reiskost

tabel 3
ReisOntmoetID (PK)
|ReisNR (unique index)
|PersoonOntmoet (unique index)
LeeftijdPersoonOntmoet
AdresPersoonOntmoet

Als PersoonOntmoet uit tabel1 komt, zou ik daar ook nog een verwijzing van maken. De gegevens zou ik daar dan uit halen.
 
Dat laatste is niet het geval

De notie unique index ken ik (nog) niet.
Moet het nog leren.
(klein woordje misschien?)
Ik neem aan dat ik dan nog kan afleiden dat het AdresPersoonOntmoet samenhangt met de geboortedatum van NrPersoon.
En dat unique index geen vermindering betekent van de mogelijkheden tegenover het gebruik van de PK.
Zijn er voordelen van deze methode?
Dank bij voorbaat.
 
Die voordelen zijn er zeker, omdat je dan met één veld voor de sleutel kunt volstaan. En dat koppelt gewoon een stuk handiger. Verder is het effect hetzelfde, een unieke index zorgt ervoor dat je geen dubbele waarden kunt invoeren. Het enkele sleutelveld zorgt ervoor dat je makkelijker koppelt. Best of both words dus.
 
Volgens het schematische voorbeeld zou ik zeggen dat Tabel3 "persoon ontmoet" simpelweg een persoon is weer uit Tabel1 en ben ik het dus eens met Octa.

Buiten het feit dat er directe voordelen zijn aan de enkelvoudige koppeling is het redelijk zeldzaam dat je echt meervoudige sleutel velden hebt.
voorbeeld uit tabel2, je ECHTE key van die tabel is hoe dan ook NrReis, welke simpelweg je autonummer kan zijn.... Tenzij er een "gebruiks" reden is dat het per persoon moet doornummeren van 1,2,3,4,5...
Als het per persoon ook 1,5,76,84 kan zijn, dan is de NrReis je PK.... met 12345 is de vervangende database key wel nodig....

Wat op het eerste gezicht "noodzakelijk" lijkt te zijn, blijkt vaak maar een gewoonte te zijn die weinig practisch nut heeft.... als je er echt op doorvraagt/graaft
 
@namliam: daar heeft TS al op geantwoord n.a.v. mijn laatste zin in bericht #11:
andreaugust zei:
Dat laatste is niet het geval
Klik om te vergroten...
@TS:
Unique Index is uiteraard het Engels voor <Ja (Geen duplicaten)>. In tegenstelling tot een index met de instelling <Ja (Duplicaten OK)>.
Een optimale sleutel is die combinatie van gegevens die met het minimale aantal velden een unieke combinatie levert. Dat kan best met twee velden geregeld worden. In een adressentabel is de combinatie [Postcode] + [Huisnummer] uniek, dus een perfecte sleutel. De combinatie [Postcode] + [Huisnummer] + [Plaats] is nog steeds uniek, maar niet optimaal omdat er 3 velden gebruikt worden waar 2 velden al genoeg zijn.
 
1) Namliam, volgens de context zijn de personen in tabel 1 en tabel 3 in principe verschillend maar men zou wel degelijk de PersonenOntmoet in tabel 1 kunnen plaatsen met hun kenmerken, maar mijn vraag ging eigenlijk meer over primary keys.
2)octafish,u schrijft : In een adressentabel is de combinatie [Postcode] + [Huisnummer] uniek.
Dit is toch duidelijk niet juist (in België toch, want de huisnummers worden hier gegeven per straatnaam en niet per postcode zodat slechts postcode + straatnaam + huisnummer uniek is).
Misschien ligt dit in Nederland anders?
Dank voor de interesse.
 
OctaFish zei:
In een adressentabel is de combinatie [Postcode] + [Huisnummer] uniek, dus een perfecte sleutel.
Klik om te vergroten...

Al is een postcode en huisnummer combo uniek, om het nog iets exacter te maken zou je ook nog het Huisnummer Toevoeging moeten toevoegen.... maar semantiek...
hij is niet gegarandeerd constant... Adressen kunnen van huisnummer maar ook van postcode en ZELFS van Plaats veranderen....
Van plaats veranderen is ZEER zeldzaam, maar gebeurd.... Huisnummers veranderen enigszins regelmatig... Postcodes hangen er ergens tussen in.


@ TS
Personen zijn personen, als je deze informatie over ze vast wil leggen... Dan kan dat prima in dezelfde tabel... zou een persoon de ene keer in de ene kant en de andere keer aan de andere kant kunnen voorkomen??

@ Postcodes
Nederland is zo een beetje het enige land of i.i.g. een van de weinige landen waar een postcode een deel van een straat is, terwijl als ik het me goed heug heel Brussel 3 postcodes heeft
 
Bij een of andere medische toestand kwam mijn vrouw dit tegen..:
naam, voorletters en geboortedatum, adres alles klopte... toch was de verkeerde persoon opgeroepen....
Tweeling (beiden wat ouder) .... met exact dezelfde initialen en nog steeds op hetzelfde adres... hoe uniek zijn dan je data....
Dus postcodes...gruwel....
 
Wat een discussie over postcodes :) Ik wilde er slechts mee aangeven dat in een adressentabel de combinatie uniek is. Inderdaad had ik het dan over de Nederlandse situatie waar we cijfers en letters gebruiken. Wat namliam vervolgens aanhaalt over veranderende plaatsnamen etc. mag allemaal wel waar zijn, maar doet niets af aan de situatie dat de combinatie [Postcode] + [Huisnummer] nog steeds uniek is...
Ook ik ben tegen situaties aangelopen dat een combinatie van [Naam] + [geboortedatum] + [Adres] niet uniek was, doorgaans inderdaad bij meerlingen waarbij de ouders niet goed hebben opgelet. Daarom is een Single Identifier doorgaans altijd aan te bevelen. Bijvoorbeeld het BSN nummer, als je dat mag gebruiken.

Overigens vraag ik me ondertussen af of er nog wel een vraag is waar TS een antwoord op wil :)
 
U heeft gelijk, OctaFish, op mijn oorspronkelijke vraag heb ik voldoende antwoord gekregen.
Met PK versus Index moet ik nog wat klaarder zien.
Wat uniek is of niet moet men m.i. weliswaar voorzichtig zijn maar het hangt natuurlijk ook af van de gegevens in de omgeving waarin men handelt, ook met inachtneming van de latere mogelijkheden.
Ik dank iedereen voor hun bijdrage.
 
Status
Niet open voor verdere reacties.
                    Steun ons                    

Nieuwste berichten

Terug
Bovenaan Onderaan