[DB/XML] xml genereren of als xml bewaren

[Verwijderd]

Stel dat je op basis van data in een database een webpagina wilt genereren met als tussenstap XML. Dan kun je twee dingen doen.

1. De data in de database opslaan als XML, je hoeft dan nog slechts de boel te transformeren met XSLT (of door de domxmltree lopen en een template invullen). Nadeel: met xmldata in een database niet meer snel en fijn je data kunt filteren en sorteren met een sql-query als je bijvoorbeeld alleen de elements <title> en <data> uit een heleboel xml-stukjes van het type <message> wilt hebben.
Voordeel: Alle soorten data kunnen in dezelfde dbtable, dus supergeneriek.

2. De data op een 'normale' manier in een netjes geconstrueerde database zetten. Je query uitvoeren, xml genereren, en vervolgends of wat voor manier dan ook transformeren naar xslt. Voordelen: snel filteren/sorteren van je data, en makkelijk gebruiken van je data in verschillende views.
Nadeel: het kost een extra stap en daarom parsetime. Tevens zul je alsnog voor alle soorten data verschillende tables moeten maken waardoor het dus meer werk kost om een nieuw soort pagina te maken.

Als je het zo bekijkt lijkt het helemaal niet zo praktisch om xml te gebruiken alhoewel het principe wel zeer aanlokkelijk vanwere de potentiele generiek-heid.

Zie ik mogelijkheden over het hoofd? Zijn er nog andere suggesties wat betreft manieren om XML te gebruiken in een website of cms als je van templates af wilt?

Je zou userattributes of rechten bijvoorbeeld ook nog kunnen opslaan als xmlstring. Tevens zou je een form waarmee je de userattributes kunt wijzigen weer beschrijven in xml. De mogelijkheden zijn oneindig maar hoe praktisch zijn ze, wat is jullie mening?

[Verwijderd]

Persoonlijk ga ik voor de tweede optie. Als je zo graag die xml generatie stap wilt overslaan sla dan alles op in xml bestanden en gebruik die hele database niet (die heeft dan toch nauwlijks voordelen). Maar persoonlijk sla ik alles gewoon op in de database, genereer uit die data een interne XML boom en transformeer die met XSLT naar HTML.

[Verwijderd]

Hmm je zou ook alles wat altijd maar 1 view heeft als xml op kunnen slaan en de rest met modules in hun eigen tables. Dus een soort van base content als xml en de rest wordt door een module eerst uit de database gehaald en naar xml omgezet. Het transformeren naar html kan bij beide soorten door hetzelfde systeem gebeuren.

[mbravenboer]

fladder: Als je het zo bekijkt lijkt het helemaal niet zo praktisch om xml te gebruiken alhoewel het principe wel zeer aanlokkelijk vanwere de potentiele generiek-heid.

XML is met name bedoeld als methode om data uit te wisselen tussen verschillende software componenten en applicaties. Als je data duidelijk maar in 1 applicatie gebruikt en er dus geen uitwisseling plaats vindt met andere componenten kan XML omslachtig zijn. De toepassing van XML kan in deze situatie echter wel erg inspirerend werken en je aanzetten om je applicatie toch in meerdere onderdelen op te zetten. Hier kan je bij onverwachte wendingen misschien erg veel baat bij hebben.

Over XML versus een relationele database: het hierarchische model van XML kan erg aantrekkelijk zijn tov van een relationele database als je data ook echt hierarchisch is. Verder kan XML erg aantrekkelijk zijn door de grotere flexibiliteit van het semi gestructureerde data model. De nadelen die hieraan kleven geef je zelf al wel aardig aan, dus ik denk wel dat je die goed beseft.

Ik denk dat het belangrijk is om onderscheid te maken tussen 'intensieve' data en data die nodig is voor de structuur van je site. Intensieve data zou ik willen omschrijven als data waarop je graag queries wilt uitvoeren, data waar performance belangrijk is, waar locks en synchronizatie belangrijk zijn enzovoorts. Dergelijke data wil je graag laten beheren door een systeem. Dit kan een relationele database zijn, maar misschien ook wel een xml database.

