[ALG] Opslaan data CMS

[Verwijderd]

Momenteel zijn we bezig met het ontwikkelen van een CMS waarin dynamisch modules kunnen worden gedefinieerd. Probleem waar we nu tegenaan lopen is het opslaan van de data. Iedere module bestaat uit een te definieren aantal velden met verschillende data types. Voor het opslaan hebben we een aantal mogelijkheden bedacht:

1. Per datatype een aparte tabel
2. Per module dynamisch tabellen genereren
3. XML genereren met alle data en die in een text opslaan in de database

Problemen die daarbij optreden zijn ongeveer:

1. Veel joins nodig om alle data voor een item op te halen
2. Onhandig voor het generiek implementeren van functies voor verschillende modules
3. Geen directe ORDER BY en GROUP BY mogelijk via de database, moet zelf een parser voor geschreven worden

Dit zijn op dit moment onze mogelijkheden, zijn hier nog andere ideeen over en zijn er meer voor en nadelen te noemen voor de verschillende mogelijkheden ?

[Reveller]

Bij Drupal gaan ze ervan uit dat elk datatype in principe eenzelfde structuur heeft, genaamd een node:

code:

  `nid` int(10) unsigned NOT NULL auto_increment,
  `type` varchar(16) NOT NULL default '',
  `title` varchar(128) NOT NULL default '',
  `score` int(11) NOT NULL default '0',
  `votes` int(11) NOT NULL default '0',
  `uid` int(10) NOT NULL default '0',
  `status` int(4) NOT NULL default '1',
  `created` int(11) NOT NULL default '0',
  `comment` int(2) NOT NULL default '0',
  `promote` int(2) NOT NULL default '0',
  `moderate` int(2) NOT NULL default '0',
  `users` text NOT NULL,
  `attributes` varchar(255) NOT NULL default '',
  `teaser` text NOT NULL,
  `body` text NOT NULL,
  `changed` int(11) NOT NULL default '0',
  `revisions` text NOT NULL,
  `static` int(2) NOT NULL default '0',

Zo hebben een guestbook entry, weblog post, artikel, product, etc. allemaal dezelfde properties gedefinieerd (title, teaser, body, attributes...). Door deze uniforme "alles is een node" aanpak is het in principe niet nodig om voor elk datatype een aparte tabel te maken. Natuurlijk zul je wel andere oplossingen moeten zoeken voor datatypen (agenda bv.) die een totaal andere structuur vereisen.

Onnodig te zeggen natuurlijk dat dit qua ophalen van data ontzettend efficient is.

[ Voor 12% gewijzigd door Reveller op 25-01-2005 13:19 ]

[bigbeng]

Nu alleen nog een veldje om hiërarchische data (boomstructuur, parent/child) op te kunnen slaan en bijna compleet.

[Bosmonster]

