[PHP/(My)SQL] voor dummies - Deel 41

quote:

Op vrijdag 6 april 2007 16:58 schreef SuperRembo het volgende:

[..]

Nou, het werkt bij jou. Maar een kolom die niet in een group by en niet in een aggegate staat is niet goed gedefinieerd. De waarde die je terug krijgt kan van allerlei dingen afhangen zoals de indexen op de tabel of zelfs de volgorde waarin de regels in de tabel gezet zijn.

Hmz, nou ja ik heb dit zoals gezegd van de mysql website bij een uitleg over hierarchische data.
Maar die van jou werkt prima, en mysql ondersteunt toch vanaf 4.2 ofzo subqueries? Dan kan ik 'm weer omzetten

Na het weekend meer, ik ben nu een paar dagen afwezig. Bedankt weer voor de hulp!

Wie kan mij helpen? Mijn bod van 25 euro is nog geldig hoor

quote:

Op zaterdag 7 april 2007 15:57 schreef JohannesPaulus het volgende:
Wie kan mij helpen? Mijn bod van 25 euro is nog geldig hoor

Zet je Messenger client aan

Ik heb een vraag... qua database gebruik.

Voor een startpagina concept gebruik ik nu meerdere tabellen.

cats - voor de categorieen
html - voor html blokken
link - voor de links
user - voor gebruiker info

nu vraag ik mij af of het niet handiger is om HTML en LINK samen te voegen... of zeggen jullie dat dit preformance technisch beter is dat je gebruik maakt van 2 tabellen ipv 1?

Iemand een idee?

Ter vergelijking de tabellen.

HTML


en LINK

Ik zie niet in waarom je die niet in één tabel zou doen, een lange text uit een tabel halen is natuurlijk sneller als een text uit a, een link dit uit b, linkinformatie dat uit b, en die dan ook nog eens samenvoegen in php met een hele constructie. Zelfs als je die links apart editbaar zou willen maken kun je gewoon met regexen aan de slag.

Chandler, welke functie heeft de tabel 'html'?

@ralfie; hoeft niet persee met regex toch? gewoon een extra optie in de tabel (link, html, etc)

@Jera: De tabel HTML heeft als functie om het HTML gedeelte van de links gescheiden te houden, dit waar ik denk dat dit scheelt in de preformance omdat hier gebruik gemaakt wordt van 'TEXT' maar hier ben ik dus niet zeker van daarom vraag ik het even

Ik ben een admin pagina aan het maken voor mijn gastenboek, daarvoor wil ik dat het originele bericht in een veld van een formulier gezet wordt.



Dit doet hij wel alleen zet hij alleen het eerste woord van het bericht weg, hoe krijg ik dat dan voor elkaar?

Je hoort bij HTML altijd (!) quotes te gebruiken rond de attributen, dus zo:



Anders gaat het mis bij spaties. En als je de waarde van een PHP variabele in je output wil zetten, dan kun je er beter ook nog { en } omheen zetten.

@ timbastiaansen: Met enkele of dubbele quotjes bij $bericht ?

Mijn vraag:

Hoe kan ik ervoor zorgen dat een php script op het laatst nog even zijn output opschoont:

Voorbeeld:



Dat dit script dus allen "dag" echo-ed :-)

Daarvoor kun je kijken naar Output Control.

Dit laat alleen 'dag' zien.

quote:

Op dinsdag 10 april 2007 18:39 schreef HuHu het volgende:
Je hoort bij HTML altijd (!) quotes te gebruiken rond de attributen, dus zo:
[ code verwijderd ]

Anders gaat het mis bij spaties. En als je de waarde van een PHP variabele in je output wil zetten, dan kun je er beter ook nog { en } omheen zetten.

Helpt niet

Ik heb het nu zo



En dit geeft hetzelfde resultaat als zonder { }

Je kunt dit het beste zien als drie delen, <input value=" & $naam & "> , die doormiddel van punten aan elkaar worden gebonden.

quote:

Op dinsdag 10 april 2007 18:53 schreef timbastiaansen het volgende:

[..]

Helpt niet ;(

Ik heb het nu zo
[ code verwijderd ]

En dit geeft hetzelfde resultaat als zonder { }

Wel de hele post lezen hè ;).

Het gaat voornamelijk om de quotes, de " dus.

