[Alg] UBB-code in de database opslaan en/of XHTML? - Softwareontwikkeling

donderdag 23 maart 2006 10:35

Acties:

/* No Comment */

Topicstarter

Ik ben momenteel bezig met het ontwikkelen van een nieuw community-systeem. Het is een soort CMS, maar dan met de nadruk op Heel veel user-interactie (beetje richting een forum) en behoorlijk hoge bezoekersaantallen.

In de vorige versie van het systeem had ik een zogenaamde Text-tabel. Als ik ergens een textveld nodig had dan maakte ik een nieuw record in de text-tabel, en sloeg ik het ID op bij het item. In de text-tabel sloeg ik 2 text-velden op: een met de UBB-code, en een met de geconverteerde XHTML-code.

Dit had als voordeel dat de database-structuur vrij schoon en overzichtelijk bleef, maar het grote nadeel was dat ik eindeloos aan het left-joinen ben als ik texten bij items wil hebben. Daarnaast is bij een van de sites de text-tabel de 2Gb al voorbij, en heb ik de max-table-sizes van mysql moeten opkrikken.

Voor de nieuwe versie is het dus zaak om dingen zo efficient mogelijk aan te pakken, en ook de bovenstaande structuur nog eens goed te overdenken. Ik ben al op zoek geweest naar hoe andere enterprise-systemen dergelijke dingen aanpakken, maar dit is tot nog toe vrij vruchtenloos geweest.

Andere oplossingen zouden zijn:

Alleen de UBB bij het item opslaan
+ Supersimpele structuur
+ Wijzigen van de text is relatief makkelijk
-- Bij iedere pageview (of generatie van cache) moeten alle UBB-texten naar XHTML worden omgezet.

Alleen de XHTML bij het item opslaan
+ Supersimpele structuur
+ Bij weergave geen actie
- Bij iedere wijziging van de text moet de XHTML terug-geconverteerd worden naar UBB zodat de user aanpassingen in zijn UBB-code kan doen. Dit lijkt me erg foutgevoelig

Zowel UBB als XHTML bij het item opslaan
+ Geen belasting bij het weergeven, bij een select selecteer je gewoon het UBB-veld niet
+ Geen problemen bij editten, je selecteerd dan gewoon de UBB, en converteert deze bij het opslaan naar XHTML
- Ieder item krijgt 2 textvelden, tabellen worden hierdoor (onnodig?) groter

Houden zoals het was
+ relatief makkelijk weergeven
+ makkelijk wijzigen
- Veel te veel left joins

Wat lijkt jullie de beste oplossing? Nog andere ideeen?
Graag jullie reactie/commentaar

donderdag 23 maart 2006 10:59

Acties:

Michali

Ik zou puur de UBB opslaan, en als je echt met performance problemen kampt gewoon aan de cache gaan. Dat is in feite precies hetzelfde als ook de HTML opslaan, maar dan nog iets efficienter. Ik zou iig niet puur de HTML opslaan, zonder de UBB te behouden. Na terug converteren is het nooit hetzelfde als wat de user had opgeslagen, je moet hem altijd zijn eigen versie geven.

Noushka's Magnificent Dream | Unity

donderdag 23 maart 2006 11:24

Acties:

crisp

Devver

Pixelated

Beide opslaan, maar in aparte tabellen

Intentionally left blank

donderdag 23 maart 2006 11:32

Acties:

Martijn02

/* No Comment */

Topicstarter

crisp schreef op donderdag 23 maart 2006 @ 11:24:
Beide opslaan, maar in aparte tabellen

Dus ook je xhtml in een losse tabel? Dan blijft je alsnog left-joinen.

Wat natuurlijk ook een optie zou zijn de UBB in een aparte tabel te zetten (die heb je niet vaak nodig) en de XHTML bij de items en comments opslaan.

donderdag 23 maart 2006 11:44

Acties:

crisp

Devver

Pixelated

Martijn02 schreef op donderdag 23 maart 2006 @ 11:32:
[...]

Dus ook je xhtml in een losse tabel? Dan blijft je alsnog left-joinen.

Topics slaan we hier ook apart op van reacties. En waarom left joinen? Ik zou gewoon 2 queries uitvoeren: 1 om je 'topic' op te halen en 1 om de bijbehorende reacties op te halen.

offtopic:
en waarom xhtml en geen html? is je CMS xml-based?

Intentionally left blank

donderdag 23 maart 2006 11:53

Acties:

orf

Ik ben voor html gegaan.
Smilies: Twee arrays, één voor textuele weergaves van een smileys en één voor afbeeldingen. Bij encoden gebruik je ze in een str_replace. Bij decoden hetzelfde, maar in andere volgorde.

Code highlighting: Je hoeft alleen maar strip_tags te gebruiken voor het decoden.

Bold, underlined e.d. Je regex kan gewoon twee kanten op werken.

