[cms/php] cms db opzet

[gomaster]

Ik ben bezig een db opzet te maken voor mijn cms. Ik zit alleen met een probleem, ik heb helaas nog geen vergelijkbare vragen hier en elders gevonden.
In mijn cms moet het mogelijk worden meerdere soorten content weer te geven. In het begin zal dit alleen nog een standaard pagina en een contact formulier worden, later wil ik dit graag uitbreiden (classes zijn zeer handig ).

Ik zat er zelf aan te denken ieder type content een eigen tabel te geven, immers voor het opslaan van een standaard pagina zijn andere velden nodig dan het opslaan van een form.
Dan in een soort van koppeltabel het ID van de pagina + de contentid neer te zetten. Dan weet ik dus straks in welke tabel ik moet zoeken.
Tot slot zet ik in de tabel van het menu de ID van de pagina die dan weer in de koppeltabel staat.
Voor de duidelijkheid even een plaatje waarbij het user gedeelte natuurlijk niet van belang is



Naar mijn idee is dit een vrij onlogische oplossing, ik kan alleen niks beters bedenken. Zijn er hier mensen die er meer verstand van en ervaring mee hebben?

edit: Die binary varchar(0) dingen kloppen natuurlijk niet maar dat heb ik al gewijzigd voordat daar posts over komen

[ Voor 6% gewijzigd door gomaster op 19-04-2004 17:13 ]

[creative8500]

En hoe wil je de volgorde der menuitems bepalen?

[djluc]

En hoe lokaliseer je dingen op een bepaalde plaats in je CMS? Dus bijvoorbeeld op welke pagina?

[dream0r]

djluc schreef op 19 april 2004 @ 19:08:
En hoe lokaliseer je dingen op een bepaalde plaats in je CMS? Dus bijvoorbeeld op welke pagina?

Waarschijnlijk met het Content-ID

[djluc]

Skizzik schreef op 19 april 2004 @ 19:14:[...]Waarschijnlijk met het Content-ID

Ik mis daar toch echt wat gegevens, een id zegt opzich helemaal niets. Als je bijvoorbeeld uitgaat van een tree structuur worden bepaalde content items weer onder andere gehangen en zo zie je het verband tussen de items. Dat kan ik nog niet uit de opzet van de TS halen.

Of is het systeem zo eenvoudig dat ik me dit nog niet helemaal voor had gestelt: alle pagina's zijn 1 rij in de content tabel?

@ts: duidelijke afbeelding trouwens, zo met die kleuren.

[ Voor 13% gewijzigd door djluc op 19-04-2004 19:17 ]

[Verwijderd]

De 'layout' van de pagina's wordt (volgens mij) bepaald door de menu table. Zo als je ziet verwijst daar een column naar de parent (kan beter de parent_id zijn denk ik zo).

Maar wat ik mij nou afvraag hoe koppelt de TS een content(_type) aan de content table of hoe houd de TS de verschillende content_types uitelkaar, want ik zie maar 1 id die aan content(_type) verwijst in de content table.

[Jaspertje]

