[SqlServer] on delete cascade, vanuit 2 tabellen op 1 tabel?

[mindcrash]

Probleem is het volgende:

ik ben bezig met het ontwikkelen van een app met een SQL Server backend en een Access frontend. In deze app maak ik gebruik van twee tabellen: 1 met gegevens van personen, en 1 met gegevens van bedrijven. Deze 2 tabellen hebben unieke id's die samengevoegd waarin extra gegevens geplaats kunnen worden die voor zowel bedrijven als personen hetzelfde zijn. Tot nu eigenlijk niets bijzonders

Maar goed, nu wil ik ervoor zorgen dat de gegevens in de onderliggende tabel verwijderd wordt indien de gegevens in 2 van de bovenstaande tabellen ook verwijderd wordt met behulp van een ON DELETE CASCADE. Dit werkt ook prima, maar alleen als er al gegevens in deze tabel aanwezig zijn. Voeg je echter een record toe dan kicked de referentiele integriteit van SQL Server in omdat de id die toegevoegd wordt wel in de ene maar niet in de andere tabel staat (vrij logisch).

Triggers zijn in deze applicatie niet echt een optie omdat Access dan een goedbedoelde melding geeft dat er zonder tussenkomst van de gebruiker gegevens zijn aangepast, maar dat wil ik de eindgebruiker niet aan doen

Is deze referentiele check op een of andere manier uit te schakelen zodat ik records toe kan voegen en verwijderen of weet iemand misschien een andere slimme oplossing? Mijn eigen zoektocht heeft tot nu toe niets opgeleverd...

[whoami]

Uh, 't is toch de bedoeling van foreign key constraints dat je geen child-record kunt toevoegen als er geen record bestaat waar deze naar verwijst?
Het is toch de bedoeling dat je , zegmaar, geen order kunt ingeven voor een niet bestaande klant?

[.oisyn]

even de titel ontcapst, het stond zo schreeuwerig

[Verwijderd]

Ik snap het datamodel niet zo goed. Als je deze problemen tegenkomt is het vaak een aanwijzing dat je datamodel niet lekker in elkaar zit.

Maar goed, het is een kwestie van de juiste volgorde aanhouden. Een record inserten in een child-table terwijl er geen parent is werkt dus niet. Je zal eerst een insert moeten doen in "Bedrijven" en "Personen" daarna kan je met de id's van de nieuwe records een insert doen in de onderliggende tabel met de extra gegevens.

[ Voor 12% gewijzigd door Verwijderd op 30-03-2004 16:26 ]

[Jaspertje]

Dit kan niet, ondanks een goed datamodel.. Je kan niet twee verschillende cascade deletes op een tabel doen (koppeltabel) al vaker geprobeerd, maar kan niet)

Waarom het niet kan, ik heb het weleens gelezen, volgens mij heb ik er ook ooit eens een topic over gestart, ergens op de microsift site staat dat het niet kan

[rml][ SQL Server/SQL]Cascade Delete Foreign Keys[/rml]

zie daar

[ Voor 46% gewijzigd door Jaspertje op 30-03-2004 16:23 ]

[Verwijderd]

whoami schreef op 30 maart 2004 @ 16:09:
Uh, 't is toch de bedoeling van foreign key constraints dat je geen child-record kunt toevoegen als er geen record bestaat waar deze naar verwijst?
Het is toch de bedoeling dat je , zegmaar, geen order kunt ingeven voor een niet bestaande klant?

Het lijkt me inderdaad raar om een referentiele check te omzeilen. Die zit er niet voor niets.
Ik snap niet helemaal wat je precies allemaal wilt.

[mindcrash]

Ik zal het probleem even illustreren met een voorbeeld voor de duidelijkheid:

In de tabel tblPersoon staan records met id's 1,3,5,7 etc.

In de tabel tblBedrijf staan records met id's 2,4,6,8 etc.

