Generiek datamodel voor vergelijkings- en waarderingssysteem

[Verwijderd]

Ik loop met het volgende idee in mijn hoofd. Toen ik op zoek was naar een sportschool op internet kwam ik erachter dat er niet een goede duidelijke site bestaat waarbij de gebruiker:

• kan zoeken op eigenschappen van een sportschool (zoek sportscholen met een sauna of zoek sportscholen waarbij judolessen worden gegeven)
• sportscholen kan waarderen op voorgefineerde onderdelen zoals de locatie, de machines en de sfeer
• sportscholen kan zoeken en vergelijken op basis van waarderingen

Nu lijkt mij dit een leuk project om zo kennis te maken met bepaalde onderwerpen (ORM, OR/Mappers, etc.). Dit ga ik dan ook zeker doen!

Wanneer dit af is zou het leuk zijn om het aan te passen/opnieuw te bouwen zodat het systeem herbruikbaar zou zijn. Ik zou ook bijvoorbeeld tv's of webshops willen vergelijken. Het mogelijk kunnen maken om bijvoorbeeld tv's te kunnen vergelijken en te waarderen moet dan een kwestie zijn van het toevoegen van een entiteit tv met entiteit specifieke eigenschappen. Bijvoorbeeld tv met eigenschappen: beelddiagonaal, merk en gewicht. Hiermee moet het mogelijk worden om instanties van tv's te kunnen toevoegen (model a van merk b en model c merk d).

• Een tabel ObjectType zou de soorten objecten moeten bevatten die vergeleken kunnen worden. Dus bijvoorbeeld sportscholen tv's of webshops.
• Een tabel ObjectProperty zou de eigenschappen van de objecten uit ObjectType moeten bevatten. Dus bijvoorbeeld afmeting voor tv's en sauna aanwezig? voor sportschool.In deze tabel ObjectProperty zou ik willen vastleggen of het verplicht is, er meerdere waarden mogen worden ingevoerd.
• ObjectPropertyEnumaration (dus voor een ObjectProperty sportschool mogelijkheden zou je de waarden kunnen opslaan: aerobics, bedrijfsfitness en spinning).
• In een tabel Instance zou een instantie van het ObjectType opgeslagen moeten worden met een relatie naar de tabel Object (dus bijvoorbeeld de Sony KDL-W4000 tv of de sportschool Healthcity Amsterdam).
• In een tabel InstanceProperty kunnen op dezelde wijze de in ObjectProperty vastgelegde eigenschappen worden ingevoerd
• Door het toevoegen van subtypering zou je nog kunnen aangeven of het om een Product, Bedrijf, Dienst of misschien zelfs een Persoon gaat zodat gemeenschappelijke informatie niet keer op keer in de tabel ObjectProperty gedefinieerd hoeven te worden. Ook zou je voor het subtype bedrijf een koppeling met een adres tabel mogelijk kunnen maken. Maar dat zou geen must have zijn in eerste instantie.

Een nadeel die ik kan bedenken van dit is natuurlijk dat je niet gebruik maakt van het datatype systeem die de RDBMS biedt. Dit is op te lossen in code maar dan zit je nog wel met dat je voor alles het veld varchar gebruikt. Op zich zou je dit nog kunnen oplossen door de kolom Content van de ObjectProperty te verplaatsen naar onderliggende subtype tabellen. Dus een PropertyVarchar, PropertyInt, PropertyDatetime, PropertyBoolean met een relatie naar de tabel InstanceProperty. IN een extra kolom Datatype in de tabel ObjectProperty zou ik dan kunnen vastleggen in welke subtype tabel het record moet worden opgeslagen.

Ik zou hiernaast op dezelfde manier waarderingscriteria willen definiëren voor records in de tabel Insance. Dus voor een sportschool kan je 3 criteria bedenken als sfeer, service en accomodatie. De bezoeker zou dan een waardering kunnen geven aan de hand van deze criteria voor een instantie van een sportschool.