Misschien dat je niet voor a of b moet kiezen: er is niets op tegen om een deel van de site (de intensieve data) te laten beheren door een relationele database systeem en een ander deel van je site te beschrijven in XML. Deze opzet heb ik onlangs nog vrij succesvol toegepast.

[zoepercavia]

Verwijderd schreef op 08 september 2002 @ 13:19:
Als je het zo bekijkt lijkt het helemaal niet zo praktisch om xml te gebruiken alhoewel het principe wel zeer aanlokkelijk vanwere de potentiele generiek-heid.

xml is inderdaad niet altijd beter voor alle oplossingen. Ik zelf ben bijvoorbeeld een tijdje bezig om een site geheel te herschrijven naar xml/xslt (dus alle data in xml genereren en serverside een XSL er overheen). Soms is het echt een hel om met xsl hetzelfde te bereiken als met serverside gegenereerde HTML en werkelijk omslachtig.

Echter de generiekheid kan een inderaad een groot voordeel opleveren. Zo kan ik nu met groot gemak mijn xml documenten in elk gewenst formaat omzetten zonder dat dat in veel aanpassing van mijn ASP code vergt. Ook nieuwe layouts kunnen door de layouter gemaakt worden zonder veel kennis van de technische kant (wel natuurlijk van XSL).

XML/XSL is niet zaligmakend, maar kan naar mijn mening in veel toepassingen gebruikt worden. Daarnaast dwingt een xml document je goed over de opbouw van je site na te denken

[Verwijderd]

De toepassing van XML kan in deze situatie echter wel erg inspirerend werken en je aanzetten om je applicatie toch in meerdere onderdelen op te zetten. Hier kan je bij onverwachte wendingen misschien erg veel baat bij hebben.

Inderdaad, onlangs zo'n gevalletje gehad. Statistieken van de webactiviteiten (omzet e.d.) koppelen aan de statistieken van de verkoop via de reguliere activiteiten en dat gekoppeld in een Excel sheet gepropt. Ik laat nu dus iedere maandagochtend het resultaat automatisch in het mail boxje van de heren managers dumpen.

Toen de opzet van de website gemaakt werd waren alleen de stats van de website genoeg. Later wordt er in gezien wat er nog meer mogelijk is en veel uitgebreidere rapportage mogelijk is.

Vandaar dat de opmerking van MBRAVENBOER de spijker op zijn kop slaat.

[drm]

mbravenboer: e.e.a.

Daaraan zou ik nog even toe willen voegen dat 't geen kwaad kan onderscheid te maken tussen de XML die output is, en de XML die je (hypothetisch) als database gebruikt. Ik bedoel daarmee dat je XML die "output" is (een boompje met title, content, author, datum etc...) niet als zodanig in een relationele database op moet slaan, puur omdat je 2 prima technieken op zo'n manier combineert dat de technieken elkaar uitsluiten, ajbwib, zoals je ei'k zelf al aangeeft.

Kortom, ik denk dat de datasource er opzich los van moet staan, van op welke manier je je zooi output. Dat die 2 dan kunnen overeenkomen (datasource XML mbv. XSLT, output XML mbv. XSLT), dat zou ik dan niet meer als een "toevallige" overeenkomst zien.

Ik hoop dat je een beetje begrijpt wat ik probeer te zeggen

[Verwijderd]

Dan zou ik dus modules kunnen maken die al dan niet hun data in xml uit hun database of een file halen, en het al dan niet omzetten naar (eventueel naar een andere boom) xml en dit leveren aan het gedeelte van het systeem dat het ergens naartoe kan transformen, bijvoorbeeld imode/http/wap/email..

Dat klinkt wel leuk.