waarden uit formulier in meerdere tabellen plaatsen

Status
Niet open voor verdere reacties.

shidan

Gebruiker
Lid geworden
8 jan 2007
Berichten
351
goedenavond,

kan ik de waarden uit 1 formulier in meerdere tabellen plaatsen?
mijn persoon_id is gelijk maar in de ene tabel komt de naam en in de andere komt het adres.
kan dat?

mvg
 
Waarom zou je dat willen?
Slecht idee, niet doen!

Tardis
 
Gegevens die bij elkaar horen zet je in één tabel; dat is de normale werkwijze. Ergo: een tabel met NAW gegegevens zet je in de tabel met persoonsgegevens. Er vanuit gaande dat een persoon maar één (woon)adres heeft. Bij bedrijven heb je vaak ook nog een postadres, dus dan zet je die velden als lose blokken in je tabel met bedrijfsgegevens. Dus dan krijg je de velden [Bezoekadres], [BezoekHuisnummer], [BezoekPC], [BezoekWoonplaats] en [Postadres], [PostHuisnummer], [PostPC] en [PostWoonplaats]. Als voorbeeldje :). Je trekt dit soort gegevens dus nooit uit elkaar. Vandaar: slecht idee.

Leg even uit wat je bedoeling is, voordat we er meer gaten in schieten ;).
 