quote:

Op dinsdag 10 april 2007 19:04 schreef Geqxon het volgende:

[ code verwijderd ]

Je kunt dit het beste zien als drie delen, <input value=" & $naam & "> , die doormiddel van punten aan elkaar worden gebonden.

Als de de " in een string wilt hebben kun je makkelijker gewoon met de ' de echo beginnen. Dus zo:



Sowieso is het gebruik van de ' beter dan de ", omdat de tekst binnen een ' niet nog eens geparsed gaat worden en dus sneller wordt verwerkt.

En wat als je dan een single-quote binnen string wilt hebben? Ik prefereer double quotes, en een backslash voor de double quote binnen de string.

Een single-quote binnen een string komt met HTML output nauwelijks voor als het goed is. Verder is het sneller en persoonlijk vind ik al die backslashes maar rommelig staan.

quote:

Op dinsdag 10 april 2007 19:36 schreef HuHu het volgende:
Een single-quote binnen een string komt met HTML output nauwelijks voor als het goed is. Verder is het sneller en persoonlijk vind ik al die backslashes maar rommelig staan.

tijdje terug al gelezen (ergens in dit topique) dat enkele quotes niet tot nauwelijks sneller zijn, dus doe gewoon wat je makkelijk vind.

quote:

Op dinsdag 10 april 2007 17:47 schreef Chandler het volgende:
@Jera: De tabel HTML heeft als functie om het HTML gedeelte van de links gescheiden te houden, dit waar ik denk dat dit scheelt in de preformance omdat hier gebruik gemaakt wordt van 'TEXT' maar hier ben ik dus niet zeker van daarom vraag ik het even

Nou weet ik niet wat je totaalplan is met je design maar ik weet wel wat de meeste softwarebouwers doen als ze voor een keuze staan zoals die waar jij nu mee bezig bent: best of both worlds

Als ik jou was zou ik je database zo inrichten dat het zo genormaliseerd mogelijk is (wat het gemakkelijk voor je maakt om de contents van een pagina aan te passen via een CMS en je niet in tekstkolommen hoeft te gaan zitten regexen). Vervolgens ga je contents cachen je rendert bij een opvraag van zo'n blok (of pagina) je databaseinhoud naar HTML en slaat die HTML op (in een bestand, in een aparte tabel, etc) zodat je bij toekomstige opvragen niets hoeft te gaan opbouwen in PHP maar gewoon de HTML letterlijk uit de database kunt trekken. Zodra je dan iets aanpast in de database via je CMS ga je je cache 'invalidaten' zoals dat zo mooi heet, waardoor bij de eerst volgende opvraag de HTML opnieuw gerendert wordt.

Hier op FOK! wordt dat vziw ook gedaan, met de trackers op de frontpage bijvoorbeeld. Het scheelt ontzettend qua load als je niet elke keer hoeft te joinen en HTML moet wegschrijven, terwijl je vrijwel niets inlevert op gebruiksgemak voor de beheerder

quote:

Op dinsdag 10 april 2007 19:25 schreef HuHu het volgende:

[..]

Als de de " in een string wilt hebben kun je makkelijker gewoon met de ' de echo beginnen. Dus zo:
[ code verwijderd ]

Sowieso is het gebruik van de ' beter dan de ", omdat de tekst binnen een ' niet nog eens geparsed gaat worden en dus sneller wordt verwerkt.

