[PHP/(My)SQL] voor dummies - deel 58

Met behulp van een soortgelijke query moet dat lukken. _{(In oude topics staan nog wel eens handige dingen)}

quote:

Op zaterdag 3 mei 2008 14:16 schreef Dzy het volgende:
Ik heb een vraagje

Ik ben bezig met een site waar een heleboel gedichten op komen te staan van dezelfde dichter. Deze kan hij taggen met meerdere tags, die allemaal weer in een aparte tabel tags staan. Omdat er meerdere tags bij meerdere gedichten kunnen gebruik ik een koppeltabel gedichten_tags. Alleen hoe kan ik nu mooi in 1 query alle gedichten opvragen die bij 1 of meer tags horen?

Ik zat zelf al een beetje te prutsen met de volgende query:
[ code verwijderd ]

Dit zou dan alle gedichten opvragen die een tag hebben van 1, 3 of 4 maar de bedoeling is natuurlijk dat ze alle drie zo getagd moeten zijn. En voor mijn gevoel is dit een ranzige query, maar dat kan ik verkeerd hebben. Ingewikkelde queries ben ik nog niet zo goed in Wie kan me helpen?

Ik zie niks verkeerd aan deze query om heel eerlijk te zijn. Maar toegegeven SQL is niet mijn sterkste ding.

Dan zou het dus iets soortgelijks worden:


worden?

Ik snap de query nog niet helemaal :P Wat doet dat GROUP BY nou precies? Zorgt die dat die duplicates wegblijven? En die HAVING COUNT zorgt ervoor dat alleen resultaten die precies 3 keer voorkomen doorkomen om te zorgen dat alle tags aanwezig moeten zijn? Als ik nog andere zoekdingen toevoeg dan maakt het niet uit verder toch? Zolang het geen moeilijke constructies worden zal hij er altijd 3 blijven vinden of niet?

_{Bedankt, ben nog niet zo'n ster in MySQL maar er komt verandering in, tof onderschrift trouwens :P}

quote:

Op zaterdag 3 mei 2008 15:06 schreef Dzy het volgende:
Ik snap de query nog niet helemaal :P

Zie andere topic :P


Het zou (uitgaande van MySQL 5) zo iets worden:

quote:

Op donderdag 1 mei 2008 18:20 schreef Flaccid het volgende:
Ik heb een functie met die checkt of een variable leeg is of niet, wanneer hij leeg is zegt hij dat hij leeg is . Maar dan wordt het: Hoe krijg je de tekst van een variable die leeg is op het scherm, dus de naam van de lege variable?
[ code verwijderd ]

omfg

Ik heb het aan de praat, dankjewel. Hier is een query die ik gebruik om op 2 tags te zoeken die moeten matchen en het moet uit een bepaald boekje komen:



Doet het prima :) Thanks! Ik snap het ook zowaar :P

quote:

Op zaterdag 3 mei 2008 15:34 schreef SuperRembo het volgende:

[..]

Zie andere topic


Het zou (uitgaande van MySQL 5) zo iets worden:
[ code verwijderd ]

Zover ik tot nog toe heb ondervonden duren dit queries (dus met querie in querie) langer dan een join.

quote:

Op zaterdag 3 mei 2008 16:40 schreef ursel het volgende:

querie in querie

Een subquery dus

Als je fatsoenlijke caching van de output gebruikt zou het snelheidsverschil weinig invloed mogen hebben overigens.

Zijn er hier überhaupt mensen bezig met memcached en dergelijke?

quote:

Op zaterdag 3 mei 2008 16:40 schreef ursel het volgende:
Zover ik tot nog toe heb ondervonden duren dit queries (dus met querie in querie) langer dan een join.

In dit geval lukt het ook wel zonder sub-query, alleen wordt 't daar wat minder overzichtelijk van. En de vraag is of 't echt sneller is.


_{(En alles wat je in de SELECT opneemt ook toevoegen aan de GROUP BY)}

quote:

Op zaterdag 3 mei 2008 16:56 schreef CraZaay het volgende:
Zijn er hier überhaupt mensen bezig met memcached en dergelijke?

Wat bedoel je daar precies mee?

quote:

Op zaterdag 3 mei 2008 18:04 schreef SuperRembo het volgende:

Wat bedoel je daar precies mee?

