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

quote:

Op dinsdag 24 maart 2009 19:24 schreef Scorpie het volgende:
Welk pattern gebruiken jullie om objecten aan te maken binnen jullie applicatie? Voor domain objecten lijkt mij een DomainObjectFactory class handig, die elke keer 1 instantie van een object retourneert?

Of gebruiken jullie een generieke oplossing voor al jullie objecten?

PHP/MySQL?

quote:

Op dinsdag 24 maart 2009 19:10 schreef GlowMouse het volgende:

[..]

Je kunt bijvoorbeeld zeggen: WHERE id = (SELECT max(id) FROM fotoboek_comments WHERE ...)

Flaccid:
1. Domtree of regex, kies maar
2. Wat is per entry? je wilt van élk record 2 velden? Dat is snel maar je moet geen duizenden records hebben.
3. Zoek eens op xmlHttpRequest, er komt wat JavaScript en PHP bij kijken

1. Ik snap even niet.
2. Ja ik kan even niet op die term in een mysql table komen. Gewoon zo'n rij in een mysql table.
3. Ik dacht dat het wel snel te doen was, maar dat valt tegen.

ik heb me probleem weten op de lossen met een subquery, volgens mij is die niet optimaal maar dat maakt niet uit.
Het is een script op de website van een studentenvereniging, ik weet 100% zeker dat er slechtere code te vinden is op die site.

bedankt voor de hulp

quote:

Op dinsdag 24 maart 2009 18:44 schreef GlowMouse het volgende:
Kijken wanneer het plaatje voor het laatst is aangepast, en indien lang genog, een ander plaatje tonen?

thanks, je hebt me op een idee gebracht die ook nog werkt..
het is niet super maar werkt wel goed

quote:

Op dinsdag 24 maart 2009 23:48 schreef bassiedekloon het volgende:

thanks, je hebt me op een idee gebracht die ook nog werkt..
het is niet super maar werkt wel goed

En welk idee is dat?

quote:

Op dinsdag 24 maart 2009 19:59 schreef slacker_nl het volgende:

[..]

Hoezo zou het niet werken? Werkt bij mij anders perfect...

http://dev.mysql.com/doc/refman/5.1/en/select.html
En DISTINCT is verder geen bijzondere functie. Ik heb het voor je getest met MySQL 5.0.38 en 5.1.32, maar het werkt gewoon niet.

quote:

Knappe studiebol ben je dat je aan de hand van 1 table kan zien hoe zijn datamodel eruit ziet. Jij hebt zeker de glazen bol gejat die iedereen mist (zie OP).

Daar heb je geen glazen bol voor nodig. Ik zal je de algemene regel schenken: wanneer je wilt sorteren op kolom A en slechts één A wilt bij iedere unieke waarde uit kolom B (met B ongelijk A) dan kan MySQL die query niet efficiënt uitvoeren.

quote:

Op woensdag 25 maart 2009 12:36 schreef GlowMouse het volgende:
Daar heb je geen glazen bol voor nodig. Ik zal je de algemene regel schenken: wanneer je wilt sorteren op kolom A en slechts één A wilt bij iedere unieke waarde uit kolom B (met B ongelijk A) dan kan MySQL die query niet efficiënt uitvoeren.

Subqueries zie ik ook liever niet, maar die zijn er niet voor niks. Als de functionaliteit van de applicatie iets vereist dat alleen met subqueries op te lossen is, dan kom je er in sommige gevallen niet onderuit.

Maar jij bent d'r zeker zo eentje die zo min mogelijk de DB wilt belasten, maar wel databasezaken op applicatieniveau gaat oplossen. Nee dát is efficiënt.

Websites moeten snel zijn omdat dat fijn is voor de gebruikeren omdat je server dan meer bezoekers aan kan. Voor je back-end zijn subqueries minder erg en kunnen ze soms leuke statistieken tevoorschijn toveren.
Per geval kun je nadenken wat je het beste kunt doen. Soms valt de query iets te herschrijven. Hier is dat niet mogelijk, dus zul je het resultaat moeten cachen.
Deze query gaat er bij een wat grotere dataset seconden over doen (benchmark: 60+ seconden bij 30k reacties) en dat is onacceptabel. MySQL kan hem slecht cachen omdat de reactietabel vaak geüpdatet wordt. Dus dan moet je applicatie maar helpen.

Sorry, maar dat is geen haar beter. Ik vind het altijd lullig om te zien wanneer mensen keurige, semantische websites opzetten (inhoud in de HTML, opmaak in de CSS, unobtrussive Javascript apart, enzovoorts) onder het mom van 'zaken neerleggen waar ze horen', maar vervolgens achteliggende broncode hebben waar je van gaat janken. In de regel vaak hele goede programmeurs die enkel op PHP / ASP gefocused zijn maar geen flauw benul van SQL hebben, of té gemakzuchtig zijn in hun backend.

