[PHP] str_ireplace de DB in of uit?

[WingsOfFury]

Ik gebruik op een van mijn sites Tiny_MCE Editor, en daarbij zitten smilies die je kunt oproepen via een knop, maar dit duurt nogal lang. Daarom heb ik sneltoetsen ingevoerd, alleen vraag ik mij af of ik die de database in of uit moet vervangen?

Ik heb het nu de DB in, dus:

PHP:

$tekst = $_POST['tekst'];
$sneltoetsen = array(":b", ":'(", ":*", ":+", ":(", ":^", ":x", ":d", ":$", ":#", ":)", ":o", ":p", ":/", ";)", ":@");
$codes = array("<img title=\"Cool\" src=\"tiny_mce/plugins/emotions/img/smiley-cool.gif\" border=\"0\" alt=\"Cool\" />",
"<img title=\"Cry\" src=\"tiny_mce/plugins/emotions/img/smiley-cry.gif\" border=\"0\" alt=\"Cry\" />",
"<img title=\"Embarassed\" src=\"tiny_mce/plugins/emotions/img/smiley-embarassed.gif\" border=\"0\" alt=\"Embarassed\" />",
"<img title=\"Foot in mouth\" src=\"tiny_mce/plugins/emotions/img/smiley-foot-in-mouth.gif\" border=\"0\" alt=\"Foot in mouth\" />",
"<img title=\"Frown\" src=\"tiny_mce/plugins/emotions/img/smiley-frown.gif\" border=\"0\" alt=\"Frown\" />",
"<img title=\"Innocent\" src=\"tiny_mce/plugins/emotions/img/smiley-innocent.gif\" border=\"0\" alt=\"Innocent\" />",
"<img title=\"Kiss\" src=\"tiny_mce/plugins/emotions/img/smiley-kiss.gif\" border=\"0\" alt=\"Kiss\" />",
"<img title=\"Laughing\" src=\"tiny_mce/plugins/emotions/img/smiley-laughing.gif\" border=\"0\" alt=\"Laughing\" />",
"<img title=\"Money mouth\" src=\"tiny_mce/plugins/emotions/img/smiley-money-mouth.gif\" border=\"0\" alt=\"Money mouth\" />",
"<img title=\"Sealed\" src=\"tiny_mce/plugins/emotions/img/smiley-sealed.gif\" border=\"0\" alt=\"Sealed\" />",
"<img title=\"Smile\" src=\"tiny_mce/plugins/emotions/img/smiley-smile.gif\" border=\"0\" alt=\"Smile\" />",
"<img title=\"Surprised\" src=\"tiny_mce/plugins/emotions/img/smiley-surprised.gif\" border=\"0\" alt=\"Surprised\" />",
"<img title=\"Tongue out\" src=\"tiny_mce/plugins/emotions/img/smiley-tongue-out.gif\" border=\"0\" alt=\"Tongue out\" />",
"<img title=\"Undecided\" src=\"tiny_mce/plugins/emotions/img/smiley-undecided.gif\" border=\"0\" alt=\"Undecided\" />",
"<img title=\"Wink\" src=\"tiny_mce/plugins/emotions/img/smiley-wink.gif\" border=\"0\" alt=\"Wink\" />",
"<img title=\"Yell\" src=\"tiny_mce/plugins/emotions/img/smiley-yell.gif\" border=\"0\" alt=\"Yell\" />");
$tekst = str_ireplace($sneltoetsen, $codes, $tekst);
$tekst = addslashes($tekst);
$query ="INSERT INTO tbl (tekst, auteur) VALUES ('$tekst','".$naam."')";
        mysql_query($query);

Maar misschien is het sneller/beter om ze gewoon als ":)" de DB in te stoppen, en pas bij het eruit halen (lezen) te vervangen? Of maakt dit helemaal niks uit?

[RobIII]

WingsOfFury schreef op dinsdag 27 juli 2010 @ 13:04:
Maar misschien is het sneller/beter om ze gewoon als ":)" de DB in te stoppen, en pas bij het eruit halen (lezen) te vervangen? Of maakt dit helemaal niks uit?

Je slaat een tekst doorgaans maar 1 keer op (en misschien nog een paar edits) en geeft 'm misschien wel 100.000 keer weer; waarbij je dan telkens die smiley codes gaat zitten replacen. You do the math.