Eigenlijk wat er staat Zijn er hier mensen die bijvoorbeeld query results cachen d.m.v. bijvoorbeeld memcached (cachen in geheugen). Ik gebruik het veelvuldig voor zeer drukke websites, waarbij query results in het geheugen gaan totdat ze geïnvalideerd worden. Voor sommige sites gaan er hele stukken HTML (segmenten of hele pagina's) in het geheugen.

Misschien niet van toepassing op de meeste sites die hier gebouwd worden (geen idee over wat voor projecten we het hier hebben), maar voor echt drukke sites is het onmisbaar.

Ik gebruik de cachingfunctie van Smarty, voor de templates / HTML dus. Op dynamische pagina's heb je daar niks aan, maar bij pagina's die weinig tot nooit wijzigen is de winst opvallend groot.

Verder gebruik ik Adodb als database class, en die heeft ook een caching functie waarbij het resultaat in een file opgeslagen wordt. Het opzoeken en inlezen van de file is dermate traag dat je het eigenlijk alleen als backup-mechanisme kunt gebruiken, iets wat de documentatie zelf ook aangeeft.

Met cachen in het geheugen heb ik geen ervaring.... Aan wat voor bezoekersaantallen / queries moet ik denken als jij het over een drukke site hebt?

Ik heb er op m'n werk wel eens mee moeten werken, afhankelijk van allerlei factoren scheelt het een beetje tot een hele boel, vooral afhankelijk van hoe vaak en veel de data verandert. Maar inderdaad, voor 99% van de sites die hier gebouwd worden is het vrij zinloos.

Ik heb nog een vraagje hoe jullie het volgende zouden aanpassen:

Ik kan nu mooi zoeken in de gedichten op meerdere dingen, op tags, het boek waar het gedicht in staan en/of de inhoud en titel. Deze query dingen staan gewoon in de url dmv GET, zelfs als je een gedicht aan het lezen bent. Hierdoor kan ik binnen dezelfde selectie gedichten met pijltjes vooruit en achteruit in de gedichten. Dus stel dat ik een zoekactie heb gedaan op gedichten met het woord School erin en de tag Liefde, dan staat in de url. Dan krijg ik een lijstje met gedichten die hieronder vallen, klik ik er een aan en dan krijg ik die voorgeschoteld. Nu wil ik dus zonder op Vorige te drukken naar het volgende of vorige gedicht in de selectie komen door op een pijltje te drukken. Dit is niet zo moeilijk te realiseren alleen zijn er een paar verschillende opties, wat zouden jullie doen:

- Zodra je bent gaan zoeken alle IDs van de gedichten op volgorde in een sessie op slaan zodat je die heel makkelijk kunt checken om de pijltjes te maken met de goede link erbij. Nadeel van deze is dat er echt duizenden gedichten in de database komen en je dus bij een hele vrije search makkelijk 2000 ID's op gaat slaan. Ik weet niet precies wat voor limiet er bij sessions zitten maar op deze host zal het vast niet hoog zijn.
- Als je het bericht checkt kun je zo de search opnieuw doen zonder limit en dan zo de vorige en volgende ID ophalen. Nadeel is wel dat je dan elk gedicht weer de query moet uitvoeren.

EDIT: Nadeel bij 1 vergeten.

quote:

Op zaterdag 3 mei 2008 18:56 schreef Xcalibur het volgende:
Aan wat voor bezoekersaantallen / queries moet ik denken als jij het over een drukke site hebt?

Een project wat ik voor NU.nl gedaan heb bijvoorbeeld (da's extreem), maar ook een jongerensite met een sociaal netwerk wat met 30.000 pageviews per dag al aardig wat zware queries oplevert.

Nee, memcached gebruik ik niet, maar dat had je al wel begrepen
Ziet er interessant uit, daar moet ik eens in duiken.

Memcache gebruik ik niet zo vaak maar ik gebruik wel regelmatig sql caching, waar het resultaat van een loodzware query geserialized wordt opgeslagen in een objectstorage in de db. Aan memory caching heb je in dit geval minder omdat het om queries gaat waar het resultaat hoogstens 1 keer per dag wijzigt en je aan alle bezoekers hetzelfde resultaat wil tonen. Die wil je dus ook maar 1 keer per dag berekenen, niet meer.
Eigenlijk gebruik ik caching alleen als het echt heel nodig is - als het om het verschil tussen een server die op zijn bek gaat en een server die netjes door blijft werken gaat bijvoorbeeld - maar als het niet perse moet dan liever niet. Caching kan voor allerlei nare problemen zorgen en maakt troubleshooten ook vaak moeilijker.

quote:

Op zondag 4 mei 2008 01:17 schreef Farenji het volgende:
Memcache gebruik ik niet zo vaak maar ik gebruik wel regelmatig sql caching, waar het resultaat van een loodzware query geserialized wordt opgeslagen in een objectstorage in de db. Aan memory caching heb je in dit geval minder omdat het om queries gaat waar het resultaat hoogstens 1 keer per dag wijzigt en je aan alle bezoekers hetzelfde resultaat wil tonen. Die wil je dus ook maar 1 keer per dag berekenen, niet meer.

Waarom zou memcached hier niet geschikt voor zijn? In dat geval check ik in de model of het result in de cache zit, en zo niet voer ik de query uit en sla het resultaat op in de cache met een time to live van 24 uur

Kleine vraag, stel ik heb een hostname cc93022-a.tu.nogwat.home.nl

Van deze hostname wil ik het volgende uitlezen (maar dit kan natuurlijk ook een andere hostname zijn)
- home.nl
- home
- @home internet Groningen Nederland (dit kun je ergens uitlezen maar waar?)

Is er voor de 1e 2 een regex die ook werkt met co.uk en dergelijke domeinnamen? en waar kan ik de 3e gegeven weg halen?

ik denk dat je de eerste 2 wel met parse_url() kunt uitvinden.
De 3e krijg je met gethostbyaddr() denk ik....

quote:

Op maandag 5 mei 2008 09:14 schreef Chandler het volgende:
Kleine vraag, stel ik heb een hostname cc93022-a.tu.nogwat.home.nl

Van deze hostname wil ik het volgende uitlezen (maar dit kan natuurlijk ook een andere hostname zijn)
- home.nl
- home
- @home internet Groningen Nederland (dit kun je ergens uitlezen maar waar?)

Is er voor de 1e 2 een regex die ook werkt met co.uk en dergelijke domeinnamen? en waar kan ik de 3e gegeven weg halen?

punt 3 is alleen uit te lezen bij @home en nog een geloof ik. Bij planet (mijn ISP) wordt het niet meegestuurd. Je hebt wel databases die dat soort info verzamelen en waar je beroep op kunt doen, sommige gratis, sommige niet.

Ik heb een tabel met Auto Increment, hoe krijg ik nu heel makkelijk het laatste ID eruit?

Nu doe ik namelijk SELECT id FROM gegevens ORDER BY id DESC LIMIT 1, maar kan dat niet sneller?

quote:

Op maandag 5 mei 2008 14:54 schreef wobbel het volgende:
Ik heb een tabel met Auto Increment, hoe krijg ik nu heel makkelijk het laatste ID eruit?

Nu doe ik namelijk SELECT id FROM gegevens ORDER BY id DESC LIMIT 1, maar kan dat niet sneller?

SELECT MAX(id) FROM gegevens ?

Trouwens nog een leuke link gevonden over memcaching:

http://www.search-this.co(...)uction-to-memcached/

quote:

Op maandag 5 mei 2008 14:59 schreef JortK het volgende:

[..]

SELECT MAX(id) FROM gegevens ?

moet ik die dan weer opvragen met mysql_fetch_assoc of kan dat ook met mysql_result ofzo?

quote:

Op maandag 5 mei 2008 15:11 schreef wobbel het volgende:

[..]

moet ik die dan weer opvragen met mysql_fetch_assoc of kan dat ook met mysql_result ofzo?

Zo ff uit mn hoofd :P

quote:

Op maandag 5 mei 2008 15:12 schreef Piles het volgende:

[..]
[ code verwijderd ]

Zo ff uit mn hoofd

Ah bedankt, gewoon met mysql_result!!

Super jongens, weeti k dat ook weer

Als je de id wil weten van de row die je net ge-insert hebt, dan kan je beter mysql_insert_id() gebruiken.

quote:

Op maandag 5 mei 2008 16:36 schreef SuperRembo het volgende:
Als je de id wil weten van de row die je net ge-insert hebt, dan kan je beter mysql_insert_id() gebruiken.

Goede tip zeg

quote:

Op maandag 5 mei 2008 16:36 schreef SuperRembo het volgende:
Als je de id wil weten van de row die je net ge-insert hebt, dan kan je beter mysql_insert_id() gebruiken.

Die kende ik gelukkig al


Andere vraag: Ik heb onderstaande query, alleen daar is blijkbaar iets fout aan



Foutmelding

quote:

You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '.IdCart WHERE SHOP_Carts.IdCart = '1'' at line 1

quote:

Op maandag 5 mei 2008 18:54 schreef wobbel het volgende:

[..]

Die kende ik gelukkig al ;)


Andere vraag: Ik heb onderstaande query, alleen daar is blijkbaar iets fout aan :P
[ code verwijderd ]

Foutmelding
[..]

Moet het niet zijn