[UML/(My)SQL] Generalisatie in database

[Jelmer]

Ik loop net tegen een probleem aan dat ik een bepaalde afgeleide klasse in de database wil opslaan. Nu zoek ik een nette manier om dit te bewerkstelligen, aangezien SQL dit niet ondersteund naar mijn weten.

Even wat meer info; Ik heb een klasse die algemene info van een factuur bevat (zoals het id en de datum) en een afgeleide klasse RegiebonFactuur (bevat wat extra dingen). Later komen er nog andere typen facturen bij, dus daarom lijkt mij deze constructie het verstandigst.

Zelf zat ik te denken om het zo op te lossen:
Factuur: id, factuurDatum
RegieFactuur: <id@Factuur>,<RegieBon>

Maar om eerlijk te zijn vind ik dat een beetje vuile oplossing, ookal denk ik zelf dat het wel de enige is.. Toch zou ik van jullie hier graag wat commentaar op willen hebben hoe ik dit misschien wat netter kan oplossen.

[SJR]

Wat vind je er precies 'vuil' aan? Volgens mij is het redelijk gegeneraliseerd.
Voorbeeld:

code:

factuur
---
factuurID
datum

factuur1
---
factuur1ID
factuurID
factuur1 element 1
factuur1 element 2

factuur2
---
factuur2ID
factuurID
factuur2 element 1
factuur2 element 2
factuur2 element 3

Beperking is wel dat je alle facturen moet baseren op de hoofd factuur, en moeilijk een subfactuur op een subfactuur kan baseren.

[Goodielover]

Het handigst gaat dit met alles in 1 tabel te mappen.
Met een apart type veld houd je bij welke subtype je in het record hebt opgeslagen.
Je maakt dus 1 grote tabel waarbij bepaalde velden alleen gevuld worden als het type veld een bepaalde waarde bevat.
Op die manier kan je gemakkelijk op het hoogeste typeniveau alles in 1 keer selecteren.
Voor de subtypen maak je toch aparte schermen, dus daar kan je ook een aparte query voor schrijven of de info op de achtergrond bewaren bij de eerste query.
Snappie?

[Jelmer]

Heb er nog eens een nachtje over geslapen en ik houd het toch maar zoals ik het had uit gedacht. Eigenlijk zou het nu mooi geweest zijn als ik een OODBMS zou hebben, alleen heb ik nog geen gratis versie kunnen vinden en blijf daarom maar bij een RDBMS als MySQL.

[Verwijderd]

Op donderdag 14 maart 2002 11:28 schreef Jelmer Barhorst het volgende:
Heb er nog eens een nachtje over geslapen en ik houd het toch maar zoals ik het had uit gedacht. Eigenlijk zou het nu mooi geweest zijn als ik een OODBMS zou hebben, alleen heb ik nog geen gratis versie kunnen vinden en blijf daarom maar bij een RDBMS als MySQL.

Je oplossing is prima hoor. Tis een 1-1 parent-child relatie en die sla je idd op door bij het child het id van de parent op te nemen.

[Goodielover]

Op donderdag 14 maart 2002 11:49 schreef Melvin het volgende:

[..]

Je oplossing is prima hoor. Tis een 1-1 parent-child relatie en die sla je idd op door bij het child het id van de parent op te nemen.

Tis helemaal niet prima hoor. 1-1 relaties sla je plat in 1 tabel. Het is een over-normalisatie die helemaal niet nodig is.
De meeste DBMS-en kunnen mbv van triggers ook alle contraints die je op de velden zou willen leggen gewoon aan.
Doe het niet, je database wordt nodeloos ingewikkeld.
Je inserts van een object worden er direct 2 of meer. subtype zijn niet gemakkelijke te bepalen, je outerjoined je rot. dit geeft een slechtere performance. Update moet je verdelen over meerdere tabellen. Afhankelijkheden tussen velden over meerdere types zijn lastig door een DBMS te checken...........

[Verwijderd]

Op donderdag 14 maart 2002 12:01 schreef Goodielover het volgende:

[..]

Tis helemaal niet prima hoor. 1-1 relaties sla je plat in 1 tabel. Het is een over-normalisatie die helemaal niet nodig is.
De meeste DBMS-en kunnen mbv van triggers ook alle contraints die je op de velden zou willen leggen gewoon aan.
Doe het niet, je database wordt nodeloos ingewikkeld.
Je inserts van een object worden er direct 2 of meer. subtype zijn niet gemakkelijke te bepalen, je outerjoined je rot. dit geeft een slechtere performance. Update moet je verdelen over meerdere tabellen. Afhankelijkheden tussen velden over meerdere types zijn lastig door een DBMS te checken...........

En wat met Facturen die geen RegieFacturen zijn, maar gewone Facturen zonder een subtype ? Of een ander type Factuur ? Dat kan je toch niet allemaal in 1 tabel gaan duwen en dan de velden van het andere type allemaal leeg laten ?
Als je echt geen joins wil, moet je dan voor elke type Factuur een andere tabel gaan maken, maar dat is dan weer niet netjes voor je overervings structuur...