[Alg / C#, MSSQL] Variabele aantal members

[stylee]

Hoi allemaal,

Puur voor de fun (en de leerzaamheid) ben ik bezig een soort van Object Broker / Data Layer aan het maken.

Wat ik wil doen is eigenlijk als volgt. Mijn Object Broker geeft een object door die een aantal properties heeft, maar de properties óf het aantal properties weet je nooit van te voren. Je hebt bijv een object Boek die de ene keer een Titel, Auteur en ISBN heeft en de andere keer Titel, Auteur, JaarVanUitgave.

Vrij simpel te doen dmv een Hashtable en een Indexer op mijn class (bijvoorbeeld), maar het probleem zit het in het persistent maken van deze objecten in bijvoorbeeld een database.

Ik gebruik nu SQL Server 2000 en zat ongeveer aan het volgende te denken.

Een tabel Product (ProductID, ProductType)
Een tabel ProductProperty (ProductID, ProductPropertyKey, ProductPropertyValue)

Je voelt hem al hangen, wat voor type veld moet ProductPropertyValue dan zijn om het database-model efficënt te houden?

Ik heb twee dingen bedacht het ene is inventariseren wat voor types ik in mijn applicatie ga aanbieden en iets van de volgende structuur maken:

ProductProperty (ProductID, ProductPropertyKey, ProductPropertyValueInt, ProductPropertyValueVarChar, ProductPropertyValueDateTime, etc)

Ranzig

Het tweede wat ik had bedacht was gewoon verschillende tabellen:

ProductPropertyInt (ProductID, ProductPropertyKey, ProductPropertyValue)
ProductPropertyVarChar (ProductID, ProductPropertyKey, ProductPropertyValue)
..etc..

Ranzig numero deux

Ik heb er zelfs aan gedacht om complete objecten binair te serializen naar de database. Maar dat word een beetje lastig met doorzoeken (of ik moet aparte search tabellen bij houden. Zou mischien nog eens efficiënt zijn ook voor de Indexes).

Ook een object gewoon serializen naar XML heb ik aan gedacht. Het leuke hiervan is dat mijn Object Broker een bepaalde product zou kunnen cachen zodat hij de ge-deserializede (hoe spel je dat? ) versie direct kan aanbieden, maar allerlei losje XML bestandjes voor je objecten is ook niet je-van-het

Ik vroeg me af of jullie ideeën hadden om dit beter op te lossen. Dit is gewoon een testje dus in principe zit ik niet vast aan wat dan ook. Het gaat me ook meer om het principe dan het uiteindelijk uitwerken.

Bedankt

[EfBe]

Welkom in de wondere wereld van O/R mappers, waar meer valkuilen zijn dan waar ook.

Als je op objectniveau praat over entiteiten hebben die niet een variabel aantal properties. Een boek heeft titel, auteur, ISBN en jaarvanuitgifte. Je bent wellicht geinteresseerd in een subset daarvan, maar de andere properties verdwijnen niet! Een boek heeft nog steeds een jaar van uitgifte als jij die niet noemt.

[Verwijderd]

Bedoelt de ts niet dat bijvoorbeeld in plaats van een boek ook een fiets kan worden meegegeven?

In dat geval is het misschien interessant om attributen toe te passen op bijvoorbeeld de properties van iedere klasse. In de object broker zou je in dat geval m.b.v. reflection kunnen bepalen wat voor datatype je moet gebruiken, etc.

[stylee]

Verwijderd schreef op 27 April 2003 @ 13:35:
Bedoelt de ts niet dat bijvoorbeeld in plaats van een boek ook een fiets kan worden meegegeven?

In dat geval is het misschien interessant om attributen toe te passen op bijvoorbeeld de properties van iedere klasse. In de object broker zou je in dat geval m.b.v. reflection kunnen bepalen wat voor datatype je moet gebruiken, etc.

Juist. Voor hetzelfde geld zou het dus ook een fiets kunnen zijn en helemaal niks te maken kunnen hebben met Titel, Auteur, etc.

Misschien was ik iewat onduidelijk in mijn openingspost.

[EfBe]

Verwijderd schreef op 27 April 2003 @ 13:35:
Bedoelt de ts niet dat bijvoorbeeld in plaats van een boek ook een fiets kan worden meegegeven?

Waaraan meegegeven? De broker? maar wat moet die broker ermee als hij niet weet wat het is? Een in-memory object tree dat een representatie is van een persistent bewaarde verzameling data, is niet meer dan dat: een representatie. M.a.w: je hebt dus ergens een fysieke instance van die verzameling data. Als je dus praat over een object Boek, dan heb je dus in je persistente verzameling data (bv een database) ook een entiteit boek. (het is daarom beter te praten over entiteiten, ipv objects).

Je zorgt er dus voor dat de in-memory representatie van een entiteit gemapped wordt op een fysieke representatie zodat je een in-memory instance kunt verkrijgen van de fysieke en de fysieke dmv de in-memory representatie kunt wijzigen/creeren etc.

Lees eens:
http://www.uq.net.au/~zzabergl/simpleorm/whitepaper.html
Wel een leuk artikel hierover.

In dat geval is het misschien interessant om attributen toe te passen op bijvoorbeeld de properties van iedere klasse. In de object broker zou je in dat geval m.b.v. reflection kunnen bepalen wat voor datatype je moet gebruiken, etc.

Zou je werkelijk bij elke instance middels reflection willen weten waar je mee te maken hebt? Lijkt me vrij langzaam, en ook onnodig, want je broker logica zit veel lager in de chain of command: die verzorgt de fysieke mapping tussen een tabel in een database (of meerdere tabellen in de database) en het in-memory object, iets wat je dus kunt genereren in plain code vanuit bv een database definitie, als je geen editor wilt bouwen, en die gegenereerde code kan dan dmv inheritence of object composition vrij compact gebouwd worden.