Wanneer de functie van het systeem zou zijn sportscholen waarderen en vergelijken dan is dit een omslachtige werkwijze maar wanneer de functie wordt: bedrijven en producten vergelijken dan moet je toch naar een dergelijke structuur?

Ik ga me eerst nog even lekker verdiepen in ORM/NIAM om tot een goed conceptueel model te komen. Toch wil ik weten wat de nadelen , naast het door mij genoemde gebruik van datatypen op de RDBMS nadeel, zijn van een dergelijke opzet die ik moet meenemen om een goede beslissing te kunnen maken of ik dit zo wil uitvoeren.

edit:

Kan de titel van mijn topic ontdaan worden van de spelfouten?

edit:
ObjectPropertyEnumaration toegevoegd

[Flard]

Het klinkt misschien wat stom, maar in feite bouw je dus gewoon een database in een database? Hiedoor lever je dus behoorlijk in op performance, 'simpele queries' en referentiele integriteit.

Mij lijkt het juist beter een aantal goede stamtabellen te hebben (dus een tabel sportscholen, een tabel cursussen, etc). Voor de bezoekerbeoordelingen zou je dan wel 1 tabel kunnen maken ([type][id][eigenschap][rating])

Ik denk ook niet dat het slecht is als je je later ineens een nieuwe 'sportschooleigenschap' bedenkt en die dan nog als kolom moet toevoegen)

[Verwijderd]

Maatwerk, dus eigen tabellen, is kijkend naar optimalisatie beter zoal jij aangeeft. Ik weet dat mijn oplossing daar op inlevert maar er is natuurlijk een verschil tussen een acceptabele inlevering van performance en een niet goed werkend systeem.

De queries worden welliswaar wel langer maar de opbouw van de query is wel hetzelfde voor wanneer het ophalen van een tv met zijn eigenschappen als voor een sportschool met zijn eigeschappen. Bij de 1 zal ik ik meer de tabel InstanceProperty moeten aliassen en hiermee joinen met de Insance tabel. Het zou niet veel uitmaken of je dit 3 of 10 keer doet toch? De query structuur wordt immers niet complexer of anders.

edit:

Ik wil het wel als 1 systeem beschouwen dus niet zo zeer als een systeem waarmee een specifiek product wordt vergeleken. Middels een andere grafische schil kan de suggesie gewekt worden dat het verschillende systemen zijn.

[ Voor 44% gewijzigd door Verwijderd op 18-08-2008 06:56 ]

[Flard]

Nou, je moet het als volgt zien (denk ik): stel dat je sportschool een nieuwe eigenschap krijgt die je wilt 'meten', in het ene geval voeg je dan een nieuwe kolom toe (ALTER TABLE ADD COLUMN), in het andere geval voeg je een nieuw record toe (INSERT INTO [Properties]). Waarom zou het eerste minder zijn?
Zodra je gaat zoeken op jouw propertykolommen, en zeker een of meer properties gaat gebruiken gaat het héél snel achteruit met je performance. (En dat komt nogal eens voor dat mensen op meer dan één kolom willen zoeken).
Alle metadata zijn ook gewoon via SQL te verkrijgen, dus je kunt ook gewoon door de kolommen lopen en kijken welk type ze zijn, welke naam ze hebben en welke omschrijving ze hebben en die op je webpagina tonen. Dus in het ene geval doe je (SELECT FROM [metadata]) en in het andere geval (SELECT FROM [Properties]).

Eventueel zou je je datamodel wel qua naamgeving wat generieker op kunnen zetten.

Op zich klopt je datamodel trouwens wel, en het zal ook wel werken, alleen je slaat dus eigenlijk één stap te ver door met je NIAM, want zo is er niet echt sprake meer van een probleemdomein, als je begrijpt wat ik bedoel.

[Verwijderd]