velden die bij elkaar horen zet je idd in één tabel.
daar een adres kan veranderen zet je het in een andere tabel.
via een tussentabel kun je dan kiezen of een adres een domicilie is of een werkadres of adres van één van de ouders (in geval van scheiding)
idem voor contactgegevens:
in een tabel zet je de contactmiddelen (gsm, gsm2, e-mail, e-mail vader, e-mail moeder, ...
in een andere de contacten (contact_id, persoon_id, contactmiddel_id en data)

mijn tabel is conform met de normaalvormen, dat is geen probleem

ik zou een form willen waar ik diverse data kan plaatsen en deze naar de diverse tabellen stuur
momenteel moet ik teveel formulieren openen (één per tabel)
 
velden die bij elkaar horen zet je idd in één tabel. daar een adres kan veranderen zet je het in een andere tabel.
Dat is een onzin argument. Je eerste zin klopt overigens wel: data die bij elkaar hoort, zet je in één tabel. Zoals Persoons- en NAW gegevens. Het gaat om gegevens die onlosmakelijk aan een entiteit vast zitten. Een adres is zo'n attribuut. Jouw tabellen zijn dus niet conform de normaal normen opgebouwd, want jij splitst atrributen die bij een entiteit horen.
 
En nóg wat: als je van één persson meerdere adressen wilt bijhouden, dan kan dat natuurlijk best simpel gemaakt worden. Ik gaf al aan dat bedrijven vaak meerdere adressen hebben. In dat geval heb je een één-op-veel relatie tussen de tabel tPersoon (of tBedrijf) en de tabel tAdressen, waarbij je in tAdressen alleen het PersoonID opslaat, en (lijkt mij) d.m.v. een keuzelijst aangeeft om wat voor type adres het gaat. Op je formulier frmPersonen heb je dan een subformulier frmAdressen, en die zijn gekoppeld middels PersoonID. Als je dan door je hoofdformulier bladert, krijg je automatisch de juiste adressen te zien van de juiste personen. Sterker nog: als je bij een persoon een nieuw adres toevoegt, wordt automatisch al het PersoonsID ingevuld. Kortom: jouw vraag is overbodig, want wat je nodig hebt, gebeurt al, mits je de db netjes (genormaliseerd) opzet. En ik vermoed dat dit voor 99% van de gevallen bij jou ook het geval gaat zijn.
 
k heb een voorbeeld databank meegestuurd.
je ziet dat ik diverse tabellen gebruik (ook voor contacten)

daar personen kunnen verhuizen, staan de adressen in een andere tabel

kan een form worden gemaakt waarin in de personen en de adressen (eventueel contacten) kan ingeven zodat deze in de bijhorende tabellen komen?
 

Bijlagen

  • voorbeeld.zip
    469 KB · Weergaven: 25
daar personen kunnen verhuizen, staan de adressen in een andere tabel
Weer zo'n (sorry dat ik dit woord gebruik) kulargument; wat is het nut van het bewaren van oude adressen? Als je een adressenbestand hebt voor personen, dan wil je toch nooit brieven sturen naar adressen waar de persoon niet meer woont? Je wilt van een persoon (en dat geldt voor 99,99% van de honderden databases die ik in mijn leven heb gemaakt/beheerd) het huidige adres weten, want dáár stuur je een bericht heen. Wat moet je met oude adressen?

De enige reden die ik kan verzinnen is als je een genealogische database maakt, en je dus de geschiedenis van mensen wilt bewaren. Dan kán het interessant zijn om vast te leggen waar ze gewoond hebben, zodat je geofysische informatie kunt relateren aan de adressen. Maar verder? Alleen maar verwarrend.

cml_id contactmiddel
1 gsm
2 gsm 2
3 gsm vader
4 gsm moeder
5 e-mail
6 e-mail 2
7 e-mail vader
8 e-mail moeder
9 telefoon
10 telefoon 2
11 telefoon vader
12 telefoon moeder
13 e-mail werk


En als je naar dit lijstje kijkt, dan is die dus totaal niet genormaliseerd. Op het moment dat je waarden als gsm en gsm 2 gaat gebruiken, weet je al dat je fout bezig bent. Ik durf te wedden dat gsm 2 exact hetzelfde soort apparaat is, en van exact dezelfde techniek gebruikt maakt als gsm.
Kortom: als het gaat om een tabel Contactmiddelen dan mag er in jouw geval niet meer in zitten dan dit:

cml_id contactmiddel
1 gsm
2 e-mail
3 telefoon


En in je tabel tContacten maak je dan een link met wat voor soort contact het is. En je tabel tLocaties? Waarom staat die los van adressen? Die is toch bij uitstek gerelateerd aan de adressen? Echt, daar klopt dus niets van, en van normalisatie is dus ook geen sprake. Adressen liggen in gemeentes, maar de tabel gemeenten heeft geen enkele relatie met adressen.... SoortenGemeenten idem dito.

Eén tip: begin overnieuw, en teken eerst eens uit voor jezelf wat je met deze database wilt doen. Want dat haal ik er dus ook niet uit. En nog een tip (het is niet voor niets HelpMij): stop ogenblikkelijk met het gebruik van keuzelijsten op basis van tabellen; die horen dus absoluut niet thuis in tabellen, maar wel op formulieren. Gebruik in tabellen alléén keuzelijsten op basis van Waarden.
 
sommige mensen hebben 2 gsm's, prive en werk
ik kan natuurlijk verder normaliseren, maar dit leek mij voldoende
 
locatie staat los van adressen omdat ik zowel de geboorteplaats als de woonplaats wil
 
Je antwoorden wekken niet de indruk dat je weet wat 'normaliseren' inhoudt. Lees daar eens wat over :). Je tabellen zijn namelijk echt niet genormaliseerd. Kijk eens naar jouw tabel Adressen: die bevat dus alleen straatnamen. Dat kan toch niet? Een straat ligt toch altijd in een plaats/gemeente? En een gemeente ligt dan weer in een land (zo'n beetje de enige relatie die klopt in je db). Maar je tabel tLocaties is dus volkomen overbodig, nutteloos en veroorzaakt alleen maar verkeerde adresgegevens.
Ik zou je adressen dus aanpassen, en ik heb er even een plaatje van gemaakt.
relaties.png

Maar nogmaals: bedenk waar je al die adressen voor nodig hebt, en zet, als je toch verder wilt met meerdere adressen per persoon (bedenk ook voor jezelf of je ze vanuit de privacy wetgeving wel mag bewaren) of je oude adressen ook wilt opslaan.
 
En even basaal in een voorbeeldje gekwakt met een formulier. Zoals je ziet, kun je perfect zonder geklooi nieuwe adressen toevoegen, die ook nog eens in bestaande gemeentes vallen. (Als je het Belgische stratenboek uit je hoofd kent natuurlijk).
 

Bijlagen

  • voorbeeld.zip
    166,3 KB · Weergaven: 31
Status
Niet open voor verdere reacties.
Steun Ons

Nieuwste berichten

Terug
Bovenaan Onderaan