Vervolgens heb ik dus een tabel met wat extra data en een veld relatie_id met daarin een van deze waardes. Deze tabel is d.m.v. een foreign key op relatie_id gekoppeld aan zowel tblPersoon en tblBedrijf. So far so good

Nu heb ik de tabel gevuld met gegevens uit zowel tblPersoon als tblBedrijf voordat ik de foreign key heb aangemaakt. Het verwijderen m.b.v. ON DELETE CASCADE gaat nu wel goed maar als ik nieuwe gegevens met een id uit een van deze 2 tabellen toevoeg komt SQL Server / Access met een flinke error betreffende de referentiele integriteit op de proppen omdat een id van tblPersoon niet voorkomt in tblBedrijf en vice versa: "insert statement conflicted with column foreign key constraint "fk_<keynaam>". Error occured in database "mydb" table "<tblBedrijf/tblPersoon>" column "id".

[Jaspertje]

dus je probeert (adv) dit voorbeeld een record toe te voegen waar je een persoon hebt met id 2 (die niet in de reeks staat) zoiets?

[ Voor 4% gewijzigd door Jaspertje op 30-03-2004 16:33 ]

[mindcrash]

Nee, ik probeer een reeds bestaande id uit tblPersoon OF tblBedrijf toe te voegen aan de andere tabel (laten we deze voor het gemak tblDonateur noemen)

[ Voor 20% gewijzigd door mindcrash op 30-03-2004 16:38 ]

[Jaspertje]

Staat dat ID al in die tabel (waar het heen moet)?
Heb je de relatie de goede kan op staan?

[ Voor 55% gewijzigd door Jaspertje op 30-03-2004 16:38 ]

[DanTm]

mindcrash schreef op 30 maart 2004 @ 16:31:
Ik zal het probleem even illustreren met een voorbeeld voor de duidelijkheid:

In de tabel tblPersoon staan records met id's 1,3,5,7 etc.

In de tabel tblBedrijf staan records met id's 2,4,6,8 etc.

Vervolgens heb ik dus een tabel met wat extra data en een veld relatie_id met daarin een van deze waardes. Deze tabel is d.m.v. een foreign key op relatie_id gekoppeld aan zowel tblPersoon en tblBedrijf. So far so good

Nu heb ik de tabel gevuld met gegevens uit zowel tblPersoon als tblBedrijf voordat ik de foreign key heb aangemaakt. Het verwijderen m.b.v. ON DELETE CASCADE gaat nu wel goed maar als ik nieuwe gegevens met een id uit een van deze 2 tabellen toevoeg komt SQL Server / Access met een flinke error betreffende de referentiele integriteit op de proppen omdat een id van tblPersoon niet voorkomt in tblBedrijf en vice versa: "insert statement conflicted with column foreign key constraint "fk_<keynaam>". Error occured in database "mydb" table "<tblBedrijf/tblPersoon>" column "id".

dit is i.d.d. niet mogelijk.. je hebt binnen een tabel (zeg tblExtra) een afhankelijkheid gecreerd naar 2 andere tabellen, als je een entry wilt aanmaken in tblExtra zul er dus al een entry moeten bestaan in beide andere tabellen.

Mogelijke oplossingen zijn de id van tblExtra op te nemen in zowel tblPersoon als tblBedrijf (dan moet je wel eerst een tblExtra aanmaken voordat je een tblPersoon of tblBedrijf entry kunt aanmaken), de cascading delete werkt dan echter niet...
ander mogelijkheid is een soort base tabel aan te maken (tblBase), hier komen alle personen en bedrijven in te staan (met 1 unieke id), de verdere gegevens van deze personen/bedrijven sla je gewoon op in respectievelijk tblPersoon/tblBedrijf, en de extra gegevens in tblExtra, deze 3 tabellen krijgen allemaal de id van tblBase. FF cascading deletes aanzetten, en als je dan een entry uit tblBase verwijderd verwijderd hij alle mogelijke gekoppelde gegevens...

hoop dat het een beetje duidelijk is...