In bovenstaand voorbeeld verbeter je de performance van een functionaliteit niet, je verlegt de belasting die er door plaats vindt alleen maar, nota bene naar een plek waar het niet eens hoort. Lappen aan SQL scripts in codefiles / codebehinds is een ranzige gewoonte. En dan vooral wanneer er (weer eens) iets in de databasestructuur van de betreffende applicatie moet veranderen, en allerlei vage bestanden met hardcoded queries moet gaan doorzoeken.

Sowieso is je voorbeeld erg overdreven. Op iets eenvoudigs als een reactie-tabel, kun je toch snelle queries draaien waar subqueries in zitten. Sowieso haal je in geval van reacties altijd maar een bepaald aantal op (hee, LIMIT ), en zit er in die reactie-tabel een veld dat verwijst naar de bovenliggende tabel (hee, een INDEX ). Als er honderdduizenden records in die reactie tabel zitten dan zal die ietsjes langzamer zijn dan wanneer er maar 10 records in zitten, maar 60+ seconden? Kom op zeg.

Ik geef je eens een ander voorbeeld. Stel je hebt een webshop met rubrieken. Die rubrieken zijn dusdanig opgezet dat je onbeperkt diep child-rubrieken kunt aanmaken onder bestaande rubrieken. Van elke rubriek wil je het actuele aantal producten in diezelfde rubriek en diens onderliggende rubrieken hebben. Hoe zou jij dat oplossen?

[ Bericht 3% gewijzigd door Tuvai.net op 25-03-2009 13:30:30 ]

Caching anyone? Ik gebruik regelmatig subqueries, maar dit geldt voor alle soorten queries, etc: het is onzin om ze voor een high traffic app bij iedere request uit te voeren. Het resultaat cachen kan vrijwel altijd.

En voor een low traffic site is het helemaal niet interessant, want dan staat je DB-server ook met zwaarde queries uit zijn neus te vreten.

quote:

Op woensdag 25 maart 2009 13:01 schreef GlowMouse het volgende:
Websites moeten snel zijn omdat dat fijn is voor de gebruikeren omdat je server dan meer bezoekers aan kan. Voor je back-end zijn subqueries minder erg en kunnen ze soms leuke statistieken tevoorschijn toveren.
Per geval kun je nadenken wat je het beste kunt doen. Soms valt de query iets te herschrijven. Hier is dat niet mogelijk, dus zul je het resultaat moeten cachen.
Deze query gaat er bij een wat grotere dataset seconden over doen (benchmark: 60+ seconden bij 30k reacties) en dat is onacceptabel. MySQL kan hem slecht cachen omdat de reactietabel vaak geüpdatet wordt. Dus dan moet je applicatie maar helpen.

Als je 30k reacties hebt en je query heeft 60+ seconden nodig, dan staan je indices niet goed. Misschien moet je ook de query zelf aanpassen, maar goed geplaatste indices doen heel veel.

quote:

Op woensdag 25 maart 2009 13:12 schreef Tuvai.net het volgende:
Sowieso is je voorbeeld erg overdreven. Op iets eenvoudigs als een reactie-tabel, kun je toch snelle queries draaien waar subqueries in zitten. Sowieso haal je in geval van reacties altijd maar een bepaald aantal op (hee, LIMIT ), en zit er in die reactie-tabel een veld dat verwijst naar de bovenliggende tabel (hee, een INDEX ). Als er honderdduizenden records in die reactie tabel zitten dan zal die ietsjes langzamer zijn dan wanneer er maar 10 records in zitten, maar 60+ seconden? Kom op zeg.

Je hebt gelijk, subquery met LIMIT en een tweetal indices doet wonderen hier. Blijft een relatief langzame query, maar het is nu te overzien (paar honderdsten van een seconde, afhankelijk van waar de laatste reacties geplaatst zijn).

quote:

Ik geef je eens een ander voorbeeld. Stel je hebt een webshop met rubrieken. Die rubrieken zijn dusdanig opgezet dat je onbeperkt diep child-rubrieken kunt aanmaken onder bestaande rubrieken. Van elke rubriek wil je het actuele aantal producten in diezelfde rubriek en diens onderliggende rubrieken hebben. Hoe zou jij dat oplossen?

Extra veld in de rubriektabel.

quote:

Op woensdag 25 maart 2009 13:38 schreef GlowMouse het volgende:
Je hebt gelijk, subquery met LIMIT en een tweetal indices doet wonderen hier. Blijft een relatief langzame query, maar het is nu te overzien (paar honderdsten van een seconde, afhankelijk van waar de laatste reacties geplaatst zijn).

Zo 'relatief' langzaam dat de gebruiker er niks van merkt. Ook in geval van honderdduizenden records niet. Die paar milliseconden op zo veel records zijn verwaarloosbaar, vooral als dat de schaalbaarheid, overzichtelijkheid en flexibiliteit van de broncode ten goede doet.

quote:

Op woensdag 25 maart 2009 13:38 schreef GlowMouse het volgende:
Extra veld in de rubriektabel.