Url's Url's worden automatisch naar links omgezet, of je er nu wel of niet ubb codes omheen zet. Bij het terugparsen zet je er zelf gewoon ubb tags omheen. (dat zie je overigens ook gebeuren bij vBulletin en Invasion).

PHP:

<?php

$urlRegex   = '((?:http|ftp|https)://[a-z0-9\-\.%&;\+/\_\=\?\#]+)';

// decoden (kan nogal wat netter)
$message = preg_replace("#<a href=\"$urlRegex\" target=\"_blank\">([^]]+)</a>#Usi", "[url=$1]$2[/url]", $message);

?>

Jij bent degene die bepaalt hoe de HTML eruit komt te zien en dus weet je ook wat voor html tags je moet kunnen parsen. Om quotes zet ik een div heen: <div class="quote"></div>. Terug parsen naar [quote ][ /quote] is dan helemaal geen probleem.

Voor het highlighten van verschillende scripttalen gebruik ik een preg_replace_callback. Die roept een functie aan en vervangt de code voor (unieke) placeholders. Vervolgens worden de smileys en ubb code geparsed; daarna worden de placeholders vervangen voor de ge-highlighte codes. Op die manier heb je geen last van ongewenste smileys tussen de code.

Voor een druk bezocht forum heb ik gekeken hoeveel edits er gedaan worden ten opzichte van het aantal pageviews. Alleen voor de edits hoef je vervolgens de decode functie uit te voeren. Dat scheelt voor élke pageview de encode functie, die ook nog eens even zwaar is als de decode.

donderdag 23 maart 2006 12:04

Acties:

Martijn02

/* No Comment */

Topicstarter

crisp schreef op donderdag 23 maart 2006 @ 11:44:
[...]

Topics slaan we hier ook apart op van reacties. En waarom left joinen? Ik zou gewoon 2 queries uitvoeren: 1 om je 'topic' op te halen en 1 om de bijbehorende reacties op te halen.

offtopic:
en waarom xhtml en geen html? is je CMS xml-based?

Het gaat niet om het opslaan van Topics en reacties. Het gaat om de vorm van de text (uit die topics en reacties) Sla je de XHTML op? of de UBB-code? of een mix van beide?

en waarom XHTML? Euh ik gebruik al een tijdje geen HTML meer, alles wat ik produceer is XHTML, en daarom noem ik het ook zo. Is ook wel eens handig om een blobje code in een xml te versturen als gevolg van een ajax request oid.

donderdag 23 maart 2006 12:07

Acties:

joepP

Allebei opslaan, zonder twijfel. Zeker voor een groot forum.

Argumenten:
- Onderhoudbaar: Als je je parsing wilt aanpassen kan je dat envoudig doen en de XHTML tabel opnieuw vullen.
- Performance: Je hoeft niet steeds UBB -> XHTML te parsen voor -elke- keer dat de post bekeken wordt.
- Eenvoud: Je wilt geen parser schrijven die XHTML -> UBB omzet. Dit kost extra tijd en is foutgevoelig.

De ruimte voor de extra opslag is niet zo relevant voor een groot forum, performance en onderhoudbaarhuis wel.

donderdag 23 maart 2006 18:40

Acties:

Martijn02

/* No Comment */

Topicstarter

Ik voel er ook het meest voor om toch zowel de UBB als de XHTML op te slaan. Alleen de vraag is nu nog. Hoe sla ik het op?

- UBB+XHTML samen in een aparte "text"-tabel.
- UBB+XHTML samen bij de items.

Of een "best of both worlds" aanpak met

- XHTML bij items en UBB in een aparte tabel.

Ik neig nu het meest naar de laatste optie. Voor weergave heb je de XHTML direct bij de hand, en voor het aanpassen kan je de oorspronkelijke UBB uit de UBB-text tabel erbij pakken.

donderdag 23 maart 2006 21:44

Acties:

Civil

Martijn02 schreef op donderdag 23 maart 2006 @ 18:40:
Ik voel er ook het meest voor om toch zowel de UBB als de XHTML op te slaan. Alleen de vraag is nu nog. Hoe sla ik het op?

- UBB+XHTML samen in een aparte "text"-tabel.

Dit wordt dus veel te veel in één tabel zoals je zelf al aangaf.

- UBB+XHTML samen bij de items.

Dit is een optie waarbij de grote van je tabel ongeveer 2x zo snel groeit qua data (2 versies van 1 bericht).

Of een "best of both worlds" aanpak met

- XHTML bij items en UBB in een aparte tabel.

Ik neig nu het meest naar de laatste optie. Voor weergave heb je de XHTML direct bij de hand, en voor het aanpassen kan je de oorspronkelijke UBB uit de UBB-text tabel erbij pakken.

Hier zou ik zelf ook voor kiezen zoals ook crisp al aangaf. De UBB uiteraard apart want die haal je in principe nooit op tenzij iemand zijn bericht wil wijzigen, daarmee voorkom je dus joins naar deze tabel bij het normaal ophalen van data.

[ Voor 5% gewijzigd door Civil op 23-03-2006 21:45 ]