[MySQL] Insert op joined tables i.v.m. FK constraints

[Paul C]

Ik heb de volgende tabellen:

bedrijf_contactpersonen.c_bedrijf_id is een foreign key niet null
bedrijven.b_hoofdcontactpersoon is een foreign key niet null

Nu wil ik echter een nieuw bedrijf met contactpersoon toevoegen, maar dat wil niet lukken omdat voor beide tabellen de FK ontbreekt. Ik heb al gegoogled en gekeken of ik de tabellen kan joinen en dan inserten, maar dat heeft niets zinnigs opgeleverd. Kan dit überhaupt wel?

Het betreft hier MySQL 5.1.37

[Staatslot]

En als je in bedrijf_contactpersoon nou eens is_hoofdcontact opneemt, dan kun je eerst de bedrijven vullen en daarna de contactpersonen.. Ga ik er wel vanuit dat een contactpersoon maar van 1 bedrijf hoofdcontactpersoon is natuurlijk..

[sig69]

-Wat Staatslot zegt
-Of je kan hoofdcontactpersoon nullable maken, vervolgens bedrijf inserten, contactpersoon inserten, bedrijf updaten met contactpersoon
-Of je kan een koppeltabel tussen beide tabellen maken (dan kan een persoon ook contactpersoon zijn bij meerdere bedrijven) met daarin een boolean is_hoofdcontactpersoon

De laatste heeft mijn persoonlijk voorkeur

[ Voor 4% gewijzigd door sig69 op 08-04-2011 12:28 ]

[Paul C]

Ja, dat zijn ook oplossingen waar ik aan heb zitten denken, maar ik heb expres alles in InnoDB gedaan en op een manier dat dit soort dingen door het ontwerp van het datamodel afgedwongen wordt. Een contactpersoon is wel van één bedrijf (bedrijf 1 - 1n contactpersoon) , maar dan verplicht ik niet meer dat een bedrijf een hoofdcontactpersoon heeft.

Als het niet kan, dan zal ik waarschijnlijk hoofdcontactpersoon nullable maken, maar ik wil weten of het zo op te lossen is?

[Staatslot]

Ik durf niet te zeggen of het wel kán, maar ik vraag me af of je dat op die manier moet willen oplossen.
Het afvangen van fouten waarbij bedrijven geen contactpersoon hebben kun je in mijn opinie netjes afvangen via je GUI, daarna wordt de correcte data weggeschreven naar MySQL.

Maar wellicht kunnen experts op MySQL gebied hier op tweakers je nog meer vertellen over de door jou aangehaalde contructie?

[ Voor 3% gewijzigd door Staatslot op 08-04-2011 12:48 ]

[NMe]

Je hebt een rondgang tussen je tabellen en dat is zelden tot nooit een goed idee. De eerste tip van Staatslot is de enige juiste: laat alle verwijzingen via de contactpersonentabel lopen middels een link naar het bedrijfs-id, voeg een veldje "isHoofdcontact" toe, en haal het hoofdcontactpersoon-id weg uit de bedrijfstabel. Wel of geen InnoDB gebruiken heeft daar verder niets mee te maken.

[Paul C]

Oké NMe, dat is een duidelijk antwoord! Dan ga ik het zo aanpassen.

Iedereen bedankt voor de antwoorden!

[drm]

NMe:
Je hebt een rondgang tussen je tabellen en dat is zelden tot nooit een goed idee. De eerste tip van Staatslot is de enige juiste: laat alle verwijzingen via de contactpersonentabel lopen middels een link naar het bedrijfs-id, voeg een veldje "isHoofdcontact" toe, en haal het hoofdcontactpersoon-id weg uit de bedrijfstabel. Wel of geen InnoDB gebruiken heeft daar verder niets mee te maken.

Je bent hier onterecht nogal stellig. Het is namelijk helemaal niet "de enige juiste" oplossing. In jouw geval moet je namelijk ook een constraint op de tabel gaan leggen die aangeeft dat er maximaal 1 persoon per bedrijf de hoofdcontactpersoon mag zijn, wat niet alleen een lastigere constraint is, het is ook geen eigenschap van de contactpersoon maar een eigenschap van de relatie tussen de contactpersoon en het bedrijf. Als een contactpersoon van bedrijf verandert, moet het veld vervolgens ook veranderen en dat is allemaal veel ingewikkelder dan de relatie te leggen als "bedrijf heeft hoofdcontactpersoon". Je laat met jouw oplossing de constraint dat een bedrijf maar 1 contactpersoon mag hebben immers ook vallen, die in de oplossing van de topicstart wel eenvoudig af te dwingen is; het is namelijk maar 1 veld met een foreign key.

De recurrente relatie is op zich niet per se verkeerd, je moet alleen kiezen: of een bedrijf kan bestaan zonder hoofdcontactpersoon, of een persoon kan bestaan zonder een bedrijf. De FK's worden dan gewoon nullable en de referential constraint kan gewoon blijven bestaan. De laatste optie (c_bedrijf_id nullable) lijkt me het beste, aangezien je dan ook een ON DELETE SET NULL op de foreign key constraint kunt zetten. Je kunt dan wel heel eenvoudig afdwingen (on delete restrict) dat een contactpersoon niet verwijderd mag worden als hij de hoofdcontactpersoon is van een bedrijf.

[The Eagle]

Wat bij Oracle ook gewoon werkt is een simple view. Als jij een view hebt over alle keys van beide tabellen, kun je de view in Oracle in 1x updaten. Vereist wel dat er geen functiebewerkingen of subselects oid in de view zitten. Weet niet of MySQL ook zoiets biedt?

Maar verder wat al eerder gezegd is: ik zou je datamodel eens herzien.