Wat ik altijd meestal doe is een "raw" versie opslaan (dus gewoon de tekst zoals 'ie ingevoerd is) en een 'processed' versie ervan (dus waar smileys in zijn vervangen en andere (zeg, UBB ofzo) codes zijn toegepast). Bij een edit gebruik je dan gewoon de 'raw' versie en bij een view gebruik je de 'processed' versie.

Overigens:

quote: http://php.net/manual/en/function.addslashes.php

It's highly recommeneded to use DBMS specific escape function (e.g. mysqli_real_escape_string() for MySQL or pg_escape_string() for PostgreSQL)

En nog beter gebruik je Parametrized Queries.

[ Voor 47% gewijzigd door RobIII op 27-07-2010 13:25 ]

[Janoz]

Tja, of het beter is hangt af van de requirements. Het is natuurlijk sneller wanneer de transformatie maar 1x gebeurt (bij het opslaan) ipv meerdere keren (bij het weergeven). Aan de andere kant worden de opgeslagen berichten wel weer groter en zou je tegen problemen aan kunnen lopen wanneer je je berichten ook weer wilt wijzigen.

Ik zie echter totaal niet de relevantie tussen de eerste zin en je uiteindelijke vraag.

[djluc]

Het opslaan van de originele versie is sowieso aan te raden. Voor snelheid een processed versie is optimalisatie en kan je toevoegen. Het is aan te raden om dan een check in te bouwen zodat je zeker weet dat de processed versie geüpdate wordt zodat je niet 2 versies krijgt die niet overeenkomen.

[Verwijderd]

Ik zou replacements pas bij het eruithalen van de database doen, dus bij de output ipv input

[Skinkie]

Materialized view?

[RobIII]

Skinkie schreef op dinsdag 27 juli 2010 @ 13:31:
Materialized view?

Care to explain? Ik zie even niet wat dat te maken heeft met dit probleem? Ik krijg een beetje een klok/klepel gevoel...

Verwijderd schreef op dinsdag 27 juli 2010 @ 13:30:
Ik zou replacements pas bij het eruithalen van de database doen, dus bij de output ipv input

Wil je ook even onderbouwen waarom? Zonder onderbouwing is je reply niet veel waard namelijk Dan hebben we straks 15 "ik zou bij input doen" en 14 "ik zou bij output doen" reacties en zijn we geen steek verder. We zijn een discussieforum, geen Idols waar de meeste stemmen winnen

Normaliter doe je dat inderdaad; alleen bij "dure" acties (zoals -tig string replacements uitvoeren voor smileys + "UBB code toepassen" + links automatisch van anchors voorzien + ...) kan het gunstiger zijn om dit eenmalig (bij opslaan) te doen ipv bij elke view (dan doe je voor elke view, dus potentieel vele duizenden keren of meer, namelijk onnodig exact hetzelfde). Nu gebruikt TS TinyMCE en zal dus het gros wel al ondervangen zijn en zal 't wel beperkt zijn tot de smileys, maar aangezien TS aangeeft dat 't "lang" duurt is het dus handig die load maar eenmalig te hoeven veroorzaken en dan een klein beetje extra ruimte daarvoor op te offeren in de DB.

djluc schreef op dinsdag 27 juli 2010 @ 13:28:
Het is aan te raden om dan een check in te bouwen zodat je zeker weet dat de processed versie geüpdate wordt zodat je niet 2 versies krijgt die niet overeenkomen.

Uiteraard; de .Save() (om het zo even te zeggen) zal ten alle tijden beide velden bij moeten werken maar bij een goed geabstraheerd model moet dat een koud kunstje zijn. Enige waar je nog rekening mee moet houden is als je op een bepaald moment nieuwe codes toevoegt bijvoorbeeld dat het kan zijn (afhankelijk of je dat wil of niet) dat je alle bestaande records nog eens moet nafietsen om opnieuw te processen. Maar dat kun je dan met een apart procesje lekker rustig en zonder al te veel load/overlast te veroorzaken uitvoeren zonder dat er iemand last van heeft.

[ Voor 108% gewijzigd door RobIII op 27-07-2010 14:03 ]

[wackmaniac]

TinyMCE levert toch ook gewoon HTML op? Dan zou het in dit geval het meest consistent zijn om de replace voor het opslaan te doen. Neemt niet weg dat de oplossing van RobIII in mijn ogen de beste is.

[RobIII]

wackmaniac schreef op dinsdag 27 juli 2010 @ 14:08:
TinyMCE levert toch ook gewoon HTML op? Dan zou het in dit geval het meest consistent zijn om de replace voor het opslaan te doen. Neemt niet weg dat de oplossing van RobIII in mijn ogen de beste is.

TinyMCE doet, bij mijn weten althans, ook "UBB". Wanneer je HTML zou doen is heel die replace natuurlijk overbodig en kun je net zo goed meteen die image tags erin knallen. Daarom zei "mijn water" dat er iets meer aan de hand is wat TS ons niet vertelt en dus ga ik even uit van UBB

Correctie: Ik bedoel met UBB natuurlijk BBCode.

[ Voor 12% gewijzigd door RobIII op 27-07-2010 14:16 ]

[4Real]

RobIII schreef op dinsdag 27 juli 2010 @ 13:07:
[...]

Je slaat een tekst doorgaans maar 1 keer op (en misschien nog een paar edits) en geeft 'm misschien wel 100.000 keer weer; waarbij je dan telkens die smiley codes gaat zitten replacen. You do the math.

Wat ik altijd meestal doe is een "raw" versie opslaan (dus gewoon de tekst zoals 'ie ingevoerd is) en een 'processed' versie ervan (dus waar smileys in zijn vervangen en andere (zeg, UBB ofzo) codes zijn toegepast). Bij een edit gebruik je dan gewoon de 'raw' versie en bij een view gebruik je de 'processed' versie.

Hier ga ik helemaal in mee, weergeven moet zo snel mogelijk dus daar gebruik je de 'processed' versie.

[Gomez12]

RobIII schreef op dinsdag 27 juli 2010 @ 13:36:
[...]
Uiteraard; de .Save() (om het zo even te zeggen) zal ten alle tijden beide velden bij moeten werken maar bij een goed geabstraheerd model moet dat een koud kunstje zijn. Enige waar je nog rekening mee moet houden is als je op een bepaald moment nieuwe codes toevoegt bijvoorbeeld dat het kan zijn (afhankelijk of je dat wil of niet) dat je alle bestaande records nog eens moet nafietsen om opnieuw te processen. Maar dat kun je dan met een apart procesje lekker rustig en zonder al te veel load/overlast te veroorzaken uitvoeren zonder dat er iemand last van heeft.

Persoonlijk gaat mijn voorkeur altijd uit naar de .retrieve() aan te passen ipv de save, zodat je meer een cachings functie krijgt.
Gewoon in je retrieve kijken of je een geparste versie hebt, zoniet dan origineel parsen en opslaan.

Nadeel van .save aanpassen vind ik altijd dat het erg lastig is om nieuwe functionaliteit in te bouwen ( alles moet opnieuw geparsed worden = zwaar proces ) terwijl je met een .retrieve enkel de gecachete weg hoeft te gooien en alles wordt vanzelf weer aangevuld.
Als je na een .save() de gebruiker gelijk weer de invoer toont dan heb je zo goed als dezelfde functionaliteit als dat je het in .save() inbouwt enkel minder complex en flexibeler imho.

Waar je trouwens wel op moet letten met een een geparste tabel is dat deze veel groter kan zijn dan je originele tabel. 1 smilie in origineel is 2 tekens, na parsing kan het rustig 30 tekens zijn ( zou niet de eerste keer zijn dat ik posts op een forum afgekapt zie worden die bij editten wel weer volledig ter beschikking zijn )

[RobIII]

Gomez12 schreef op dinsdag 27 juli 2010 @ 14:42:
[...]

Persoonlijk gaat mijn voorkeur altijd uit naar de .retrieve() aan te passen ipv de save, zodat je meer een cachings functie krijgt.
Gewoon in je retrieve kijken of je een geparste versie hebt, zoniet dan origineel parsen en opslaan.

Ook goed Either way moet dit gewoon ergens weg-geabstraheerd worden zodat je daar verder geen omkijken naar hebt.

[Noxious]

Eens met de 'raw' en 'processed' versie. Dit is ook je redding als je nog eens je smilies veranderd naar een andere theme oid (wat ik heb meegemaakt waar dus alles voor het plaatsen in de database was aangepast).

[Olaf van der Spek]

RobIII schreef op dinsdag 27 juli 2010 @ 13:07:
En nog beter gebruik je Parametrized Queries.

Dit stuk is niet van toepassing op de combinatie PHP/MySQL.

[FragFrog]

RobIII schreef op dinsdag 27 juli 2010 @ 14:15:
TinyMCE doet, bij mijn weten althans, ook "UBB". Wanneer je HTML zou doen is heel die replace natuurlijk overbodig en kun je net zo goed meteen die image tags erin knallen.

Bij mijn weten niet, althans, niet zodra je de content opstuurt. Alles wat uit TinyMCE komt is pure HTML en kun je daardoor ook makkelijk zo op een andere pagina plempen (vandaar ook dat je de interne stylesheets van je website kan koppelen aan TinyMCE, zodat de WYSIWYG ook daadwerkelijk is WYG zodra je de html van TinyMCE op een pagina weergeeft). Do correct me if I'm wrong here

Hoewel ik normaliter ook geen fan ben van content parsen voor je het opslaat (wat nu als je de tekst niet als HTML wilt weergeven?) maar in dit geval is dat eigenlijk niet aan de orde. Ik zou het dan ook lekker vooraf doen

Noxious schreef op dinsdag 27 juli 2010 @ 14:56:
Eens met de 'raw' en 'processed' versie. Dit is ook je redding als je nog eens je smilies veranderd naar een andere theme oid (wat ik heb meegemaakt waar dus alles voor het plaatsen in de database was aangepast).

Niet per se een probleem. Ofwel je veranderd de afbeeldingen in je template folder zelf, ofwel je gebruikt een andere stylesheet of template en slaat niet de source maar de class van de smiley op. Daarnaast is het nog maar de vraag of je ook oude content mee wilt aanpassen - er zijn situaties waarin "nieuwe" smileys niet 1 : 1 te vertalen zijn naar de oude qua grootte & toepasbaarheid, in een dergelijk geval is het juist handig als je een specifieke smiley-afbeelding aangeeft in plaats van een generiek type. Nochtans uiteraard wel een punt om over na te denken.

Olaf van der Spek schreef op dinsdag 27 juli 2010 @ 16:01:

Ook PHP / MySQL kan in principe met parametrized queries overweg, zie pdo _{Al moet ik toegeven zelf doorgaans ook de mysqli library te pakken, al was het alleen maar omdat die een stuk vaker beschikbaar is}

[ Voor 43% gewijzigd door FragFrog op 27-07-2010 16:59 ]

[RobIII]

Olaf van der Spek schreef op dinsdag 27 juli 2010 @ 16:01:
Dit stuk is niet van toepassing op de combinatie PHP/MySQL.

Dat is tegenwoordig wél mogelijk met (zoals gezegd hierboven) PDO (geen ervaring mee) en MySQLi; die FAQ moet nodig eens bijgewerkt worden.

[ Voor 3% gewijzigd door RobIII op 27-07-2010 17:28 ]

[Skinkie]

RobIII schreef op dinsdag 27 juli 2010 @ 13:36:
[...]

Care to explain? Ik zie even niet wat dat te maken heeft met dit probleem? Ik krijg een beetje een klok/klepel gevoel...

Je maakt een view waar je alle hier boven beschreven operaties uitvoert. Dan bewaar je dus de ruwe data en heb je toch direct je meuk in de juiste vorm.

[Gomez12]

Skinkie schreef op dinsdag 27 juli 2010 @ 18:45:
[...]

Je maakt een view waar je alle hier boven beschreven operaties uitvoert. Dan bewaar je dus de ruwe data en heb je toch direct je meuk in de juiste vorm.

Dat kan als je het enkel over simpele operaties hebt. Wil je iets verder gaan dan gaat SQL je echt opbreken...

Voor puur dit probleem kan het, maar toekomstvoorbereid / uitbreidbaar is het niet echt

[Skinkie]

Gomez12 schreef op dinsdag 27 juli 2010 @ 19:02:
[...]

Dat kan als je het enkel over simpele operaties hebt. Wil je iets verder gaan dan gaat SQL je echt opbreken...

Voor puur dit probleem kan het, maar toekomstvoorbereid / uitbreidbaar is het niet echt

Sinds wanneer is een materialized query alleen voor simpele operaties? Dat gaat SQL totaal niet opbreken.

[Verwijderd]

Waarom eigenlijk de keuze voor str_ireplace?

Als je je al zorgen maakt om performance zaken en best practice, waarom dan niet ook daar wat aandacht aan besteden?

[FragFrog]

Verwijderd schreef op dinsdag 27 juli 2010 @ 19:15:
Waarom eigenlijk de keuze voor str_ireplace?

Als je je al zorgen maakt om performance zaken en best practice, waarom dan niet ook daar wat aandacht aan besteden?

Welk alternatief zou jij aanraden? Voor zover ik weet zijn de 'native' PHP string search / replace functies een stuk sneller dan de regular expression based varianten

[RobIII]

Skinkie schreef op dinsdag 27 juli 2010 @ 19:11:
[...]

Sinds wanneer is een materialized query alleen voor simpele operaties? Dat gaat SQL totaal niet opbreken.

Het gaat er om dat je die logica (IMHO) helemaal niet in de DB wil stoppen. Een (materialized) view is wel het laatste waar ik op zou komen in dit geval.

Verwijderd schreef op dinsdag 27 juli 2010 @ 19:15:
Waarom eigenlijk de keuze voor str_ireplace?

Als je je al zorgen maakt om performance zaken en best practice, waarom dan niet ook daar wat aandacht aan besteden?

Ik neem aan voor gevallen als :p en :P Ik had dat ook al even willen aankaarten. In dat geval kun je misschien beter een extra key/value pair maken (1 voor :p en 1 voor :P). Maar dan loop je, denk ik, wel heel erg in de marge te rommelen.

[ Voor 40% gewijzigd door RobIII op 27-07-2010 19:53 ]

[Skinkie]

RobIII schreef op dinsdag 27 juli 2010 @ 19:51:
Het gaat er om dat je die logica (IMHO) helemaal niet in de DB wil stoppen. Een (materialized) view is wel het laatste waar ik op zou komen in dit geval.

cpu power vs storage. Dus store and serve.

[Verwijderd]

FragFrog schreef op dinsdag 27 juli 2010 @ 19:30:
[...]

Welk alternatief zou jij aanraden? Voor zover ik weet zijn de 'native' PHP string search / replace functies een stuk sneller dan de regular expression based varianten

Dat minimale verlies in snelheid wordt geheel goedgemaakt door de flexibiliteit die reguliere expressies je bieden, vooral als je die efficiënt opzet.

[Verwijderd]

RobIII schreef op dinsdag 27 juli 2010 @ 19:51:
[...]
Ik neem aan voor gevallen als :p en :P Ik had dat ook al even willen aankaarten. In dat geval kun je misschien beter een extra key/value pair maken (1 voor :p en 1 voor :P). Maar dan loop je, denk ik, wel heel erg in de marge te rommelen.

Inderdaad, waar ik meer op doelde was de mindset van de TS. Aan de ene kant zorgen maken om performance, maar aan de andere kant zonder erover na te denken str_ireplace gebruiken ipv str_replace met 2 extra entries in de array.

Ik weet niet wat voor een site het is, maar ik zou hier niet eens aan denken. Zorg liever voor een stabiel en goed te onderhouden systeem dan iets wat 100% gericht is op performance. Uit ervaring weet ik dat je zelfs een redelijk grote site incl volledig template parsing systeem met realtime parsing op ongeveer alles en minimale caching op een simpel thuisservertje nog zonder moeite kunt draaien. Redelijk groot moet je denken aan een orde van grootte tot 500.000 pageviews per dag.

Ga je richting 1 a 2 miljoen dan kun je in de hardware vrij eenvoudig al de snelheidswinst halen die nodig is. Met dergelijk aantal pageviews kun je uit de ad opbrengsten ook wel een geschikt servertje huren normaal gezien.

Ga je richting 5 miljoen pageviews per dag dan zou ik eens serieus gaan nadenken hoe zoiets aan te pakken (oftewel verwacht je binnen 1 tot 2 jaar aan de 5 miljoen pageviews te zitten dan moet je hier nu mee bezig zijn). Maar dan zou ik eerder kijken naar een integraal caching systeem op m'n frontend dan een enkel aspect van de performance.

(Let niet op de getallen exact, het gaat meer om een orde van grootte)

[WingsOfFury]

Bedankt voor alle reacties! Ik zie dat er nog wat onduidelijkheden zijn, maar ook dat het nogal uit de hand is gelopen Er zijn veel dingen gezegd die mij niks zeggen namelijk

De vraag was meer bedoelt voor in het algemeen, niet specifiek voor deze site. Toch zal ik de reden eens beter uitleggen:
In een tekstveld van TinyMCE heb je de standaard knoppen bovenaan (dik/schuin/plaatje/link) en 1 knop daarvan is om smiley's in te voeren. Als je op die knop klikt komt er een pop-up die, via JavaScript, alle smiley's (16 in dit geval) laat zien, en je kunt ze dan invoeren door erop te klikken. Het openen en laden van die pop-up duurt 3-5 seconden, en per smiley moet je weer opnieuw beginnen. Dus wil je 5 x dan ben je 15-25 seconden kwijt. Daarom wilde ik het ook met sneltoetsen mogelijk maken, zodat je die laadtijd kwijt bent én zodat je gewoon kunt doortypen ipv iedere keer de muis moet pakken.

Str_ireplace is inderdaad vanwege de hoofdlettergevoeligheid. Maar als ik het goed begrijp is str_replace met 2x zo grote array's (kleine en grote letter) dus sneller?

De meesten zullen het de DB 'in' doen, zodat het maar 1 keer hoeft. Dat daarmee de DB groter en voller wordt maakt dus niks uit begrijp ik. Alleen dat van die raw versie snap ik niet, of ik begrijp het niet... Raw en processed, wil dat zeggen dat alles dus 2 keer in je DB komt? Dan zou een site met 10.000 berichten er dus 20.000 in zijn DB hebben zitten? Ik begrijp de logica daar niet van

[Voutloos]

Je eerste probleem is dus die laadtijd van dat scherm, dus pak dat eerst aan. Kijk bijv. Met firebug of benodigde javascript en plaatjes gecached worden etc...

[Skinkie]

Als je op de edit klopt drukt wil je niet terug parsen

[orf]

Tiny heeft een mooie onNodeChange listener. Daar kun je hardstikke mooi dit soort dingen aanhangen. Met JavaScript vervang je dan direct de smiley-codes voor de afbeeldingen. Dan heb je dezelfde functionaliteit als de popup, maar dan terwijl je typt.

[Gomez12]

WingsOfFury schreef op dinsdag 27 juli 2010 @ 22:12:
Str_ireplace is inderdaad vanwege de hoofdlettergevoeligheid. Maar als ik het goed begrijp is str_replace met 2x zo grote array's (kleine en grote letter) dus sneller?

Als ik het zo zie dan gok ik dat sneller voor jou niets uitmaakt. Het gaat in dit soort gevallen bijna nooit om voelbaar sneller,enkel meetbaar sneller.
Als een JS-popupje 3 seconden duurt dan maakt die 1 duizendste van een seconde (oid) die str_replace sneller is dan istr_replace niets uit...

Raw en processed, wil dat zeggen dat alles dus 2 keer in je DB komt? Dan zou een site met 10.000 berichten er dus 20.000 in zijn DB hebben zitten? Ik begrijp de logica daar niet van

Simplistisch gezegd :
- Je hebt een raw versie zoals hij ingevoerd is, deze gebruik je enkel om te editten etc ( en voor als in de toekomst er iets bijkomt waardoor je processed niet meer voldoet ( vb. andere image locatie ) )
- Je hebt een processed versie, hier doet php/mysql zo goed als niets meer aan. Dit is rechtstreeks in een html-pagina te schieten.

Je raw versie bevat dus : [insert smiley here]
Je processed versie bevat dan dus : <img src="smiley2.gif">

En je slaat dan idd 2x je berichten op. Maar is dat erg? Zolang je db de juiste tabel pakt maakt het geen barst uit

De logica is dus dat je 1 versie hebt die het "origineel" is, hierop kunnen nog allerlei bewerkingen nodig zijn voordat je het toont ( vb. smiley codes vervangen ), deze bewerkingen kosten allemaal tijd en als je 500.000 pageviews per dag hebt gebeuren al die bewerkingen x keer per pagina. Daarom sla je dus ook een "bewerkte" op.
Als je enkel een bewerkte opslaat dan kan je nooit meer iets veranderen / toevoegen, daarom dus ook het origineel.

[Ventieldopje]

Wat ik zou doen is een aparte tabel aan maken met alle smileys (id, sneltoets, plaatje) en een aparte tabel met de berichten (zonder <img> etc., gewoon met etc. in tekst vorm, dus de raw) ... en elke keer als je het bericht weer geeft dan ga je de smileys parsen:

smileys laden uit de db -> array -> str_ireplace

Dit omdat je de flexibiliteit hebt om later nog nieuwe smileys toe te voegen of de plaatjes te veranderen, je zal maar de directory structuur van je server aanpassen en alle berichten met <img src="blab" ... moeten vervangen met je nieuwe URL .. dit hoeft dan niet meer.

Qua snelheid zal je er weinig van merken plus het geeft je flexibiliteit.

Edit: shit te laat

[Cartman!]

Het enige wat je dan doet is een query draaien om je parsed versies weg te halen en dan zal je logica die zelf weer opslaan in z'n row als cache, simpel.

Qua snelheid merk je er natuurlijk wat van, je hoeft geen queries te doen voor je smileys, geen arrays ervan te maken, het replacen doe je niet meer.

[Verwijderd]

Zoek eerst eens uit waarom in dat popupje zoveel sec weg gaan? Das toch niet echt gezond of wel?

[Gomez12]

Phas0r schreef op dinsdag 27 juli 2010 @ 22:35:
Wat ik zou doen is een aparte tabel aan maken met alle smileys (id, sneltoets, plaatje) en een aparte tabel met de berichten (zonder <img> etc., gewoon met etc. in tekst vorm, dus de raw) ... en elke keer als je het bericht weer geeft dan ga je de smileys parsen:

Waarom die smileys in een aparte tabel? Ik zou het gewoon in je code zetten in een aparte parse class oid.

Waar hebben we het over? 20 smileys ofzo?
Als je een aparte tabel pakt wat wil je dan later gaan doen met andere parsings regels etc ( youtube links bv )

Elke page view een extra query gaan doen om 20 values op te halen om later te kunnen parsen lijkt me ietwat overkill

[st0p]

Waarom krijg ik bij dit hele topic een enorm groot micro optimalisatie gevoel? str_ireplace gewoon als data de DB uit gaat. In de DB zelf wil ik data altijd zo rauw mogelijk opslaan, ivm met eventuele andere output formaten zoals PDF. Indien je 100% zeker weet dat je altijd HTML nodig hebt doe je het ervoor (en dan nog ben ik situaties tegengekomen waarin ik daar later spijt van had, omdat later toch bleek dat de data nodig was in een ander formaat.)

Het meerendeel van alle site's gaat geen aantallen bezoekers verwerken zoals facebook of youtube. Als ik dan moet kiezen tussen een simpeler datamodel wat enkele milliseconden langer duurt per request, of een complexer datamodel met een marginaal performance voordeel, dan kies ik voor het eerste. De kans dat de echte performance bottlenecks elders liggen is toch 99%.

[RobIII]

st0p schreef op woensdag 28 juli 2010 @ 00:08:
Waarom krijg ik bij dit hele topic een enorm groot micro optimalisatie gevoel? str_ireplace gewoon als data de DB uit gaat. In de DB zelf wil ik data altijd zo rauw mogelijk opslaan, ivm met eventuele andere output formaten zoals PDF. Indien je 100% zeker weet dat je altijd HTML nodig hebt doe je het ervoor (en dan nog ben ik situaties tegengekomen waarin ik daar later spijt van had, omdat later toch bleek dat de data nodig was in een ander formaat.)

Daarom sla je het 'raw' (zoals het ingevoerd is) op en daarbij een 'processed' (zoals wanneer er allerlei code overheen gegaan is). Storage kost gewoon geen ruk. Of het zinnig is om deze "optimalisatie" uberhaupt toe te passen is andere koek; dat kan alleen de TS beantwoorden en beoordelen. Wij kennen de (exacte) situatie immers niet. Wel ben ik het eens dat de discussie omtrent str_replace vs. str_ireplace e.d. uiteindelijk een microoptimalisatie van de puurste soort is.

st0p schreef op woensdag 28 juli 2010 @ 00:08:
Als ik dan moet kiezen tussen een simpeler datamodel wat enkele milliseconden langer duurt per request

Enkele ms. kan aardig oplopen als je site begint te lopen, en:

st0p schreef op woensdag 28 juli 2010 @ 00:08:
of een complexer datamodel met een marginaal performance voordeel, dan kies ik voor het eerste.

Nou nou... complexer is een groot woord. Of je nou:

• message_id
• message_text

hebt of

• message_id
• message_text
• message_parsed

Als dat al complex is... Het is nagenoeg geen extra werk en nagenoeg niet "complexer" in onderhoud. Ik vind dit wel een optimalisatie die de moeite waard is (GoT doet het ook); maar dan heb ik het dus wél over processen waarbij het verwerken van de tekst daadwerkelijk wat "heftiger" is dan 16 replaces. Dan hou je de load graag bij "database in" omdat je er dan potentieel duizenden keren van profiteert en maar 1 keer de load veroorzaakt. Maar we blijken het nu dus opeens niet meer over load te hebben maar over een popup die traag opent.

st0p schreef op woensdag 28 juli 2010 @ 00:08:
De kans dat de echte performance bottlenecks elders liggen is toch 99%.

TS gaf (in de topicstart althans) aan dat "dit nogal lang duurt" en daar verstond ik het vervangen van de smileycodes door de daadwerkelijke smileys (en wat er dan nog meer om heen zou hangen....) onder. Als die 16~something replaces al "lang" duren is er iets anders aan de hand en moet TS sowieso eens gaan zoeken waar het probleem dan precies zit. Dat blijkt nu ook wel nu TS opeens komt met dat het openen van een pop-up lang duurt.
Performance bottlenecks moet je overigens gewoon meten en niet op de gok gaan zitten proberen oplossen.

[ Voor 48% gewijzigd door RobIII op 28-07-2010 00:20 ]

[Gomez12]

st0p schreef op woensdag 28 juli 2010 @ 00:08:
Indien je 100% zeker weet dat je altijd HTML nodig hebt doe je het ervoor (en dan nog ben ik situaties tegengekomen waarin ik daar later spijt van had, omdat later toch bleek dat de data nodig was in een ander formaat.)

Simpel gezegd, ik kan me geen enkel voorbeeld bedenken wat altijd HTML ( volgens de huidige regels ) moet uitspugen, altijd is er afaik wel een toekomstige mogelijkheid tot XML / RSS oid.

Als ik dan moet kiezen tussen een simpeler datamodel wat enkele milliseconden langer duurt per request, of een complexer datamodel met een marginaal performance voordeel, dan kies ik voor het eerste. De kans dat de echte performance bottlenecks elders liggen is toch 99%.

Het gaat hier dan ook niet om een complexer datamodel, enkel om een stukje caching in de dbase voor 1 specifiek veelgebruikt export formaat.

[st0p]

Tja, wat is dan nog het voordeel van een processed variant opslaan? Grote kans dat je later nog een variant nodig hebt met plaatjes, zonder smilies en nog even later een variant met smilies maar zonder plaatjes. Ga je dan processed_2 en processed_3 varianten opslaan? of processed_without_smilies en processed_without_images? Wordt de variant zonder smilies en images dan processed_without_smilies_and_images? En wat als ik alle blije smilies wil wergeven maar de negatieve niet? processed_with_happy_smilies_and_images?

Don't get me wrong: iedere fatsoenlijke database kan dit handelen en storage kost idd geen drol meer. Maar hoe ga ik de verschillen uitleggen aan een nieuwe developer in mijn team? Ik snap het voordeel wel van beide varianten opslaan, maar ik geloof dat RDBMS'en juist bedoeld waren om 1 canonieke variant van je data op te slaan. Met deze canonieke variant ben je uiteraard vrij om te doen en te laten wat je wil.

Nogmaals, als je moet schalen zoals facebook (en misschien ook tweakers, ik heb geen idee wat deze site voor requests/seconde krijgt te verstouwen) is het opslaan van verschillende varianten een prima oplossing. Maar meestal is het premature optimization en zul je later alsnog een andere variant nodig hebben die toch weer een kleine hoeveelheid data manipulatie moet doen op datgene wat in je DB staat. Sowieso vraag ik me af in hoeverre je op dat soort schalen niet moet gaan kijken naar NoSQL oplossingen.

[Avalaxy]

st0p schreef op woensdag 28 juli 2010 @ 00:30:

Don't get me wrong: iedere fatsoenlijke database kan dit handelen en storage kost idd geen drol meer. Maar hoe ga ik de verschillen uitleggen aan een nieuwe developer in mijn team? Ik snap het voordeel wel van beide varianten opslaan, maar ik geloof dat RDBMS'en juist bedoeld waren om 1 canonieke variant van je data op te slaan. Met deze canonieke variant ben je uiteraard vrij om te doen en te laten wat je wil.

Lijkt me dat een view perfect is voor dit doel? Je behoudt gewoon je originele date en update de view zodra de originele data wordt aangepast.

[Verwijderd]

Het is heel simpel:

Wat is de load van de verwerking? Vermenigvuldig dat met hoe vaak je het ding gemiddeld nodig hebt. Trek daar de eenmalige verwerking bij opslaan vanaf en zie daar je besparing.

Waar het nuttig is en waar niet is dus een kwestie van meten, meten is weten.

Daarna geef je dat rapport aan je manager, die kijkt naar je uren van die dag en besluit voor 10 euro een betere CPU in de server te stoppen die het verschil al ruim goedmaakt en goedkoper is dan jouw en zijn uren die dag gekost hebben

[RobIII]

st0p schreef op woensdag 28 juli 2010 @ 00:30:
Ik snap het voordeel wel van beide varianten opslaan, maar ik geloof dat RDBMS'en juist bedoeld waren om 1 canonieke variant van je data op te slaan. Met deze canonieke variant ben je uiteraard vrij om te doen en te laten wat je wil.

Ja en soms moet je jezelf niet in een hoekje normalizeren maar pragmatisch leren werken

st0p schreef op woensdag 28 juli 2010 @ 00:30:
Nogmaals, als je moet schalen zoals facebook (en misschien ook tweakers, ik heb geen idee wat deze site voor requests/seconde krijgt te verstouwen) is het opslaan van verschillende varianten een prima oplossing.

Ik weet niet wat voor site TS heeft noch wat hij te verstouwen heeft; daar gaat het dan ook niet om. Zijn vraag was: "alleen vraag ik mij af of ik die de database in of uit moet vervangen?". En ik denk dat je dan, met minimale effort, prima de "in" methode kunt gebruiken als het voor een specifiek doel is. Dat je ook nog output voor PDF's, backends, exports, web services of weet-ik-veels wil hebben heeft daar weinig mee van doen; daar heb je de "raw" versie nog voor. En als blijkt dat de webservice wegens "processing_functie_X" teveel load veroorzaakt (en je bent beperkt in hardware en andere mogelijkheden) dan kun je daar misschien ook wel weer wat caching voor bouwen. Maar again; deze discussie is zinloos als we niet meer weten over de context.

st0p schreef op woensdag 28 juli 2010 @ 00:30:
Sowieso vraag ik me af in hoeverre je op dat soort schalen niet moet gaan kijken naar NoSQL oplossingen.

Dat is ook een optie. Evenals het cachen op filesystem. Of het cachen op een aparte dedicated server. Of een memcache. Of...you-name-it. Maar dat was de vraag dus niet

[Gomez12]

st0p schreef op woensdag 28 juli 2010 @ 00:30:
Tja, wat is dan nog het voordeel van een processed variant opslaan? Grote kans dat je later nog een variant nodig hebt met plaatjes, zonder smilies en nog even later een variant met smilies maar zonder plaatjes. Ga je dan processed_2 en processed_3 varianten opslaan?

Als je er de page_views voor hebt, waarom niet?

We hebben het hier niet over de meest exotische varianten die 1x per maand gebruikt worden.
We hebben het hier over de variant die in 1e instantie 99% van het gebruik gaat betekenen.

Wordt er later een RSS variant bijgezet dan zal deze zeer waarschijnlijk ook weer een processed variant krijgen ( enkel dan waarschijnlijk niet in dbase maar in een ander caching systeem )

Don't get me wrong: iedere fatsoenlijke database kan dit handelen en storage kost idd geen drol meer. Maar hoe ga ik de verschillen uitleggen aan een nieuwe developer in mijn team?

Die verschillen moet je juist niet uitleggen aan een nieuwe developer. Daarvoor moet het juist inherent aan het systeem zijn. Daarbij moet die processed variant (imho) ook totaal geen waarde hebben.
Die moet je ongestraft weg kunnen gooien.

Of leg jij ook aan je nieuwe developers precies uit hoe het FS waarop je dbase draait zijn caches gebruikt?

Ik snap het voordeel wel van beide varianten opslaan, maar ik geloof dat RDBMS'en juist bedoeld waren om 1 canonieke variant van je data op te slaan. Met deze canonieke variant ben je uiteraard vrij om te doen en te laten wat je wil.

Dat is leuk totdat het opbouwen van de gewenste data uit de canonieke variant te lang gaat duren ( denk bijv aan tellertjes etc ). Dan wordt er veelal weer teruggeschakeld vanuit snelheidsoverwegingen.

Maar meestal is het premature optimization en zul je later alsnog een andere variant nodig hebben die toch weer een kleine hoeveelheid data manipulatie moet doen op datgene wat in je DB staat.

Als je het echt gaat toepassen op elke variant dan ben je wmb wel bezig met premature optimisation, als je het enkel doet voor de 99% gebruiks variant...

[st0p]

Avalaxy schreef op woensdag 28 juli 2010 @ 00:33:
[...]
Lijkt me dat een view perfect is voor dit doel? Je behoudt gewoon je originele date en update de view zodra de originele data wordt aangepast.

Dan verplaats ik logica naar mijn DB die daar imho niet thuishoort. Ik weet dat het een bijna religieuze discussie is, maar ik ben hier geen voorstander van.

RobIII schreef op woensdag 28 juli 2010 @ 00:12:
Performance bottlenecks moet je overigens gewoon meten en niet op de gok gaan zitten proberen oplossen.

Eensch.

RobIII schreef op woensdag 28 juli 2010 @ 00:37:
[...]

Ja en soms moet je jezelf niet in een hoekje normalizeren maar pragmatisch leren werken
[...]

Nog meer eensch. Echter dient wel eerst aangetoond te zijn dat dat je performance bottleneck hier ligt (en ik geloof werkelijk dat dit meestal niet het geval is)

Don't get me wrong: daar waar het aantoonbaar beter is om meerdere varianten van je data op te slaan: ga je gang! Heb je echter geen (bij voorkeur real-life) benchmark gegevens: hou je data model zo simpel mogelijk. Ik heb helaas teveel data modellen gezien die die dit soort 'optimalizaties' doorvoerden op een uiterst crappy en buggy manier (en ja, ik ben hier zelf ook schuldig aan geweest)

[Cartman!]

st0p schreef op woensdag 28 juli 2010 @ 01:05:
[...]

Dan verplaats ik logica naar mijn DB die daar imho niet thuishoort. Ik weet dat het een bijna religieuze discussie is, maar ik ben hier geen voorstander van.

Het is ook geen logica in je db maar simpele cache, een heel groot verschil.

gewoon dit idee dus:

PHP:

if(empty($row->message_parsed)) {
    $row->messages_parsed = parseMessage($row->message_raw);
    $row->save();
}

echo $row->message_parsed;

En als je nieuwe regels toevoegt dan gooi je dus gewoon je message_parsed leeg in je tabel en regelt het zichzelf weer. Zo complex is dat niet.