[Database] Properties voor records

[Potatoman]

Ik ben op dit moment een database aan het ontwerpen die een heleboel verschillende tabellen bevat. Het is een soort van hierarchie. We hebben drie tabellen, die ik hier versimpeld probeer te omschrijven) :

- HoofdTabel
- SubTabel, voor elk record in HoofdTabel x records in SubTabel
- SubSubTabel, voor elk record in SubTabel x records in SubSubTabel

Ik zit met het volgende probleem: elk record (HoofdRecord, SubRecord, SubSubRecord) heeft een aantal 'properties', zoals Gewicht, Omtrek, Smaak, Kleur etc. Deze properties kunnen hetzelfde zijn voor een SubRecord, maar ze kunnen ook verschillen. Over het algemeen zal een SubRecord een hele andere serie properties hebben dan een HoofdRecord.

Bovendien zijn deze properties veranderend, en in de toekomst weet ik dat we meer nieuwe properties zullen hebben, maar ik kan niet voorspellen welke. Het is dus vrij lastig om van elke property een kolom te maken.


Qua oplossingen heb ik al veel met andere mensen gepraat, en we zijn tot twee mogelijke oplossingen gekomen, maar ik ben met beide niet 100% tevreden.

De eerste oplossing is 1 grote tabel met properties, en we gebruiken NULL velden om properties van de HoofdTabel en SubTabel te definieren. Voorbeeld:

code:

ID   HoofdID   SubID   SubSubID   Property                Value
----------------------------------------------------------------------
0    0         NULL    NULL       HoofdTabelProperty      5.678
1    0         0       NULL       SubTabelProperty        5.3232
2    0         0       0          SubSubTabelProperty     4.2324

Ik kan hier weinig concrete bezwaren tegen bedenken eigenlijk. Alleen voor mijn gevoel ziet het er lelijk uit. Kan niet precies zeggen waarom


De tweede oplossing is om een tabel te hebben die voor elke property bijhoudt bij welke tabel deze behoort en wat het ID van het record in die tabel is. Voorbeeld:

code:

ID   ForeignTableName   ForeignTableID   Property              Value
----------------------------------------------------------------------
0    HoofdTabel         0                HoofdTabelProperty    5.3432
1    SubTabel           0                SubTabelProperty      3.2314
2    SubSubTabel        0                SubSubTabelProperty   5.4321

Het grootste probleem met deze oplossing lijkt mij de referentiele integriteit, alhoewel dat 'opgelost' kan worden met triggers in de database.

Ik zou graag een derde optie willen hebben, en een discussie over de goede en slechte kanten van de oplossingen die ik nu heb

[Marcj]

Een derde oplossing zou kunnen zijn dat je voor elke tabel een propertie-tabel er bij maakt. Dus de volgende layout voor een HoofdTabelProperties, SubTabelProperties, SubSubTabelProperties.

code:

ID   ForeignTableID   Naam                  Value
----------------------------------------------------------------------
0    0                Property1             5.3432
1    0                Hoogte                3.2314
2    0                Breedte               5.4321

Aangezien je toch statisch in de SQL statements moet controleren welke properties bij welke tabel horen (dus bij joins statisch op een specifieke waarde moet kijken in beide gevallen) lijkt me dit wel net zo handig en een stuk duidelijker.

[kenneth]

Over het algemeen (jouw situatie kan natuurlijk heeeeeel specifiek zijn ) geldt dit soort generieke databases in 'n database als bad design *insert linkje naar het beroemde verhaal ergens op oracle.com*
Je krijgt onmogelijke queries, en onmogelijke referentiele integriteit.
Waarom het is lastig om de database aan te passen als dat nodig is? Die van ons krijgt ook iedere 1/2 maanden ergens 'n veld erbij.

[Potatoman]

kenneth schreef op vrijdag 13 april 2007 @ 08:04:
Over het algemeen (jouw situatie kan natuurlijk heeeeeel specifiek zijn ) geldt dit soort generieke databases in 'n database als bad design *insert linkje naar het beroemde verhaal ergens op oracle.com*
Je krijgt onmogelijke queries, en onmogelijke referentiele integriteit.
Waarom het is lastig om de database aan te passen als dat nodig is? Die van ons krijgt ook iedere 1/2 maanden ergens 'n veld erbij.

Het is lastig om zomaar extra velden en tabellen erbij te maken omdat het een database is die aangesproken wordt door programma's die door anderen gemaakt worden, en die willen een vrij definitief design hebben.

Op zich spreekt het idee van 1 property tabel per originele tabel me wel aan, maar dat maakt het geheel toch al gauw onoverzichtelijk, naar mijn mening.

[NetForce1]

Potatoman schreef op vrijdag 13 april 2007 @ 20:19:
[...]
Op zich spreekt het idee van 1 property tabel per originele tabel me wel aan, maar dat maakt het geheel toch al gauw onoverzichtelijk, naar mijn mening.

Dan is het misschien wel aardig om een centrale property tabel te maken met een koppeltabel per originele tabel. Of een enum-achtig veld in de property tabel die het type van de originele tabel aangeeft. Verder zou je kunnen overwegen om per datatype een property tabel te maken zodat je niet alles in een (n)varchar hoeft te proppen.
Maar je bent idd wel bezig om een rdbms na te bouwen dan, kun je die third-party applicaties niet beter via een webservice oid met je database laten communiceren? Dan kun je naar hartelust wijzigingen aanbrengen in je structuur zonder dat iemand daar verder last van heeft.