OOAD til EER

Normalt vil man oprette en tabel per instantierbar klasse (per ikke-abstrakt
klasse).

Men hvordan håndterer man så at klassen skifter tilstand fx fra eksemplet tilbud til ordre??

Det er en grundregel for objektorienteret design, at et objekt
aldrig kan skifte klasse.

Men jeg formoder at du tænker på noget a la State Pattern !?

Jeg er ikke i tvivl om at hver state skal have sin egen tabel.

Og hvis konteksten også har sin egen tabel. Hvis kontekst tabellen har
de attributter der er fælles for alle states. Og state tabellerne har
de specifikke attributter der addes i den state. Og state tabellerne
har en foreign key til kontekst stabellen.

Så skulle der ikke være redundante data.

Rent praktisk vil din applikation måske performe bedre med en state
attribut. Men fra en strengte teoretisk synsvinkel er den overflødig.

Det du siger om kontekstklassen og hver klasse med hver deres tabel minder lidt om en disjoint nedarvning..

Det kan ikke gøres på den måde eller hva?

Nu tabte du mig.

Det er jeg ked af... :)

Det jeg mente var, at din "lange" kommentars løsning med states, minder om en almindelig disjoint nedarvning. DVS en arvning, hvor kontekstklassen, superklassen, kun kan være én af subklasserne (kun kan være = disjoint). Deraf, salg kan kun være enten tilbud eller en ordre, men kan den så på et senere tidspunkt "skifte" fra tilbud til ordre? Ved du det?

By the way, du har tjent dine point for længe siden :)

I state pattern arver state klasserne ikke fra kontekst klassen.
Kontekst klassen indeholder et interface/abstrakt klasse, som state
klasserne implementerer/arver fra.

Som jeg ser problemet så tilføjes der oplysninger hele tiden.

Grund data oprettes i konrtekst tabellen.

Når tilbudet afsendes så tilføjes der en record i tilbuds tabellen med dato
for tilbud etc..

Når kunden afgiver ordre så tilføjes der en record i ordre tabellen
med dato for ordre etc..

Når varen leveres så tilføjes der en record i leveret tabellen
med dato for levering etc..

[tilsvarende med fakturering og betaling]

Så jeg syne sikke at det ligner disjoint arv.

Korrekt, der afsendes et tilbud, dette godkendes og bliver derfor til en ordre, derefter evt. leveres det.. etc...

disjoint er altså ikke løsningen.. så for at få det hele på plads, hvad mener du så skal gøres? (for lige at få det hele på plads. :-) )

en basis tabel
en tilbud tabel med FK til basis tabel
en ordre tabel med FK til basis tabel
en leveret tabel med FK til basis tabel

strenget taget er det vel ikke et state pattern men snarere lang arve kæde:

basis<-tilbud<-ordre<-leveret

hvor der bliver tilføjet data hele tiden.

State pattern ville komme ind hvis man skulle modelere egenskaberne,
men i databasen er det jo kun data.

Så I koden skulle det nok stadigvæk være State Pattern.

Ok, jeg siger mange tak for hjælpen. Jeg vil se om det kan løse mit problem.. :)

OO & RDBMS er ikke altid lige nemt at få til at gå op i en højere enhed