Flard schreef op maandag 18 augustus 2008 @ 09:11:
Nou, je moet het als volgt zien (denk ik): stel dat je sportschool een nieuwe eigenschap krijgt die je wilt 'meten', in het ene geval voeg je dan een nieuwe kolom toe (ALTER TABLE ADD COLUMN), in het andere geval voeg je een nieuw record toe (INSERT INTO [Properties]). Waarom zou het eerste minder zijn?
Zodra je gaat zoeken op jouw propertykolommen, en zeker een of meer properties gaat gebruiken gaat het héél snel achteruit met je performance. (En dat komt nogal eens voor dat mensen op meer dan één kolom willen zoeken).
Alle metadata zijn ook gewoon via SQL te verkrijgen, dus je kunt ook gewoon door de kolommen lopen en kijken welk type ze zijn, welke naam ze hebben en welke omschrijving ze hebben en die op je webpagina tonen. Dus in het ene geval doe je (SELECT FROM [metadata]) en in het andere geval (SELECT FROM [Properties]).

Eventueel zou je je datamodel wel qua naamgeving wat generieker op kunnen zetten.

Op zich klopt je datamodel trouwens wel, en het zal ook wel werken, alleen je slaat dus eigenlijk één stap te ver door met je NIAM, want zo is er niet echt sprake meer van een probleemdomein, als je begrijpt wat ik bedoel.

Ik heb nagedacht over eventuele performance inzakking bij het zoeken naar een waarde in deze kolom. Echter een zoekopdracht op alleen content zal niet gebeuren. Immers een gebruiker zal allen kunnen zoeken inhoud van een InstanceProperty wanneer het ObjectType wordt meegegeven. Bijvoorbeeld de zoekopdracht: haal tv's op met een beelddiagnonaal van 102 cm. Met een index zou deze opdracht geoptimaliseerd kunnen worden. Ik verwacht zelf dat, wanneer er geen tientallen miljoenen records in de database staan dat de opdracht nog vrij snel uit te voeren is. Maar een ontkrachting van mijn denkwijze hoor ik net zo graag.

Zelf denk ik dat het niet gebruiken van de implementatie van het typesysteem in de RDBMS (SQL Server) een groter nadeel is. Voor ieder PropertyType zal er moeten worden aangegeven om wat voor datatype het gaat om het syteem safe te maken op dit gebied. Daarnaast zal er code geschreven moeten worden die waardes cast naar het gegeven type. En dat laatst is volgens mij een behoorlijk moeilijke taak.

Hoe zou jij de naamgeving van het model generieker maken? De naamgeving die ik als voorbeeld gaf is misschien wat ongelukkig gekozen.

[mOrPhie]

