[PHP/MySQL] [Datamodel] variabele lijst met eigenschappen

[Config]

Ik heb in mijn applicatie enkele entiteiten...bijvoorbeeld:

- User
- Boom
- (nog een paar)

Een entiteit Boom heeft een aantal vaste eigenschappen, plus een paar die niet aanwezig zijn bij de andere Bomen. Nu zijn er een aantal opties om dit in te vullen:

- Gewoon alle eigenschappen als kolommen opnemen en velden leeg laten (+/- verdubbeling van aantal eigenschappen van 40 naar 80 per record).
=> niet echt handig met het oog op het groeiend aantal attributen in de toekomst

- Eigenschappentabel en enteittabel scheiden en koppelen met koppeltabel. Elke eigenschap heeft een ID, elke Boom ook en de koppeltabel geeft dan (AttributeID, EntityID, Value).
=> traag. het gaat om een high traffic site met veel SELECTs
=> mogelijke oplossing: pagina's cachen?

- Hybride: vaste attributen in de tabel, en dan de optionele attributen op de 2e manier opslaan.

Het gebruik van PHP libraries wordt sterk gewaardeerd .

[Janoz]

Het verschil in eigenschappen, is dat heel afwisselend, of zijn het verschillende groepen tussen de bomen de elke een eigen set eigenschappen heeft? Wat ik dus eigenlijk vraag is over er een soort object hierarchie in zit. Je hebt bomen, en daaronder naaldbomen en loofbomen.

In het laatste geval zou je als 3e optie nog kunnen kiezen voor het toevoegen van een tabel per groep en daarin de specifieke eigenschappen van die subgroep zetten. Hiertussen leg je dan een 1:[0,1] relatie.

Voordelen tov 1e optie:
-Geen grote lege tabellen.
-Je kunt voor elke subgroep ook constraints afdwingen op de voor die subgroep specifieke eigenschappen (verplichte velden)

Voordelen toc 2e optie:
-Je kunt voor elke subgroep ook constraints afdwingen op de voor die subgroep specifieke eigenschappen (In dit geval de unique constraint)
-Je extra eigenschappen hebben een datatype

Nadelen
-Werkt alleen als je vooraf redelijk de groepen kunt indelen. Als het er op neer komt dat bijna elk record in een apparte groep komt is dit zeker neit the way to go.

[_js_]

Nog een nadeel van een eigenschappen tabel: je kunt eigenlijk maar 1 type gebruiken voor je values. Als je kolommen gebruikt kun je ze allemaal het juiste datatype geven.

[Config]

Als we inderdaad even bij bomen blijven, dan is dit het idee

Boom, heeft: soort, ras, familie (steeds globaler dus)

familie 1:N ras 1:N soort

Van soort wil ik attributen gaan bijhouden. Bij de ene soort grootte,kleur, bij de andere ook nog eens een beschrijving, etc etc.

Nu zijn we al een stuk verder, en is het wel duidelijk dat het systeem een cache tabel nodig heeft met alle mogelijke soorten (0N, platte data dus). Deze tabel krijgt dan een kardinaliteit van 100.000. Deze tabel kan ik gewoon op afroep regenereren. Omdat ik deze cachetabel zeker niet overal VARCHARS wil laten gebruiken, moet ik toch OF ergens een datadictionary opgeven, OF gewoon optie 1 gebruiken.

Optie 3 had ik inderdaad nog niet bedacht, ik vraag me af of dat lekker werkt. De scripts zullen dan het ingewikkeldste zijn van alle opties..echter, misschien is het wel de beste keuze

[Siliakus]

Een sterschema met Boom als feit en familie, ras en soort als dimensies is geen optie?

Ik las dat je veel select statements op de data uitvoert, dus performance wise is het ook nog eens een goede optie..

Oja bij de dimensies dan inderdaad gewoon het maximaal aantal attribuut kolommen opnemen en deze niet leeglaten maar vullen met een omschrijving. Iets als 'niet ingevuld' ofzo.

[BikkelZ]

Als de tabellen die heel veel attributen hebben soms alleen gebruikt worden als tussenschakel, dan is het in dat geval misschien wel wat trager. Ik denk dat je altijd achteraf wilde dat je gewoon genormaliseerd had als je het niet doet.

Het klinkt eigenlijk eerder alsof je een soort UML OO schema probeert te vertalen naar tabellen trouwens. Boom extends Plant, Plant extends BiologischLeven, een plant heeft bladeren, een boom heeft een houtsoort, biologisch leven heeft een bool leeft, enz enz enz, klopt dat?

[BikkelZ]

Als dat zo is, dan moet je deze tutorial (die het inmiddels tot de MySQL site geschopt heeft) eens doornemen:

http://dev.mysql.com/tech...es/hierarchical-data.html

Je bouwt dan een Datatree in je database, en dat houdt in dat je eigenlijk uit een tabel oneindig diep kunt doornesten qua levels. Ik heb dit zelf een keer in de praktijk gebracht, en het werkt best wel goed, al is het niet voor een high traffic site gebruikt (de lakmoesproef).

Je kunt volgens mij ook vrij makkelijk delen van deze tree in je cache stoppen, je hoeft alleen maar aan te geven welke tupel de hoogste node vertegenwoordigt. Ik heb het gebruikt om heel dynamisch een scherm in te kunnen delen via een CMS. Tenslotte is een XHTML pagina niets anders dan een data tree.