Hoewel ik zelf alleen maar single quotes in PHP gebruik (voor zover dat mogelijk is) is dat laatste een slecht argument, keer op keer wijzen benchmarks erop dat het verschil om milliseconden gaat (op duizenden en duizenden echo's). Beter kijk je naar queries, de aanroep daarvan en alle overige functies van PHP (zie bijvoorbeeld het verschil tussen de preg* en de ereg*-functies ).

quote:

Op dinsdag 10 april 2007 19:55 schreef JeRa het volgende:

[..]

Nou weet ik niet wat je totaalplan is met je design maar ik weet wel wat de meeste softwarebouwers doen als ze voor een keuze staan zoals die waar jij nu mee bezig bent: best of both worlds

Als ik jou was zou ik je database zo inrichten dat het zo genormaliseerd mogelijk is (wat het gemakkelijk voor je maakt om de contents van een pagina aan te passen via een CMS en je niet in tekstkolommen hoeft te gaan zitten regexen). Vervolgens ga je contents cachen je rendert bij een opvraag van zo'n blok (of pagina) je databaseinhoud naar HTML en slaat die HTML op (in een bestand, in een aparte tabel, etc) zodat je bij toekomstige opvragen niets hoeft te gaan opbouwen in PHP maar gewoon de HTML letterlijk uit de database kunt trekken. Zodra je dan iets aanpast in de database via je CMS ga je je cache 'invalidaten' zoals dat zo mooi heet, waardoor bij de eerst volgende opvraag de HTML opnieuw gerendert wordt.

Hier op FOK! wordt dat vziw ook gedaan, met de trackers op de frontpage bijvoorbeeld. Het scheelt ontzettend qua load als je niet elke keer hoeft te joinen en HTML moet wegschrijven, terwijl je vrijwel niets inlevert op gebruiksgemak voor de beheerder

Hoe invalidate je je cache, en hoe cache je op de eerste plaats? Ik bedoel hoe weet ik dat de specifieke request van dat moment door een browser wordt gedaan die de website in zijn huidige vorm al eens gezien heeft?

quote:

Op dinsdag 10 april 2007 20:13 schreef Swetsenegger het volgende:

[..]

Hoe invalidate je je cache, en hoe cache je op de eerste plaats? Ik bedoel hoe weet ik dat de specifieke request van dat moment door een browser wordt gedaan die de website in zijn huidige vorm al eens gezien heeft?

Cachen is vrij simpel. Je houdt een aparte tabel bij met bijvoorbeeld een tekstuele identifier waarmee je de (unieke) cache identificeert. Het invalidaten kun je doen door zodra er in je CMS iets verandert de cache uit de tabel te gooien. Vervolgens kun je op de pagina waar de cache aangesproken wordt controleren of de cache bestaat, en zo niet: renderen die hap.

Je laatste vraag is een lastigere, maar dat bewerkstellig je door specificatie je moet specificeren óf iets wel gecached mag worden aan de hand van kennis over de inhoud. Een stukje HTML met daarin de huidige tijd moet je natuurlijk niet gaan cachen. Een cache kun je dus limiteren over een beperkt stuk van je website, maar ook in zijn geheel. Je zou bijvoorbeeld als unieke cache identifier de aanroep van de browser kunnen nemen (de URL?). Daarmee moet je natuurlijk oppassen dat je niet teveel meeneemt, anders kan een lolbroek je hele cache tabel volstoppen met nutteloze caches.

Verder is het niet beperkt tot één browser/client maar moet je caches voor iedereen beschikbaar maken zoals ik al als voorbeeld aanhaalde, de trackers op de frontpage hier zijn voor iedereen hetzelfde en hoeven pas geüpdatet te worden zodra een nieuwsposter een nieuw bericht plaatst.

quote:

Op dinsdag 10 april 2007 20:17 schreef JeRa het volgende:

[..]

Cachen is vrij simpel. Je houdt een aparte tabel bij met bijvoorbeeld een tekstuele identifier waarmee je de (unieke) cache identificeert. Het invalidaten kun je doen door zodra er in je CMS iets verandert de cache uit de tabel te gooien. Vervolgens kun je op de pagina waar de cache aangesproken wordt controleren of de cache bestaat, en zo niet: renderen die hap.

Je laatste vraag is een lastigere, maar dat bewerkstellig je door specificatie je moet specificeren óf iets wel gecached mag worden aan de hand van kennis over de inhoud. Een stukje HTML met daarin de huidige tijd moet je natuurlijk niet gaan cachen. Een cache kun je dus limiteren over een beperkt stuk van je website, maar ook in zijn geheel. Je zou bijvoorbeeld als unieke cache identifier de aanroep van de browser kunnen nemen (de URL?). Daarmee moet je natuurlijk oppassen dat je niet teveel meeneemt, anders kan een lolbroek je hele cache tabel volstoppen met nutteloze caches.

Verder is het niet beperkt tot één browser/client maar moet je caches voor iedereen beschikbaar maken zoals ik al als voorbeeld aanhaalde, de trackers op de frontpage hier zijn voor iedereen hetzelfde en hoeven pas geüpdatet te worden zodra een nieuwsposter een nieuw bericht plaatst.

Helder, dank je