Sleutelvelden instellen

[JohnBoy]

Ik wil een database gaan opzetten voor groepsvervoer.
Deze moet straks minimaal de volgende tabellen gaan bevatten; Deelnemers, Routes, Instellingen, Opdrachtgevers.
Nu wil ik dat in de tabel deelnemers ieder individu maar een keer voor kan komen. Dus Jan Janssen met postcode 0000 XX op huisno 15 kan maar 1x in de tabel voorkomen. Is het dan verstandig om Voornaam, Achternaam, Postcode, Huisno, als meervoudig sleutelveld aan te maken en weet ik dan zeker dat die persoon maar 1x voor kan komen???? of moet ik dit op een andere manier gaan regelen????



Johnboy

 

[thomrob]

Dat zou wel heel erg veilig zijn. Een persoon zou dan niet meer dan 1 keer voor kunnen komen

Echter een uniek deelnemersnummer als sleutelveld zou ook moeten volstaan als je met een een beetje beleid en een beetje datamodel te werk gaat!

heb je er al over nagedacht hoe je een route data-technisch vorm wilt geven?

 

[JohnBoy]

ThomRob

Natuurlijk heb ik er al verder over nagedacht. Maar omdat de data ingegeven zal gaan worden door een of andere "tiepgeit", en deze gegevens vanaf een excelsheet moet halen, en omdat hierin deelnemers op meerdere sheets kunnen voorkomen had ik het bovenstaande bedacht. Dan weet ik dus inderdaad zeker dat ik over unieke individueen praat. Begrijp je mijn dilemma dus??

Ter info:
Tabel deelnemers zal voor zich spreken (Normale naw gegevens met een extra memoveld oid.
Tabel routes: Uniek routenummer wat als volgt is opgebouwd:
100-110-1-2-1
100=Nummer opdrachtgever(Tbl opdrachtgevers)
110=Nummer instelling(Tbl Instellingen)
1=Nummer van de routes per instelling(1 tm XX)
2=Nummer vd weekdag(1=Ma;2=Di;3=Wo; enz)
1=Dagdeel(1=am;2=pm;3=deeltijd am;4=deeltijd pm)

De uiteidelijke database moet dus resulteren in een totale planning voor vervoer.

 

[digi]

Ik denk dat je schijn-veiligheid creëert als je een viervoudig sleutelveld gebruikt: een verkeerd getypte letter in de voor- of achternaam, of tussenvoegels voluit of afgekort maakt je sleutel onbruikbaar. Ik denk dat je beter kunt volstaan met controle op postcode en huisnummer en dan vragen of de gegevens hetzelfde zijn.
Het lijkt me ook niet goed voor de performance en de overzichtelijkheid om vier velden samen als sleutel te gebruiken.
Overigens wel jammer dat je over 'tiepgeiten' praat. Als je je programma gebruiksvriendelijk maakt en goede aanwijzingen aan de gebruiker geeft bij problemen, dan gaan de gebruikers zelf wél nadenken over wat ze invoeren en wordt hun werk leuker en worden de resultaten beter. Je hebt het voor jouw situatie nodig dat de gebruiker meedenkt.

 

[thomrob]

Entiteit Relatie Diagram

heb je al een ERD van je omgeving en je planning uitgetekend?

 

[JohnBoy]

Digi, ThomRob

Sorry voor de late reactie, je weet wel druk, druk ,druk,

De benaming "tiepgeit"is helemaal niet negatief bedoeld, maar dat is voor ons een andere benaming voor "data-entry-medewerkers". Ik denk trouwens dat je wel gelijk hebt als je stelt dat het schijnveiligheid is met vier sleutelvelden nu ik hier verder over heb kunnen nadenken.
De ERD moet nog komen, de opzet zit op dit moment nog voornamelijk(of alleen) in mijn grijze cellen. Ik wil dit in mijn vakantie verder op papier gaan zetten