Ik zie dat je in de tabel Menu title en parent allebei opvarchar 20 hebt staan. SQL Server heeft nvarchar (weet niet welk DBMS je gebruitt (voorspel MySQL heeft deze dat niet?)
En zou je van een <pk> niet ten alle tijden een int maken?

En begrijp ik goed dat je nu voor iedere pagina een nieuwe tabel gaat maken? (als iedere pagina een content is?)

[ Voor 22% gewijzigd door Jaspertje op 19-04-2004 19:51 ]

[djluc]

En begrijp ik goed dat je nu voor iedere pagina een nieuwe tabel gaat maken? (als iedere pagina een content is?)

Daar lijkt het wel op inderdaad. Wat me vooral zo vervelend lijkt is iets als: je wilt op een evenementenpagina onder de omschrijving van het evenement een fotoboek tonen. Hoe los je dat soort zaken op?

[gomaster]

creative8500 schreef op 19 april 2004 @ 19:04:
En hoe wil je de volgorde der menuitems bepalen?

daar moet ik nog even naar kijken maar moet met een nummertje en order by kunnen.

djluc schreef op 19 april 2004 @ 19:08:
En hoe lokaliseer je dingen op een bepaalde plaats in je CMS? Dus bijvoorbeeld op welke pagina?

wat wil je dan kunnen lokaliseren?

Verwijderd schreef op 19 april 2004 @ 19:24:
De 'layout' van de pagina's wordt (volgens mij) bepaald door de menu table. Zo als je ziet verwijst daar een column naar de parent (kan beter de parent_id zijn denk ik zo).

Maar wat ik mij nou afvraag hoe koppelt de TS een content(_type) aan de content table of hoe houd de TS de verschillende content_types uitelkaar, want ik zie maar 1 id die aan content(_type) verwijst in de content table.

Hmm ja daar zit wat in. Ik denk dat ik net met jouw post wel iets aardigs heb bedacht.
Als ik nou de hele content tabel wegdoe en in de tabellen met types de id zet die ook in menu staat. Ik dacht uit mn hoofd (zo goed ben ik niet in sql) dat je dan de 2 tabellen op een hoop kan gooien en zo de id's kan zoeken. Is dat niet zo?

Jaspertje schreef op 19 april 2004 @ 19:50:
Ik zie dat je in de tabel Menu title en parent allebei opvarchar 20 hebt staan. SQL Server heeft nvarchar (weet niet welk DBMS je gebruitt (voorspel MySQL heeft deze dat niet?)
En zou je van een <pk> niet ten alle tijden een int maken?

En begrijp ik goed dat je nu voor iedere pagina een nieuwe tabel gaat maken? (als iedere pagina een content is?)

Idd gebruik ik mysql, wat is het voordeel van nvarchar? Als <pk> zet ik denk ik idd toch maar een int neer.
Ik maak niet voor elke pagina een nieuwe tabel. Ik maak voor elk soort een nieuwe tabel, en in die tabel is dan de pagina met dat soort een rij.

iig bedankt voor de reacties tot nu toe. Ik ga de tekening eens wat aanpassen

edit:

djluc schreef op 19 april 2004 @ 20:16:
[...]
Daar lijkt het wel op inderdaad. Wat me vooral zo vervelend lijkt is iets als: je wilt op een evenementenpagina onder de omschrijving van het evenement een fotoboek tonen. Hoe los je dat soort zaken op?

Hmm dat is een goeie. Daar moet ik denk ik ook maar eens over na gaan denken.

Het valt nog niet mee zoiets bedenken

[ Voor 11% gewijzigd door gomaster op 19-04-2004 20:24 ]

[Jaspertje]

Een nvarchar heeft als voordeel tov de varchar dat als je varchar(20) zecht en je zet test neer, dat ie 16 'spaties' neerzet.. bij nvarchar doet ie dat niet..

En je had nog geen int staan bij de pk van menu.. en ook niet bij parent.. wat een verwijsende sleutel is volgens mij en geen pk kan zijn aangezien de top toch gewoon NULL is?

Wat ga je precies in de db opslaan de hele HTML?

[gomaster]

Jaspertje schreef op 19 april 2004 @ 20:54:
Een nvarchar heeft als voordeel tov de varchar dat als je varchar(20) zecht en je zet test neer, dat ie 16 'spaties' neerzet.. bij nvarchar doet ie dat niet..

En je had nog geen int staan bij de pk van menu.. en ook niet bij parent.. wat een verwijsende sleutel is volgens mij en geen pk kan zijn aangezien de top toch gewoon NULL is?

Wat ga je precies in de db opslaan de hele HTML?

Volgensmij is varchar dan hetzelfde in mysql als nvarchar. Als je hier kijkt dan geven ze als voorbeeld dat char spaties neerzet en varchar niet.
Alle <pk>'s ook gefixed.
Ik ben van plan een soort van ubb tags in de db op te slaan. Zodat output naar van alles mogelijk is.
Na wat nadenken: is het niet mogelijk om een tag te maken voor bv een fotoalbum (neem: [fotoalbum]) en die te laten replacen door een class die het fotoalbum regelt. Dan maak je daar weer een content type tabel voor aan en heb je dat ook weer. Of zit ik nu helemaal fout te denken.

Nieuwe opzet waarbij de tussentabel is weggegaan en de id's in de menutabel worden gemaakt en worden verspreid over de verschillende content types tabellen.

[djluc]

Misschien niet geheel relevant naar aanleiding van je voorbeeldje maar denk eens na over een tree structuur. Je moet je systeem dus heel modulair opbouwen:
Je maakt modules en submodules. Je kunt dan in je tree dus ook de submodules aanroepen. Je moet er maar even over nadenken. Misschien zie je dan wel meer mogelijkheden. Je kunt dus onder een pagina meerdere items hangen.

[gomaster]

djluc schreef op 19 april 2004 @ 22:18:
Misschien niet geheel relevant naar aanleiding van je voorbeeldje maar denk eens na over een tree structuur. Je moet je systeem dus heel modulair opbouwen:
Je maakt modules en submodules. Je kunt dan in je tree dus ook de submodules aanroepen. Je moet er maar even over nadenken. Misschien zie je dan wel meer mogelijkheden. Je kunt dus onder een pagina meerdere items hangen.

Dus je bedoeld:
je hebt de module pagina en submodules foto album, paragraaf, lijst en formulier. Maar sla je dan alle info van alles soorten submodules die bij pagina horen in dezelfde tabel op of heb je daar weer aparte tabellen voor.
En hoe geef je dan de volgorde in de tree aan? Je wilt bijv eerst de paragraaf dan de foto's dan een formulier en ten slotte een lijstje. Maar ergens anders weer op een andere volgorde.

[Verwijderd]

Mja, eigenlijk meer een geheim van de kok, maar probeer objecten, properties, content, templates, prioriteiten, posities, versies en relaties te scheiden. Zoveel mogelijk.

Dus bijvoorbeeld:
table object:
objectid = 1
objectkey = page

table property:
propertyid = 1
objectid = 1
propertykey = title

propertyid = 2
objectid = 1
propertykey = body

En dan een table content
contentid = 1
objectid = 1
propertyid = 1
value = 'de titel'

contentid = 1
objectid = 1
propertyid = 2
value = 'template.html'


Uiteraard komt er veel meer bij kijken, maar je creeert zo een enorm schaalbaar systeem.

[Jaspertje]

Zo een contact formulier, wat levert het nou op om het in een aparte tabel neer te zetten?

Ik neem aan dat je niet 23 contact formulieren op je website wilt? En zop ja, wat is er dan zo verschillend aan al deze formulieren..

[djluc]

Jaspertje schreef op 19 april 2004 @ 23:07:
Zo een contact formulier, wat levert het nou op om het in een aparte tabel neer te zetten?
Ik neem aan dat je niet 23 contact formulieren op je website wilt? En zop ja, wat is er dan zo verschillend aan al deze formulieren..

Er wordt hier getracht een flexibel CMS op te zetten. Dat hoeft sowieso al niet voor 1 website te zijn...

[Parcye]

Met wat tegenwoordig allemaal met JS kan, heb je niet veel meer nodig dan een paar veldjes en alle pagina's bij elkaar in een tabel.

Zelf zou ik zo iets doen:

Id
Title
Content(via WYSIWYG editor gevuld)
CreateDate
EditDate
DeleteDate (Werk zelf met een trashcan)
VisibleInMenu (pagina die niet in het menu hoeft te komen maar bijvb een doorlink pagina is)
Enabled (pagina aanmaken maar nog niet gebruiken)
OwnerId (onder welke pagina komt deze in het menu)
PositionInMenu (Volgoorde in menu bepalen)
SearchWords (voor de zoekmachine op de site)
SearchDescription (voor de zoekmachine op de site)

Meer heb je dan niet nodig, je kan ook wel werken met user_id en allerlei rechten, maar dat is dan ook eenvoudig toe te voegen.

[gomaster]

Verwijderd schreef op 19 april 2004 @ 22:39:
Mja, eigenlijk meer een geheim van de kok, maar probeer objecten, properties, content, templates, prioriteiten, posities, versies en relaties te scheiden. Zoveel mogelijk.

Dus bijvoorbeeld:
table object:
objectid = 1
objectkey = page

table property:
propertyid = 1
objectid = 1
propertykey = title

propertyid = 2
objectid = 1
propertykey = body

En dan een table content
contentid = 1
objectid = 1
propertyid = 1
value = 'de titel'

contentid = 1
objectid = 1
propertyid = 2
value = 'template.html'


Uiteraard komt er veel meer bij kijken, maar je creeert zo een enorm schaalbaar systeem.

Dat is een hele goeie tip. Ik ga dit nu eens even rustig uitwerken!

@Parcye:
Is ook iets om over na te denken maar dan geef je de user denk ik toch te veel vrijheid. Maar misschien maak ik wel een combi tussen deze 2.

Allemaal heel erg bedankt voor het reageren. Het heeft me een hoop nieuw materiaal opgelevert.

[PhoeniX-]

Ik heb een zelfde soort systeem uitgewerkt, alleen is de basis denk ik net wat uitgebreider.
Als ik zie hoe belangrijk het scheiden, en op kunnen vragen van content_types bij mij is, is het denk ik erg handig om een aparte content_types tabel aan te maken. Adhv het content_type_id is de informatie dan weer te achterhalen (tablename, classname, bedenk zelf maar hoe nuttig dat kan zijn ).
Mijn content_type tabel ziet er zo uit bijvoorbeeld:

code:

+------------+--------------+------+-----+---------+----------------+
| Field      | Type         | Null | Key | Default | Extra          |
+------------+--------------+------+-----+---------+----------------+
| id         | tinyint(4)   |      | PRI | NULL    | auto_increment |
| filename   | varchar(200) |      | MUL |         |                |
| class_name | varchar(100) |      |     |         |                |
| table_name | varchar(100) |      |     |         |                |
+------------+--------------+------+-----+---------+----------------+

Verder heb ik in een soort template de layout gedefinieerd (er kunnen meerdere templates zijn, voor verschillende pagina layouts), waarin op bepaalde plaatsen een 'view' wordt gekoppeld. Deze plaatsen zijn 'slots'. Een view hoort bij een bepaald content type (news_detail hoort bij content type 'news' bijvoorbeeld).
Op basis van een template is een pagina te maken, in elke pagina op basis van dezelfde layout, kan je dus andere views gebruiken, en bv. een geheel andere indeling maken.
Zo is in principe als een soort blokkendoos alles in elkaar te klikken.
Een template staat in het filesysteem, views staan in de database.

Het enige waar ik nog een keer aan moet werken is de views en de templates, dat mag best wat gebruiksvriendelijker

Het is vrij lastig uit te leggen in 't kort, als je nog meer wilt weten moet je maar even contact opnemen

[bat266]

Zelf ben ik nu ook bezig iets dergelijks op te zetten dus ik zal deze thread met belangstelling blijven volgen

[Rusky]

wil ook een keer een cms maken voor mijn site, die ik dan eventueel kan gebruiken voor andere sites. Maar probleem is, ik wil zoveel, en heb zo weinig tijd. Maar ik vind het ook echt interessant om te weten hoe zoiets in elkaar zit.

Ik zat meer met het probleem hoe je de files aannmaakt. Of maak je 1 file die vanalles include in een bestand. Dat soort dingen. en vooral hoe regel je de opmaak? een header bv. iedere site wil die anders hebben, hoe regel je dat?

[Verwijderd]

Ik ben momenteel volgens het eerder voorgelegde model (alleen is het model bij mij dan factor 10 groter) al bezig met een 3de versie van het systeem. De 2de versie zijn een tijdje geleden nog screens van gepost in W&G

Momenteel draaien +/- 50 clienten op één database structuur, en haal ik bij load tests een resultaat van 385 hits/sec bij 200 concurrent users. Het model is gewoon een bewezen stabiel model, en dmv diverse trucjes kun je voornamelijk de content table stukken sneller maken op de text fields.

[gomaster]

Ik denk dan ook dat ik het model van Gordijnstol ga uitwerken. Aangezien het mij ook zeer felexibel lijkt
@rusky:
Ik ben van plan het OO te maken. Alle classes include je gewoon . Opmaak doe je met templates. Kun je later precies zeggen wat waar moet.

[Verwijderd]

gomaster schreef op 20 april 2004 @ 14:37:
Ik denk dan ook dat ik het model van Gordijnstol ga uitwerken. Aangezien het mij ook zeer felexibel lijkt
@rusky:
Ik ben van plan het OO te maken. Alle classes include je gewoon . Opmaak doe je met templates. Kun je later precies zeggen wat waar moet.

Met als voordeel dat je onbeperkt aantal objecten kunt maken, onbeperkt aantal properties kunt maken, en desondanks gewoon met een polyhierarchy kunt blijven werken.

[Rusky]

gomaster schreef op 20 april 2004 @ 14:37:
Ik denk dan ook dat ik het model van Gordijnstol ga uitwerken. Aangezien het mij ook zeer felexibel lijkt
@rusky:
Ik ben van plan het OO te maken. Alle classes include je gewoon . Opmaak doe je met templates. Kun je later precies zeggen wat waar moet.

ik doe het altijd zo:

template ---> include bestand bv. een adres boek... daaraan hang ik een css.
mischien een domme vraag, maar wat is OO???

[Verwijderd]

offtopic:
Object Orientated Programming

[Verwijderd]

Rusky schreef op 20 april 2004 @ 15:19:
[...]


ik doe het altijd zo:

template ---> include bestand bv. een adres boek... daaraan hang ik een css.
mischien een domme vraag, maar wat is OO???

Met het db model kun je stukken hoger gaan zitten.

init
- verkrijg root object
- haal properties bij het object op
- gebruik properties voor de presentatielaag

etc.etc.

Het enige wat je moet hebben is een start punt in de database, of je daar nu de eerste pagina van maakt, of een object domain aanmaakt, dat moet je maar bekijken.