Je maakt hier een "Database in Database" beginnersfout. Het -te- generiek willen maken van je database is iets wat iedereen ooit 'ns heeft overwogen en later in heeft gezien dat het lastiger was dan het leek, moeilijk onderhoudbaar was, de queries vreemd en groot werden en de performance bij grote aantallen in elkaar zakte. Er zijn meerdere systemen die toch nog zo werken als dat jij noemt (Microsoft's Sharepoint bijvoorbeeld), maar die kennen dan ook de problemen die ik hierboven noemde. (Een probleem is bijvoorbeeld de "lookup" field. Een referentie naar een item in een andere lijst. Deze aanpak kent geen referentiele integriteit en is lelijk (de lookup is een string-veld met als inhoudt "{id}:{lijst}", om maar 'ns iets te noemen. Erg foutgevoelig blijkt in de praktijk.

Zoek maar 'ns op "database in database" en "generiek data model" oid. Er zijn meerdere topics die deze uitdaging aan willen gaan en waarin de problemen ervan worden aangekaart.

[Flard]

Ik sluit me volledig aan bij mOrPhie, en ik vraag me ook sterk af wat volgens jou dan de voordelen zijn van een database in een database t.o.v. een genormaliseerde 'domein'-database. Wat zijn volgens jou de nadelen van een genormaliseerde domeindatabase? Qua performance, onderhoudbaarheid, leesbaarheid en referentiële integriteit (betrouwbaarheid van de data) is een 'normale' database gemakkelijker.

En ik denk wel dat je op selecties over meerdere kolommen kunt rekenen: toon mij alle sportscholen in de omgeving van <plaats> (selectie 1) die een sauna (2) of zwembad hebben (3). Of toon mij alle winkels in de omgeving van <plaats> (1) die een plasma TV (2) verkopen van een beelddiagonaal van 100cm of meer (3) met minstens 3 HDMI inputs (4). Moet je eens voorstellen hoe die queries er in de twee versies eruit zien, en welke het beste performt. (Ik zou het execution path wel eens willen zien )

En dat vergelijken lijkt me júist de kracht van een goed vergelijksysteem en zoeksysteem.

Wat betreft de naamgeving: ik bedoelde meer dat je in een goed genormaliseerde database tabellen als 'Sportschool', 'Cursus', etc... zou krijgen. Je zou dan wel kunnen kiezen voor 'Leverancier' en 'Dienst' (bijvoorbeeld).

[edit]
Ik zie dat je het in een ander topic ook over linq hebt, ik weet niet of je dat hierin wilt gaan gebruiken, maar het lijkt me dat je dan geen database-in-database wilt maken. Linq (en het Entity Framework) zijn júist gemaakt om als O/R-mapper tussen de code en het probleemdomein te gaan zitten. En het probleemdomein bestaat in jouw geval dus uit sportscholen, cursussen etc, en niet uit instanties en eigenschappen. Je linq-statemens zullen anders ook wel heel erg raar en onleesbaar worden, en linq bevat dan ook geen echte voordelen. (En ik denk dat je ieder beetje performance moet koesteren, en dus beter zelf je SQL-statements kunt schrijven).

[ Voor 21% gewijzigd door Flard op 18-08-2008 10:50 ]

[curry684]

Wat je probeert te doen gaat op een gegeven moment leiden tot:

Iemand schreef op zondag 10 februari 2008 @ 19:36:
Daarbij heb ik de volgende query.

SQL:

SELECT `Company`,`Location`,`Product`,`Type`,`Video`,`Image`,`Genre`,`Title`,`Description`,`Text`
FROM `Company`
LEFT JOIN `Location` ON `Location`.`CompanyID` = `Company`.`CompanyID`
LEFT JOIN `Location2Product` ON `Location2Product`.`LocationID` = `Location`.`LocationID`
LEFT JOIN `Product` ON `Product`.`ProductID` = `Location2Product`.`ProductID`
LEFT JOIN `Product2Type` ON `Product2Type`.`ProductID` = `Product`.`ProductID`
LEFT JOIN `Type` ON `Type`.`TypeID` = `Product2Type`.`TypeID`
LEFT JOIN `Video` ON `Video`.`VideoID` IN (
   SELECT `VideoID` FROM `Location2Video` WHERE `LocationID` = `Location`.`LocationID`
   UNION SELECT `VideoID` FROM `Product2Video` WHERE `ProductID` = `Product`.`ProductID`
)
LEFT JOIN `Image` ON `Image`.`ImageID` IN (
   SELECT `ImageID` FROM `Location2Image` WHERE `LocationID` = `Location`.`LocationID`
   UNION SELECT `ImageID` FROM `Product2Image` WHERE `ProductID` = `Product`.`ProductID`
   UNION SELECT `ImageID` FROM `Video2Image` WHERE `VideoID` = `Video`.`VideoID`
   UNION SELECT `ImageID` FROM `Genre2Image` WHERE `GenreID` IN (
      SELECT `GenreID` FROM `Company`
      LEFT JOIN `Location` ON `Location`.`CompanyID` = `Company`.`CompanyID`
      LEFT JOIN `Location2Product` ON `Location2Product`.`LocationID` = `Location`.`LocationID`
      LEFT JOIN `Product` ON `Product`.`ProductID` = `Location2Product`.`ProductID`
      LEFT JOIN `Video` ON `Video`.`VideoID` IN (
         SELECT `VideoID` FROM `Location2Video` WHERE `LocationID` = `Location`.`LocationID`
         UNION SELECT `VideoID` FROM `Product2Video` WHERE `ProductID` = `Product`.`ProductID`
      )
      LEFT JOIN `Genre` ON `Genre`.GenreID` IN (
         SELECT `GenreID` FROM `Location2Genre` WHERE `LocationID` = `Location`.`LocationID`
         UNION SELECT `GenreID` FROM `Product2Genre` WHERE `ProductID` = `Product`.`ProductID`
         UNION SELECT `GenreID` FROM `Image2Genre` WHERE `ImageID` = `Image`.`ImageID`
         UNION SELECT `GenreID` FROM `Video2Genre` WHERE `VideoID` = `Video`.`VideoID`
      )
   )
)
LEFT JOIN `Genre` ON `Genre`.`GenreID` IN (
   SELECT `GenreID` FROM `Location2Genre` WHERE `LocationID` = `Location`.`LocationID`
   UNION SELECT `GenreID` FROM `Product2Genre` WHERE `ProductID` = `Product`.`ProductID`
   UNION SELECT `GenreID` FROM `Image2Genre` WHERE `ImageID` = `Image`.`ImageID`
   UNION SELECT `GenreID` FROM `Video2Genre` WHERE `VideoID` = `Video`.`VideoID`
)
LEFT JOIN `Title` ON `Title`.`TitleID` IN (
   SELECT `TitleID` FROM `Location2Title` WHERE `LocationID` = `Location`.`LocationID`
   UNION SELECT `TitleID` FROM `Product2Title` WHERE `ProductID` = `Product`.`ProductID`
   UNION SELECT `TitleID` FROM `Type2Title` WHERE `TypeID` = `Type`.`TypeID`
   UNION SELECT `TitleID` FROM `Video2Title` WHERE `VideoID` = `Video`.`VideoID`
   UNION SELECT `TitleID` FROM `Genre2Title` WHERE `GenreID` = `Genre`.`GenreID`
   UNION SELECT `TitleID` FROM `Image2Title` WHERE `ImageID` = `Image`.`ImageID`
)
LEFT JOIN `Description` ON `Description` IN (
   SELECT `DescriptionID` FROM `Location2Description` WHERE `LocationID` = `Location`.`LocationID`
   UNION SELECT `DescriptionID` FROM `Product2Description` WHERE `ProductID` = `Product`.`ProductID`
   UNION SELECT `DescriptionID` FROM `Type2Description` WHERE `TypeID` = `Type`.`TypeID`
   UNION SELECT `DescriptionID` FROM `Video2Description` WHERE `VideoID` = `Video`.`VideoID`
   UNION SELECT `DescriptionID` FROM `Genre2Description` WHERE `GenreID` = `Genre`.`GenreID`
   UNION SELECT `DescriptionID` FROM `Image2Description` WHERE `ImageID` = `Image`.`ImageID`
)
LEFT JOIN `Text` ON `Text` ON `Text` IN (
   SELECT `TextID` FROM `Location2Text` WHERE `LocationID` = `Location`.`LocationID`
   UNION SELECT `TextID` FROM `Product2Text` WHERE `ProductID` = `Product`.`ProductID`
   UNION SELECT `TextID` FROM `Type2Description` WHERE `TypeID` = `Type`.`TypeID`
   UNION SELECT `TextID` FROM `Video2Description` WHERE `VideoID` = `Video`.`VideoID`
   UNION SELECT `TextID` FROM `Genre2Description` WHERE `GenreID` = `Genre`.`GenreID`
   UNION SELECT `TextID` FROM `Image2Description` WHERE `ImageID` = `Image`.`ImageID`
)

Dat is geen goed idee, geloof me

[Verwijderd]

Ik zie nu ook wel in dat mijn oplossing niet goed zal werken. Ik snap ook dat het probleemdomein sportscholen is. Maar wat als je een applicatie wilt maken waarbij producten/bedrijven/diensten worden vergeleken. Dan is het probleemdomein toch het vergelijken van objecten? Is de keuze voor losse tabellen dan nog steeds te verantwoorden?

[Flard]

Lijkt me wel. Daarbij zeg je het al: je vergelijkt dus producten én bedrijven én diensten. Dat ijken me dus drie aparte entititeiten (dus tabellen). Waarom zou je die niet per website hun eigen attributen (dus kolommen) kunnen geven?
In het in geval moet je je Property-tabel per website inrichten (rijen toevoegen), in het andere geval moet je de kolommen van de drie tabellen inrichten (kolommen toevoegen).

Nogmaals: waarom hou je vast aan je (in onze ogen) té generieke model. Wat zijn volgens jou dan de voordelen?
Een 'genormaliseerde' database wint op:
* performance
* onderhoudbaarheid
* leesbaarheid van de queries
* referentiële integriteit (betrouwbaarheid van de data)

Wat betreft het toevoegen van een kolom (en hoe vaak doe je dat?): wat is het verschil dan tussen een INSERT en een ADD COLUMN?

Of anders gezegd: wat verwacht je anders van dit topic: dat wij allemaal "ja, goed bezig" zeggen? Wij komen steeds met argumenten, maar die weerleg je niet... En ik heb het idee dat het voor jou gewoon een 'koppig' (NOFI) gevoel is.

offtopic:
curry684: mooie voorbeeld query Echt WTF...

[ Voor 15% gewijzigd door Flard op 18-08-2008 11:24 ]

[Noork]

curry684 schreef op maandag 18 augustus 2008 @ 10:52:
Wat je probeert te doen gaat op een gegeven moment leiden tot:
[...]
Dat is geen goed idee, geloof me

Oh mijn god, dat topic is geweldig

Is het geen idee om gewoon een opzet te maken voor de sportscholen. Als je later b.v. webshops wilt beoordelen, dan copy paste je gewoon je tabellen en rename je de boel en verander je een aantal kolommen. Lijkt me een stuk sneller dan vooraf beginnen met een generieke opzet.

[Verwijderd]

Koppig valt wel mee toch? Ik heb in de voorgaande post al aangegeven dat GEEN goed idee is Ik ben er dus zeker niet op uit om het idee hier te gaan verdedigen.Het weerlegen van de RDBMS voordelen is ook onbegonnen werk. Echter ik ben op zoek naar een zo eenvoudig mogelijk onderhoudbare oplossing. Het moeten toevoegen van een tabel per type is niet echt onderhoudbaar te noemen. Voor mij is een alter table ingrijpender dan het toevoegen van een record. Je hebt ook gelijk wanneer je zegt dat het om 3 entiteiten gaat.

Ik ben bang dat er geen generieke oplossing voor bestaat en dat losse tabellen het best werken en dat inleveren op aanpasbaarheid dan maar iets is wat ik moet accepteren.

Ik heb nog wel een hersenspinsel...;) Het datatype van het veld waarin de inhoud van eigenschappen wordt opgeslagen zou een XML datatype kunnen zijn. Ik heb hier niet veel ervaring mee maar ik weet datje daar op kan querien. Doordat de gegevens in een kolom zitten zijn mega-joins ook overbodig toch? Ik weer alleen niet hoe dit drukt op de performance en leesbaarheid van de queries. Alleen heb je daar ook niet iets al referentiele integriteit tussen je PropertyTypen en de inhoud.

Toch bedankt voor het neersabelen van mijn gedachte

[Flard]

Verwijderd schreef op maandag 18 augustus 2008 @ 11:48:
Koppig valt wel mee toch? Ik heb in de voorgaande post al aangegeven dat GEEN goed idee is Ik ben er dus zeker niet op uit om het idee hier te gaan verdedigen.Het weerlegen van de RDBMS voordelen is ook onbegonnen werk.

Ah, het is ook niet zozeer dat je je moet verdedigen. Maar als je met argumenten zou komen, zouden we erachter kunnen komen waar het probleem/misverstand ligt (zou ook best van onze kant kunnen zijn) en zo naar een betere oplossing toe kunnen werken.

Echter ik ben op zoek naar een zo eenvoudig mogelijk onderhoudbare oplossing. Het moeten toevoegen van een tabel per type is niet echt onderhoudbaar te noemen. Voor mij is een alter table ingrijpender dan het toevoegen van een record. Je hebt ook gelijk wanneer je zegt dat het om 3 entiteiten gaat.

Ik denk dat dat je dat gevoel van de ALTER TABLE vs de INSERT moet laten gaan. Het klinkt eng, maar in feite veranderd er toch ook wat aan je probleemdomein / businesscase zodra je een nieuwe eigenschap toevoegt? En waarom is een INSERT beter onderhoudbaar dan een ALTER TABLE?

...
Ik heb nog wel een hersenspinsel...;) Het datatype van het veld waarin de inhoud van eigenschappen wordt opgeslagen zou een XML datatype kunnen zijn. Ik heb hier niet veel ervaring mee maar ik weet datje daar op kan querien. Doordat de gegevens in een kolom zitten zijn mega-joins ook overbodig toch? Ik weer alleen niet hoe dit drukt op de performance en leesbaarheid van de queries. Alleen heb je daar ook niet iets al referentiele integriteit tussen je PropertyTypen en de inhoud.

Ehm.... Data op gaan slaan in een xml-datatype... Wat denk je zelf hoe goed dat performt? Referntiële integriteit? Stel dat je daar een kolom toevoegt? XML datatype is alleen handig als je front-end ook met diezelfde XML-werkt.

Toch bedankt voor het neersabelen van mijn gedachte

Nooit te beroerd om te helpen

[Verwijderd]

Naast sportschool eigensschappen (fitness, sauna aanwezig?) wil ik dus ook vastleggen op welke onderdelen men een sportschool kan waarderen (accomdodatie, service, sfeer). De definitie hiervan kan dan natuurlijk mooi in een child tabel van de tabel met de sportscholen. En dit moet dan ook gebeuren voor andere tabellen. Echter het waardeer systeem moet wel generiek blijven. Dit systeem zou in code gewoon een n aantal waarderingsonderdelen moeten ontvangen. Is dit nog te doen met verschillende tabellen?

Een oplossing hiervoor is om in de tabel waardering een kolom op te nemen met de naam van de tabel. Op die manier blijft de waardering tabel voor ieder object gelijk en kan er 1 systeem worden gemaakt.

Is het een goed idee om de tabeldefinitie van de vastgelegde waarderingsonderdelen (SportschoolWaarderingsOnderdelen met kolommen Accomodatie en Sfeer.) te converteren in code naar generieke atributen (het aantal attributen is afhankelijk van uit welke tabel deze komen) die door het waarderingsfunctie generiek beoordeeld kunnen worden. Dus een sportschool heeft bijvoorbeeld 5 onderdelen die gewaarder kunnen worden, vastgelegd in een tabel en een tv heeft 3 onderdelen. Met een conversie sla geef je aan het waardeersysteem de naam van het onderdeel en een sequentieel nummer mee). Een gebruiker waardeert deze en in code wordt dit weer omgezet naar de juiste kolommen.

[mOrPhie]

WaarderingsOnderdeel (id, beschrijving)
Waardering (id, SportschoolID, WaarderingsOnderdeelID, Score)

Wat is daar mis mee?

[MicroWhale]

is dit wat voor je?

NB er staan honderden generieke databasemodellen op internet. Kijk wat daar tussen zit en gebruik het.

[Verwijderd]

Eerder dit http://www.databaseanswer...ned_hierarchies/index.htm maar wat men hier probeert te bereiken zie ik eigenlijk niet goed... Uitleg?

[mOrPhie]

Heb je mijn post gezien en kun je uitleggen waarom dat niet is wat je zoekt? Ik heb namelijk sterk de indruk dat je de taak overschat.

[Verwijderd]

mOrPhie schreef op dinsdag 19 augustus 2008 @ 16:31:
Heb je mijn post gezien en kun je uitleggen waarom dat niet is wat je zoekt? Ik heb namelijk sterk de indruk dat je de taak overschat.

Ja zeker heb ik die post gezien, ik ga ook verder op die voet. Ik dacht dat MrWilliams een oplossing aan wilde dragen voor het probleem wat ik had met een generieke entiteiten tabel, daarom pakte ik een een ander daarop lijkend voorbeeld van die site.

[MicroWhale]

Verwijderd schreef op dinsdag 19 augustus 2008 @ 16:06:
Eerder dit http://www.databaseanswer...ned_hierarchies/index.htm maar wat men hier probeert te bereiken zie ik eigenlijk niet goed... Uitleg?

Geef je hierboven aan dat je niet weet hoe je een dergelijk diagram moet lezen? ... en dat terwijl je een database wilt ontwerpen? In dat geval zou ik me eens in gaan lezen in de materie. Wat is een database, hoe kan ik het beste data structureren, wat zijn gangbare notatiemethoden en hoe moet/kan ik die lezen, etc...

Je zei dat je een review wilde kunnen doen op een sportzaal. Het diagram wat ik voorstelde (met de tabellen "things being reviewed", "review" en "features"... lijken me een prima basis van waaruit je je eigen model kan gaan ontwikkelen.

Ik zou hier de attributen van het thing aan de review willen koppelen, zodat er een directe relatie kan ontstaan tussen de review en het gereviewde onderdeel van het thing. thing is in jouw context (een onderdeel van) de sportfaciliteit.

[MicroWhale]

Verwijderd schreef op dinsdag 19 augustus 2008 @ 16:42:
[...]


Ja zeker heb ik die post gezien, ik ga ook verder op die voet. Ik dacht dat MrWilliams een oplossing aan wilde dragen voor het probleem wat ik had met een generieke entiteiten tabel, daarom pakte ik een een ander daarop lijkend voorbeeld van die site.

met als doel?

Je voorbeeld lijkt in de verste verte niet op wat ik aandroeg.

[Verwijderd]

De reden voor het openen van mijn topic was dat ik zocht naar een model om een willekeurig product met eigenschappen in op te kunnen slapen. Per object (sportschool, tv) kunnen eigenschappen afwijken (faciliteiten, beeldiagonaal) met als gevolg dat ook datatypen kunnen afwijken. Omdat ik mijn twijfels had over deze aanpak heb ik dit topic aangemaakt. Door andere users is het idee van 1 objecttabel met 1 eigenschappen tabel met goede redenen van tafel geveegd, welke hier boven staan opgenoemd.Het komt er op neer dat ik voor dit 'probleem' een verkeerde oplossing had bedacht waarin al velen zijn ingestonken.

Het andere deel van het datamodel bestaat inderdaad uit een opzet om reviews te kunnen opslaan op een manier die ik nodig heb voor de applicatie. Met de opzet hiervan heb ik absoluut geen probleem. Immers dit is ook vrij eenvoudig. Jij gaf een voorbeeld van een review datamodel. Ik was hier niet meer naar op zoek. Misschien was ik daarin onduidelijk. Maar wel bedankt voor je hulp natuurlijk.

Inmiddels heb ik het probleemdomein versmalt waardoor een aantal zaken eenvoudiger wordt. Dit vind ik niet erg omdat mijn leerdoelen ergens anders liggen (Object Role Modelling toepassing, de relatie tussen een entiteiten model kennen en een relatiemodel dus hoe verhouden tabellen zich tot entiteiten, hoe laten relaties zich vertalen associations, hoe inheriatance patronen uit een tabelstructuur te halen, etc..)

Ik zal een post doen in dit topic wanneer ik een eerste versie van het relationele model en objecten model heb.