Dus elke keer wanneer een product toegevoegd of verwijdert wordt ga je alle rubrieken (en subrubrieken, en diens subrubrieken, enz) nalopen, het aantal producten in die rubriek (en subrubrieken, en diens subrubrieken) met een COUNT(*) ophalen en die waarde wegschrijven? Waar leg je die functionaliteit en hoe doe je dat dan?

Een mogelijke situatie:


Stel je verwijdert een product in rubriek '- - - A E C', dan zal het productaantal van rubriek '- A' ook actueel moeten worden. Erg veel COUNT(*) query`tjes zeg.

Wat doe je overigens als een DBA in 'geval van nood' een product via de database moet verwijderen of 'recoveren'?

Vraagje, hoe kan ik binnen een grote tekst binnen bepaalde elementen iets wijzigen?

stel ik heb de volgende tekst

<table>
<tr>
<td>{=test}</td>
<td>{te=st}</td>
<td>{test=}</td>
</tr>

Nu wil ik deze data alles tussen de {} filteren en de = verwijderen... hoe kan ik dit doen?

Regex om de inhoud van alle {} te vinden en daar vervolgens je filter op loslaten

Tja dat kan ook, maar hoopte eingelijk op een simpele preg_replace.

Leek mij namelijk sneller.

Het filteren van alle {*} is idd wel te doen maar nogmaals had liever een preg_replace die het allemaal in 1x deed

quote:

Op woensdag 25 maart 2009 13:48 schreef Tuvai.net het volgende:
Stel je verwijdert een product in rubriek '- - - A E C', dan zal het productaantal van rubriek '- A' ook actueel moeten worden. Erg veel COUNT(*) query`tjes zeg.

Beter bij het updaten dan bij het opvragen. Bij een webwinkel gebeurt dat laatste veel vaker. En als je voor je site die getallen veel nodig hebt, dan ga je denormaliseren. Gebeurt ook veel in fora, bijvoorbeeld de berichtenteller, zie phpbb, zie vbulletin, zie myreact.

quote:

Wat doe je overigens als een DBA in 'geval van nood' een product via de database moet verwijderen of 'recoveren'?

Dan bouw je een knop in waarmee alle tellers opnieuw berekend worden.
Mooie code is niet altijd het criterium.

quote:

Op woensdag 25 maart 2009 17:47 schreef GlowMouse het volgende:
Mooie code is niet altijd het criterium.

Nee, maar jouw methode houdt wel in dat je op gigantisch veel plekken in je applicatie herhaaldelijke en overbodige code gaat neer plempen. Je hebt producten die besteld worden (en dus in aantal krimpen), beheermodules waar producten toegevoegd en verwijderd kunnen worden, en tig andere situaties die de aantallen in kwestie beïnvloeden en waar jij dus in je broncode stukjes voor moet gaan plaatsen om die aantallen bij te houden. Nog even afgezien van het feit dat DBA`ers 'in geval van nood' (recovery) of uit pure gemakszucht ook nog wel eens zo je database in gaan om e.e.a. aan te passen, buiten de applicatie om. Ja, je kunt een knopje maken waarmee je wederom wéér letterlijk alles na moet gaan lopen (dus ook de rubrieken die niet ter sprake zijn) en berekenen, maar da's ook niet echt lekker voor daadwerkelijk actuele cijfers (want hoe vaak moet jij deze zware functie niet gaan uitvoeren om je cijfers daadwerlelijk actueel te houden? ) en de databaseperformance die jij zo belangrijk vindt.

Dan doe mij maar de berekening bij het opvragen. Dan leg je die (recursieve) functie in de database neer en hoef je dat aantal enkel uit te lezen en weer te geven in je code. Het hele gebeuren staat op één plek, is in geval van wijzigingen in de databasestructuur eenvoudig en snel aan te passen en is altijd, hoe dan ook, actueel. Het betreft eenvoudige COUNT()s, dus waar hébben we het over qua performanceverlies indien dit bij het opvragen gebeurt?

Database-optimalisatie vind ik net zoals jezelf heel belangrijk, maar gigantisch omslachtige en misplaatste methodes gaan toepassen voor een verwaarloosbaar stukje performancewinst van een paar milliseconden, is maar mijn mening gewoon debiel. Heeft wat mij betreft iets weg van fetisjisme ("Databaseperformance hoog in het vaandel houden, de rest kan wat mij betreft stikken!").

[ Bericht 0% gewijzigd door Tuvai.net op 25-03-2009 18:41:10 ]

je zit er wel mee dat in een grote site/webshop je niet meer zit met een tabel producten en een tabel categorieen.

We zijn op het werk met een shop bezig, maar je kan echt niet zomaar 100 counts per request gaan doen, dan komt het niet goed (en helemaal niet als je naar schaalbaarheid kijkt)

hallo ik krijg iets niet voor elkaar..

ik wil namelijk $_GET['room'] ipv van de 101 hebben in het volgende stukje

alleen als ik dat doe krijg ik steeds een foutmelding.
weet iemand hoe dat moet?

Post de code eens die de fout geeft zou ik zeggen