Database Design probleem

[Verwijderd]

Ik heb een situatie waarbij ik het niet voor elkaar krijg om de database netjes in te delen. Zie:



Ik ben bezig met een web based informatie beheer systeem waarbij pagina's opgedeelt zijn in blokken, deze blokken moeten opgevuld kunnen worden met een willekeurig type blok zoals bijvoorbeeld een gegevens lijst, formulier, tree of een iframe. Het moet ook mogelijk zijn later eenvoudig nieuwe blok types toe te voegen.

Het probleem wat hier ontstaat is de koppeling tussen een blok op de pagina, en een blok type, zo heeft elk type blok weer andere parameters( een formulier wil bijvoorbeeld het id weten van een record in de form tabel waarmee vervolgens het formulier opgebouwd kan worden, een lijst vrijwel hetzelfde alleen dan voor de list tabel, een iframe heeft echter een url nodig, en als er later andere types bij kunnen komen dan kan ik nu nog niet bepalen wat er daar voor informatie nodig is om het blok op te bouwen ).

Ik wil het zo maken dat een gebruiker bij het aanmaken van een pagina blok de keuze krijgt uit alle beschikbare blokken en daarvoor lijkt het me essentieel dat deze in een tabel opgeslagen worden, namelijk de tabel block. De vraag is nu echter, hoe ga ik dit netjes in de database opslaan?

Voor zover ik kan bedenken is dit onmogelijk te realiseren door relaties tussen list en block, en tussen form en block te leggen, ook omdat er bijvoorbeeld voor een iframe helemaal geen tabel nodig is. Ik zat er dus aan te denken om in de block tabel een block_type_id veld aan te maken met een relatie naar een block_type tabel, deze tabel bevat dan een type naam waarmee hardcoded bepaald wordt welke Control (ASP.NET) geladen wordt in het block, en deze control krijgt dan als parameter de value die opgeslagen staat bij block.

Aan deze constructie zitten echter een aantal nadelen:
1. Een control kan niet meer als een parameter krijgen ( bij een tree bijvoorbeeld is het dan onmogelijk om naar een dieper niveau in de tree te linken )
2. Het selecteren van de parameter zal op een vrij klungelige wijze in elkaar hangen, zo moet er dan bijvoorbeeld een query komen die voor alle blok types alle mogelijke waardes af gaat en die in een select box toont zodat de gebruiker een "eenvoudige" keuze uit de mogelijke parameters kan maken en daarnaast zal er nog een textveld beschikbaar moeten zijn indien het blok type een iframe betreft voor het opgeven van een url.

Kortom, er zitten wat haken en ogen aan deze methode, en ik kan er niet echt een mooi dynamisch geheel van maken. Mijn vraag dus: zijn er mensen die ervaring hebben met een soortgelijk probleem? hoe heb je dit dan opgelost? of hoe zou je dit oplossen?

[NMe]

Waarom wil je overal aparte tabellen voor maken? Waarom geen koppeltabel waarin je bloktypen koppelt met veldnamen, welke je later weer met veldwaarden kan koppelen?

[whoami]

Er zijn 3 (standaard) manieren om een dergelijk (inheritance) probleem op te lossen:

- Table per concrete class
- Table per class hierarchy
- Table per subclass

Bij Table per concrete class ga je -in uw geval- voor ieder bloktype een andere tabel gaan maken.
Bij Table per class hierarchy, ga je één tabel gaan maken, waarin je al uw block-types gaat bijhouden. Dit houdt dus in dat je een heleboel nullable columns zult moeten hebben, en het is ook moeilijk om hier constraints op je DB te gaan leggen, waarbij je aangeeft van: blocktype A moet column 1 en 2 ingevuld hebben, blockType B moet column 2 en 3 en 5 ingevuld hebben, bv.
Bij Table per subclass ga je één tabel maken waarin je alle gemeenschappelijke properties in opslaat, en dan een gerelateerde tabel gaat maken voor de specifieke blocktypes, die dus per blocktype de juiste columns heeft.

Is het makkelijk om op één van deze 3 manieren blocktypes toe te voegen... Dat hangt er vanaf. Wat is makkelijk ? Zowiezo ga je in deze 3 gevallen zowiezo DB aanpassingen moeten doen.
De manier die -NMe- zegt, zal geen structuur wijzigingen op DB niveau nodig hebben, maar dan nog vind ik dat een ranzige oplossing. Hoe ga je daar nl. gaan bepalen of een bepaald veld een DateTime is, of een Int ?

[NMe]

Variants? Het gaat om een website, en daar kom je er nog wel mee weg om mijn oplossing te gebruiken, maar het kan inderdaad veel netter.

[Verwijderd]

Ik wil apparte tabellen hebben omdat de data per blok bij een lijst toch flink wat anders is als de data bij een formulier. Bovendien is het uitprogrammeren van een type een stuk eenvoudiger wanneer type specifieke informatie gewoon in een tabel voor dat type opgeslagen staat. Vandaar dat table per concrete class me wel aanspreekt. Ik ben op dit moment even op internet aan het rond neuzen naar implementaties met deze methode.

Voor het toevoegen van nieuwe blok types ging ik er al vanuit dat je daarvoor sowiso nieuwe tabellen aan moet maken en daarbij ook uiteraard een nieuwe control moet maken die dit type implementeerd. Als het op zo'n manier kan, dan vind ik dat "makkelijk" genoeg om er mee te werken.

Ik zal zo het database diagram nog even aanpassen, ben benieuwd wat jullier ervan gaan vinden.