[Verwijderd]

Je bedoelt dat je iets hebt als,

tblPersoon(relatie_id, ...)
tblBedrijf(relatie_id,...)
tblGegevens(gegeven_id, relatie_id, naam, telefoonnr, fax)

en die relatie_id verwijst naar 1 van die 2?

Is het niet mogelijk iets meer in de zin van....
P(pers_id,...)
B(bedr_id,...)
Gegevens(geg_id, p_id, b_id, naam, tel)
en dan
foreign key (p_id) reference (pers_id) on P,
foreign key (b_id) reference (bedr_id) on B,

Zorgen dat ze null mogen zijn
en vervolgens dus die on delete cascade aan zowel p_id als aan b_id hangen?

Misschien praat ik onzin hoor... ben geen expert

[ Voor 61% gewijzigd door Verwijderd op 30-03-2004 16:44 ]

[cameodski]

Ik denk dat je in tblExtra (of heet ie nou tblDonateur) een veld BedrijfID en PersoonID moet opnemen. Vervolgens bij beiden de optie ALLOW NULL aanzetten en je cascade delete zou gewoon moeten werken.

Net iets te laat.

[ Voor 5% gewijzigd door cameodski op 30-03-2004 16:44 ]

[mindcrash]

Hij staat nog niet in de tabel nee... het is een soort kip en ei probleem, als je een id uit tblPersoon toevoegt gaat de FK van tblBedrijf klagen en als je een id uit tblBedrijf toevoegt dan gaat de FK van tblPersoon klagen... en qua logica klopt dat ook wel, ik wil alleen maar dat hij niet meer klaagt (maar als je de optie enforce relationships uitschakeld dan klaagt hij dus niet, maar dan heb je ook geen on delete cascade's meer volgens het diagram ontwerp venster... en dat wil ik dus eigenlijk niet )

[Verwijderd]

mindcrash schreef op 30 maart 2004 @ 16:43:
Hij staat nog niet in de tabel nee... het is een soort kip en ei probleem, als je een id uit tblPersoon toevoegt gaat de FK van tblBedrijf klagen en als je een id uit tblBedrijf toevoegt dan gaat de FK van tblPersoon klagen... en qua logica klopt dat ook wel, ik wil alleen maar dat hij niet meer klaagt (maar als je de optie enforce relationships uitschakeld dan klaagt hij dus niet, maar dan heb je ook geen on delete cascade's meer volgens het diagram ontwerp venster... en dat wil ik dus eigenlijk niet )

Maar tblPersoon en tblBedrijf zijn toch niet de tabellen die de FK's bevatten. Dat is toch die derde tabel?

cameodski schreef op 30 maart 2004 @ 16:43:
Net iets te laat.

Sorry

[ Voor 10% gewijzigd door Verwijderd op 30-03-2004 16:48 . Reden: cameodski stangen ]

[DanTm]

cameodski schreef op 30 maart 2004 @ 16:43:
Ik denk dat je in tblExtra (of heet ie nou tblDonateur) een veld BedrijfID en PersoonID moet opnemen. Vervolgens bij beiden de optie ALLOW NULL aanzetten en je cascade delete zou gewoon moeten werken.

Net iets te laat.

opties met null waarden werken wel.. maar zijn niet echt netjes (als je je database tenminste een beetje genormaliseerd wilt hebben).

[cameodski]

DanTm schreef op 30 maart 2004 @ 16:48:
opties met null waarden werken wel.. maar zijn niet echt netjes (als je je database tenminste een beetje genormaliseerd wilt hebben).

Ik ben benieuwd of jij een nettere oplossing weet.

[Verwijderd]

DanTm schreef op 30 maart 2004 @ 16:48:
[...]


opties met null waarden werken wel.. maar zijn niet echt netjes (als je je database tenminste een beetje genormaliseerd wilt hebben).

Tja, we hebben niet genoeg info om een fatsoenlijk genormaliseerd model te maken, dus is de null value de meest voor de hand liggende oplossing denk ik.
Ik zou niet zo snel bedenken om bedrijfsgegevens en persoonsgegevens in 1 tabel te stoppen.

Andere oplossing is de FK naar een relatie i.c.m. een type_relatie_id te maken. Dan blijft hij uniek en hoef je die andere tabellen ook niet zo'n rare nummering te geven zoals {2,4,6,8...} ... ?

[mindcrash]

Verwijderd schreef op 30 maart 2004 @ 16:46:
[...]

Maar tblPersoon en tblBedrijf zijn toch niet de tabellen die de FK's bevatten. Dat is toch die derde tabel?


[...]

Klopt... de 3e tabel bevat FK's naar zowel tblBedrijf en tblPersoon op de kolom relatie_id.

Maar goed, in deze vorm gaat het blijkbaar dus absoluut niet werken dus ik ga even met het datamodel en VBA code aan de slag... best leuk zo net voor een deadline

[ Voor 7% gewijzigd door mindcrash op 30-03-2004 16:55 ]

[cameodski]

mindcrash schreef op 30 maart 2004 @ 16:54:
Klopt... de 3e tabel bevat FK's naar zowel tblBedrijf en tblPersoon op de kolom relatie_id.

Dus je hebt in de 3e tabel een kolom waarop een foreign key ligt die zowel naar tblPersoon als naar tblBedrijf refereert?
Dan kan ik me voorstellen dat SQL Server begint te klagen.

Wat je nog wel zou kunnen doen, is de relaties omdraaien en de derde tabel als basis nemen. Als je daar dan een record verwijderd, wordt er automatisch in tblBedrijf of tblPersoon ook het één en ander verwijderd.

[ Voor 23% gewijzigd door cameodski op 30-03-2004 16:59 ]

[Jaspertje]

Je hebt dus een tabel waarin zowel de gegevens van de persoon als van het bedrijf staan (alleen apparte rijen) Dan zou ik het toch netjes doen en twee apparte kolommen aanmaken waarbij je dan wel alles dubbel hebt ja, maar een bedrijf heeft misschien weer meerdere locaties e.d. en een persoon niet

Zouden het allebei 1_op_1 relaties zijn? (nee hoop ik)

Maar als je het in een tabel wilt doen, zijn die null waardes wel de oplossing denk ik

[DanTm]

cameodski schreef op 30 maart 2004 @ 16:51:
[...]

Ik ben benieuwd of jij een nettere oplossing weet.

heb ik al hierboven gepost

1 basis tabel tblRelatie (met b.v. alleen een relatie id en een type (persoon/bedrijf))
1 tabel tblPersoon (met de relatie_id uit 1ste tabel)
1 tabel tblBedrijf (met de relatie_id uit de 1ste tabel)
1 tabel tblExtra (met de relatie_id uit de 1ste tabel)

deze oplossing is met name handig als je e.a. objectgeorienteerd wilt implementeren....

maar voor de snelle oplossing.. gebruik de null waarden oplossing, of sla de key van de extra gegevens op in de persoons/bedrijf tabel (en delete de extra gegevens via een trigger, of gewoon netjes via code/stored procedure)

[mindcrash]

Hierbij trouwens een deel van mijn huidige datamodel... misschien schept dit wat meer licht in de duisternis :

tblPersoon
--------------
id (primary key)
voorletters
tussenvoegsels
achternaam
adres
woonplaats
telefoonnummer etc.

tblBedrijf
-----------
id (primary key)
naam
adres
postcode
woonplaats
telefoonnummer etc.

tblDonateur
-------------
id (primary key)
relatie_id (de beruchte foreign key)
etc.

tblDonatie
-------------
id (primary key)
donateur_id (primary key)
bedrag

[ Voor 9% gewijzigd door mindcrash op 30-03-2004 17:04 ]

[Jaspertje]

Waaom heb je een verschil gemaakt tussen persoon en bedrijf?

Had een veld bedrijf (ja/nee ) niet makkelijker geweest in dit geval?

[Verwijderd]

DanTm schreef op 30 maart 2004 @ 17:00:
[...]


1 basis tabel tblRelatie (met b.v. alleen een relatie id en een type (persoon/bedrijf))
1 tabel tblPersoon (met de relatie_id uit 1ste tabel)
1 tabel tblBedrijf (met de relatie_id uit de 1ste tabel)
1 tabel tblExtra (met de relatie_id uit de 1ste tabel)

Dit had ik inderdaad ook in gedachten. Lijkt me de meest nette oplossing. Of het voor TS de beste/snelste is, is een ander verhaal.

Succes met nieuwe model maken mindcrash.

[mindcrash]

Jaspertje schreef op 30 maart 2004 @ 17:04:
Waaom heb je een verschil gemaakt tussen persoon en bedrijf?

Had een veld bedrijf (ja/nee ) niet makkelijker geweest in dit geval?

mind the "etc." - ik sla voor bedrijven een set gegevens op die totaal verschillend zijn dan bij een persoon... zo heeft een bedrijf wel een postadres en een persoon niet, en meer van dat soort dingen.

[cameodski]

DanTm schreef op 30 maart 2004 @ 17:00:
heb ik al hierboven gepost

Oeps, niet goed opgelet

mindcrash schreef op 30 maart 2004 @ 17:02:
Hierbij trouwens een deel van mijn huidige datamodel... misschien schept dit wat meer licht in de duisternis :

tblPersoon
--------------
id (primary key)
voorletters
tussenvoegsels
achternaam
adres
woonplaats
telefoonnummer etc.

tblBedrijf
-----------
id (primary key)
naam
adres
postcode
woonplaats
telefoonnummer etc.

tblDonateur
-------------
id (primary key)
relatie_id (de beruchte foreign key)
etc.

tblDonatie
-------------
id (primary key)
donateur_id (primary key)
bedrag

Mmm, het begint er verdacht veel op te lijken dat je relaties tussen tblDonateur, tblPersoon en tblBedrijf precies de andere kant op moeten.
Dus in tblBedrijf en tblPersoon een DonateurID opnemen en je relatie_id verwijderen uit tblDonateur en je probleem is helemaal opgelost.

[DanTm]

mindcrash schreef op 30 maart 2004 @ 17:06:
[...]


mind the "etc." - ik sla voor bedrijven een set gegevens op die totaal verschillend zijn dan bij een persoon... zo heeft een bedrijf wel een postadres en een persoon niet, en meer van dat soort dingen.

als de bedoeling van de applicatie is om alleen donateurs te registreren (en geen losse bedrijven/personen), dan zou ik de tblDonateur gewoon leidend maken. Dus de primary key van tblDonateur bij tblPersoon/tblBedrijf toevoegen (is hier ook al eerder geopperd), als je de donateur dan verwijderd, verwijderd hij de daaraangekoppelde persoon/bedrijf (wel ff een type toevoegen aan tblDonateur).

ik zie dat ik sneller moet posten vorige bericht geeft dezelfde oplossing.

[ Voor 7% gewijzigd door DanTm op 30-03-2004 17:12 ]

[mindcrash]

cameodski schreef op 30 maart 2004 @ 17:09:
Mmm, het begint er verdacht veel op te lijken dat je relaties tussen tblDonateur, tblPersoon en tblBedrijf precies de andere kant op moeten.
Dus in tblBedrijf en tblPersoon een DonateurID opnemen en je relatie_id verwijderen uit tblDonateur en je probleem is helemaal opgelost.

Hm, dat zou inderdaad eens kunnen kloppen ja

Dus i.p.v. een bestaand relatie te koppelen aan een nieuw donateurs record moet ik dus eigenlijk een nieuw donateurs record koppelen aan een reeds bestaand relatie record... pff had ik eigenlijk ook zelf wel kunnen bedenken

Laten we het ermaar op houden dat het nogal een erg lange (lees: smorgens vroeg 9 tot s'avonds laat 10) week was... dan kan je neurale processor het op den duur niet meer aan he?

Anyway, ik ga aan de slag... bedankt voor de hulp mensen

[Verwijderd]

Zoiets dus...

Persoon(pers_id, naam, etc)
Bedrijf(bedr_id, naam, etc)
Pers-don(pers_id, don_id)
Bedr-don(bedr_id, don_id)
Donatie(don_id, bedrag)

Als je de gegevens van persoon en bedrijf ook los wilt bewaren.

of

don_id bij Persoon en Bedrijf en de koppeltabellen weglaten als dat niet zo is.


Hm beetje slome reactie zie ik..

[ Voor 33% gewijzigd door Verwijderd op 30-03-2004 17:32 . Reden: slome reply.. ]

[mindcrash]

Verwijderd schreef op 30 maart 2004 @ 17:25:
Zoiets dus...

Persoon(pers_id, naam, etc)
Bedrijf(bedr_id, naam, etc)
Pers-don(pers_id, don_id)
Bedr-don(bedr_id, don_id)
Donatie(don_id, bedrag)

Nee,

Persoon (id, voornaam, etc., (f)donateur_id)
Bedrijf (id, naam, etc., (f)donateur_id)
Donateur (id, blablabla)

- en vervolgens niet een koppeling leggen naar je relatiegegevens in je donateursgegevens, maar een koppeling leggen vanuit je relatiegegevens naar je donateurgegevens

snap je?

(ik had de volgorde qua koppelen omgedraaid... nogal dom zeg maar... maar ja iedereen maakt weleens een fout waarbij je later bijna de behoefte hebt om te doen )

[ Voor 12% gewijzigd door mindcrash op 30-03-2004 17:37 ]

[Verwijderd]

mindcrash schreef op 30 maart 2004 @ 17:33:
[...]
- en vervolgens niet een koppeling leggen naar je relatiegegevens in je donateursgegevens, maar een koppeling leggen vanuit je relatiegegevens naar je donateurgegevens

snap je?

Persoon(pers_id, naam, etc)
Bedrijf(bedr_id, naam, etc)
Pers-don(pers_id, don_id)
Bedr-don(bedr_id, don_id)
Donatie(don_id, bedrag)

Mja, dit was een omslachtige manier van hetzelfde nut toch?

[ Voor 38% gewijzigd door Verwijderd op 30-03-2004 17:42 ]

[cameodski]

Verwijderd schreef op 30 maart 2004 @ 17:34:

Persoon(pers_id, naam, etc)
Bedrijf(bedr_id, naam, etc)
Pers-don(pers_id, don_id)
Bedr-don(bedr_id, don_id)
Donatie(don_id, bedrag)

Mja, dit was een omslachtige manier van hetzelfde nut toch?

Dat lijkt er niet helemaal op:
1. Waar is tblDonateur gebleven.
2. Als je een donateur weg wilt gooien, moet je nu toch echt meerdere queries gaan uitvoeren.

[DanTm]

mindcrash schreef op 30 maart 2004 @ 17:33:
[...]


Nee,

Persoon (id, voornaam, etc., (f)donateur_id)
Bedrijf (id, naam, etc., (f)donateur_id)
Donateur (id, blablabla)

- en vervolgens niet een koppeling leggen naar je relatiegegevens in je donateursgegevens, maar een koppeling leggen vanuit je relatiegegevens naar je donateurgegevens

snap je?

(ik had de volgorde qua koppelen omgedraaid... nogal dom zeg maar... maar ja iedereen maakt weleens een fout waarbij je later bijna de behoefte hebt om te doen )

lijkt mij prima zo... let wel.. je kunt nu geen personen/bedrijven aanmaken zonder eerst een donateur aan te maken.

[Verwijderd]

cameodski schreef op 30 maart 2004 @ 17:42:
[...]

Dat lijkt er niet helemaal op:
1. Waar is tblDonateur gebleven.
2. Als je een donateur weg wilt gooien, moet je nu toch echt meerdere queries gaan uitvoeren.

Jep klopt... Ik ben op 't einde een beetje van het goede pad afgeslagen.

Persoon(pers_id, naam, etc, donateur_id)
Bedrijf(bedr_id, naam, etc, donateur_id)
Donateur(donateur_id, donatie_id)
Donatie(donatie_id, bedrag)

Zo moest ie inderdaad zijn gewoon...

[Verwijderd]

DanTm schreef op 30 maart 2004 @ 17:44:
[...]


lijkt mij prima zo... let wel.. je kunt nu geen personen/bedrijven aanmaken zonder eerst een donateur aan te maken.

Volgens mij was dat de reden dat ik een beetje van slag raakte. Ergens leek het me niet een 100% logisch model. Maargoed....

[ Voor 3% gewijzigd door Verwijderd op 30-03-2004 17:47 ]

[DanTm]

Verwijderd schreef op 30 maart 2004 @ 17:44:
[...]

Jep klopt... Ik ben op 't einde een beetje van het goede pad afgeslagen.

Persoon(pers_id, naam, etc, donateur_id)
Bedrijf(bedr_id, naam, etc, donateur_id)
Donateur(donateur_id, donatie_id)
Donatie(donatie_id, bedrag)

Zo moest ie inderdaad zijn gewoon...

lijkt me toch niet .. nu kan een donateur maar 1 donatie doen, als dat het geval is kun je het donatie bedrag ook gewoon bij de donateur opslaan...
dus die donatie_id uit donateur, en bij donatie de donateur_id erin

Verwijderd schreef op 30 maart 2004 @ 17:46:
[...]

Volgens mij was dat de reden dat ik een beetje van slag raakte. Ergens leek het me niet een 100% logisch model. Maargoed....

volgende keer gewoon eerst een berichtje posten met wat je app moet gaan doen en hoe je denkt dat het datamodel moet worden... dan kunnen we er gewoon allemaal gezamelijk over denken suc6 in iedergeval

[ Voor 27% gewijzigd door DanTm op 30-03-2004 17:58 ]

[Verwijderd]

DanTm schreef op 30 maart 2004 @ 17:56:
[...]


lijkt me toch niet .. nu kan een donateur maar 1 donatie doen, als dat het geval is kun je het donatie bedrag ook gewoon bij de donateur opslaan...
dus die donatie_id uit donateur, en bij donatie de donateur_id erin

Ik ben het met je eens dat inderdaad die donateur_id gewoon bij donatie erbij kan. Ben lekker overbodig bezig.
Maar dat een donateur nu maar 1 donatie kan doen is niet waar toch? De PK is een combinatie van donateur_id en donatie_id, en dus kan donateur_id gewoon meerdere keren voorkomen.
De koppeltabel is alleen niet nodig.
Toch?

[...]


volgende keer gewoon eerst een berichtje posten met wat je app moet gaan doen en hoe je denkt dat het datamodel moet worden... dan kunnen we er gewoon allemaal gezamelijk over denken suc6 in iedergeval

Uh, het was niet mijn probleem hoor.

[mindcrash]

DanTm schreef op 30 maart 2004 @ 17:44:
[...]


lijkt mij prima zo... let wel.. je kunt nu geen personen/bedrijven aanmaken zonder eerst een donateur aan te maken.

Dat was ook niet de bedoeling... je bent namelijk als gebruiker... ehm laat ik het anders zeggen... ik verplicht de gebruiker om in het donateur scherm een record aan een reeds bestaande relatie te koppelen... aangezien ik vanaf het koppel formulier wat de gebruiker bij het koppelen voor z'n neus krijgt een referentie (id dus) krijg naar een reeds bestaand bedrijf of bestaande persoon kan ik vervolgens dat specifieke record updaten met het id van dit record in de donateurstabel... en klaar is mind