Je kunt ook een tabel gebruiken voor alle data en de velden dynamisch toekennen. Dus je hebt een tabel met een type (bijvoorbeeld 1-10 ofzo) en data velden van verschillende types (bijvoorbeeld data_1 = varchar, data_2 = int, data_3 = tinyint(1) voor boolean, data_4 = datetime, etc

Je kunt alle velden ophalen, aangezien er toch maar 1 gevuld zal zijn. Welke weet je aan het type en kun je in code eenvoudig terughalen. Je haalt wel veel velden op, maar het meerendeel is leeg, dus overhead is geen probleem.

Kweet niet in hoeverre dit voor een CMS toepasbaar is, maar voor een applicatie waar we enorme hoeveelheden dynamische formulieren hadden was dit de makkelijkste manier van opslag.

[ Voor 16% gewijzigd door Bosmonster op 25-01-2005 13:34 ]

[Verwijderd]

De snelst, eenvoudigste, en meeste flexibele manier blijft nog altijd een simpele object & property tabel. Daarbij sla je dan je content op per propertyid, en is elk content item gebaseerd op een instantie van een object.

[BierPul]

Verwijderd schreef op dinsdag 25 januari 2005 @ 13:36:
De snelst, eenvoudigste, en meeste flexibele manier blijft nog altijd een simpele object & property tabel. Daarbij sla je dan je content op per propertyid, en is elk content item gebaseerd op een instantie van een object.

Kan je eens een voorbeeld geven

[Verwijderd]

Het meest simpele voorbeeld wat ik maar kan bedenken. Met onderstaand model kan je elk soort data van elk soort object opslaan in welke hoeveelheid dan ook, en flexibel als de pest.

code:

object table:
id    objectname
 1    artikel

property table:
id    objectid     propertylabel
 1             1                  titel
 2             1                  body

instantie table:
id    objectid                 label
 1             1        mijn artikel

content table:
id     propertyid     instantieid                value
 1                 1                  1           mijn titel
 2                 2                  1           mijn body

[MisterData]

Áls je overigens nodes hierarchisch wil opslaan moet je eens googlen naar het Celko treemodel, dat kan een aantal (meestal recursief geimplementeerde queries) behoorlijk eenvoudiger en sneller maken (hoewel met bijhouden van de tree iets meer werk kost) Ik gebruik het zelf ook.

[Skaah]

MisterData schreef op dinsdag 25 januari 2005 @ 17:50:
Áls je overigens nodes hierarchisch wil opslaan moet je eens googlen naar het Celko treemodel, dat kan een aantal (meestal recursief geimplementeerde queries) behoorlijk eenvoudiger en sneller maken (hoewel met bijhouden van de tree iets meer werk kost) Ik gebruik het zelf ook.

Ik heb hier nog wel een klasse voor met veel kennis over deze bomen, mail me ff als je intresse hebt.

[Verwijderd]

MisterData schreef op dinsdag 25 januari 2005 @ 17:50:
Áls je overigens nodes hierarchisch wil opslaan moet je eens googlen naar het Celko treemodel, dat kan een aantal (meestal recursief geimplementeerde queries) behoorlijk eenvoudiger en sneller maken (hoewel met bijhouden van de tree iets meer werk kost) Ik gebruik het zelf ook.

Het Celko model is echter wel een 1 op 1 relatie, en als je content wilt hergebruiken kun je beter voor een koppeltabel gaan.

[MisterData]

Verwijderd schreef op dinsdag 25 januari 2005 @ 19:18:
[...]


Het Celko model is echter wel een 1 op 1 relatie, en als je content wilt hergebruiken kun je beter voor een koppeltabel gaan.

Ja, dat is toch te combineren? Als je Celko gebruikt in je koppeltabel dan

[mocean]

Ik gebruik zelf voor een dergelijke toepassing een databasemodel dat in staat is dynamisch objecten en eigenschappen op te slaan:


Elk object is van een bepaald type. Deze types staan ook in de tabel. Elk object bestaat weer uit een set properties. Alle (meta)gegevens kunnen zo worden gedefinieerd.

Binnen dit systeem gebruik ik relations om objecten aan elkaar te hangen (zoals bijvoorbeel deen parent-child relation.) Meer uitleg (Engels) heb ik ooit eens hier gepost: http://www.phpinsider.com/smarty-forum/viewtopic.php?t=892

[Tux]

Verwijderd schreef op dinsdag 25 januari 2005 @ 16:57:

code:

content table:
id     propertyid     instantieid                value
 1                 1                  1           mijn titel
 2                 2                  1           mijn body

Wat voor type heeft het value veld dan? Ik neem aan dat het ook mogelijk moet zijn om bijvoorbeeld afbeeldingen, word documenten en pdf documenten op te slaan. Is het BLOB? Of staat er in de database alleen een verwijzing naar een file op de harddisk?

[ Voor 8% gewijzigd door Tux op 25-01-2005 20:53 ]

[Verwijderd]

Value kun je text laten als je wilt, maar je kunt ook columns definieren voor andere datatypes, die je vervolgens via een property definieert. Het hangt ook een beetje af wat voor taal je gebruikt.

Zelf gebruik ik wel datatype columns, en dan krijg je dus bijv.

id,instantieid,propertyid,value_text,value_int,value_datetime

met in de property table per property een tinyint welke het datatype aangeeft.

Het hangt een beetje af of je de keuze maakt alles in een text veld op te slaan. Er zijn voor MS SQL Server manieren om een text veld te manipuleren zodat hij zich gedraagt als een snelle varchar bij table scans waarbij alle extra informatie via pointers wordt opgeslagen.

Voor text maak ik ook nog een extra column aan waarbij de content is ontdaan van markup, aangezien full text search daar moeite mee heeft.

Ik heb nog een ouder model van een diagram online staan zonder de datatype properties.
http://www.mschopman.demon.nl/diagram.gif

[ Voor 75% gewijzigd door Verwijderd op 25-01-2005 21:46 ]

[Tux]

Verwijderd schreef op dinsdag 25 januari 2005 @ 21:36:
Value kun je text laten als je wilt, maar je kunt ook columns definieren voor andere datatypes, die je vervolgens via een property definieert.

Dus dan stel je bij de properties in dat het inhoud veld van een artikel bijvoorbeeld TEXT is, en het type van het attachment veld BLOB (met een `DataType enum('text', 'blob', 'int')` bijvoorbeeld. Vervolgens geef je de Content tabel ongeveer zo'n formaat:

code:

id     propertyid     instantieid   textvalue   blobvalue   intvalue

[ Voor 10% gewijzigd door Tux op 25-01-2005 21:42 ]

[Verwijderd]

Verwijderd schreef op dinsdag 25 januari 2005 @ 11:34:

• Veel joins nodig om alle data voor een item op te halen

Afhankelijk van je model, indices, en relations, en queries is dit verwaarloosbaar. Ik heb queries met wel 10+ joins die nog onder de 0ms worden uitgevoerd. Het hangt wel van de uitgevoerde query af, en de volgorde ervan.

[Verwijderd]

De topicstarter laat nog maar weinig van zich horen ondanks de moeite die meerdere personen nemen op zijn vraagstelling, dus .. baby ruttah hoe staat het ermee of lopen we hier voor niets je vraag te beantwoorden ?

[djluc]

Je opmerkingen zijn zeker interessant en worden zeker gelezen

Het is en blijft een mooie methode om dit in objecten op te slaan. Ik zit er over te denken om binnenkort een keer een prettige class te schrijven om dit beheerbaar te kunnen doen.