Prima zoŽn discussie, maar we moeten niet vergeten wat gevraagd werd: een simpele oplossing met standaard functies van access die uitgevoerd kan worden door iemand zonder al te veel ervaring in dit gebied (access, net zoals ik dus).
Voorbeelden als 20.000 films (waarbij dan 6mb ruimte bespaard zou kunnen worden) zijn niet echt van toepassing op een kleine hobbydatabase. Hoe jullie commentaar kunnen hebben op formulieren die je niet gezien hebt ontgaat mij ook. Ik zal voor de laatste keer de keuzes proberen te rechtvaardigen. Ik weet dat je in een profesionele omgeving (db2 of zo) heel anders hiermee omgaat. Ik weet ook dat access geen professionele omgeving is. En wat ik al helemaal weet is dat ik geen DBA ben. Ik weet wel alles over ERDŽs en ontwerpen.
Het leuke van primairy keys is, is dat ze geen enkele andere betekenis hebben dan het record uniek identificeren. Het heeft dan ook niet echt zin om betekenis aan een key te hangen, hij dient slechts om dat record uniek identificeerbaar te maken, en indien opgenomen als FK in een andere tabel, makkelijk met cascades en updates om te gaan.
Gedeeltelijk juist, enige
doel is uniek identificeren. De tabel functie is eigenlijk alleen maar het ŽdomeinŽ voor het veld functie in Rol. Waarom geen domein maar tabel heb ik uitgelegd. Zoals het er nu voor staat zal het enige attribuut inderdaad functienaam zijn. Waarom het geen zin zou hebben dat een PK een betekenis heeft ontgaat mij geheel. Als ik hier een PK functie ID zou toevoegen, leg ik precies dezelfde
informatie vast (niet dezelfde gegevens).
Tuurlijk, het interesseert helemaal geen hol wat je als PK gebruikt, maar waarom zou je het jezelf moeilijk maken door PK's te gaan verzinnen die je ook automagisch kunt laten genereren, waarbij je zeker weet dat er niks mis kan gaan
Tja, en wat gebeurt er als je vergeten bent (zoals jij nu) een unieke index te leggen op functienaam? Juist, dan kan het ook met gegenereerde IDŽs helemaal mis gaan.
Als je je query goed maakt, zal je via de explain zien dat je een select op de tabel maakt waardoor de ID wordt teruggegeven daar zal er precies EEN aan voldoen. Als je die gaat vermenigvuldigen met je koppeltabel kom je bij lange na niet aan de carthegisch product.
Leer hoe een database werkt, of ga geen domme redenen proberen te verzinnen, Doe je dat wel ga je gegarandeerd onderuit, er zijn genoeg mensen hier die redelijk veel ervaring hebben in het ontwerpen van database modellen en er dus wel veel kaas van hebben gegeten.
Ik doel dus op zoŽn query:
Select Film.titel
From Rol, Persoon, Film, Functie
Where Functie.Functienaam = 'acteur'
And Persoon.voornaam = 'robert'
And Persoon.achternaam = 'de niro'
die beperkt wordt door geen id in functie op te nemen tot:
Select Film.titel
From Rol, Persoon, Film
Where Rol.Functienaam = 'acteur'
And Persoon.voornaam = 'robert'
And Persoon.achternaam = 'de niro'
Nogmaals, ik heb er niet veel kaas van gegeten van dat praktische gedoe, maar dit is wat ik ooit in het verre verleden geleerd heb hoe queries werken. Bovendien is ook dit eigenlijk een non-issue dat als tegenargument gebruikt wordt voor andere non-issues
.
Er is helemaal niets wat je weerhoudt van een formulier maken op basis van een text-veld, om vervolgens de primary key van die tabel in de Rol-tabel op te slaan in plaats van de inhoud van het textveld. Dat is nou precies waar zo'n query voor een formulier om draait. Daarmee voorkom je net zo goed dat er foutieve gegevens opgeslagen worden.
Oftewel: het argument van het formulier gaat in geen geval op, want je zult hoe dan ook aan de hand van een 1:n relatie een dropdown moeten maken. Dat is sowieso
SELECT name FROM tabel
of name dan de primary key is of niet, dat is pas interessant wanneer er op "opslaan" geklikt wordt, als je begrijpt wat ik bedoel
Wat me hiervan weerhoudt is de beperking die de topicstarter aangaf, niet al te moeilijk dus.
En dat is niet sowieso een select from, maar gewoon in de eigenschappen van het veld in het formontwerp aangeven dat de rijbron de tabel functie is. Of hier een query achterhangt die dat regelt vind ik niet zo belangrijk, wat belangrijk is dat dit werkt en simpel is.
Moraal van dit verhaal: Ga niet je kennis showen en met moeilijke contructies schermen als de vraagsteller niet op dat niveau kan meekomen. Geef gewoon een simpele oplossing die werkt.
:strip_icc():strip_exif()/u/10274/crop67712295188a6_cropped.jpg?f=community)
:strip_exif()/u/8035/del.gif?f=community)
:strip_exif()/u/22119/ch.gif?f=community)
Waarom lukt dit niet?
:strip_icc():strip_exif()/u/36091/pig.jpg?f=community)
:strip_icc():strip_exif()/u/7418/the_hat_icon.jpg?f=community){kind=icon}
/u/16924/ulli60.JPG?f=community)
) moet er wel goed inzitten.
Hihi... 
. Ik ben maar een informatieanalist die ooit eens met access gestoeid heeft, dus over ontwerpbeslissingen kan ik je nog wel het een en ander vertellen (zou wel moeten met meer dan 10 jaar ervaring 
).
/u/20544/pelle-jjvv-bg.png?f=community)
