[MySQL] Probleem met like query

[Martine]

Voor een nieuwe website foto website ben ik bezig om een zoekfunctie te maken. Er zal gezocht worden op album titel, album omschrijving, item titel en item omschrijving.

Ieder fotoalbum heeft een titel en een korte album omschrijving. Ook iedere foto heeft een titel en een korte omschrijving. De tabel waar in de album staan heten 'fotoalbums' en alle foto's worden opgeslagen in 'items'.

Hoe kan ik checken als het zoekwoord -in dit geval 'beer'- nu gevonden is in de album titel of album omschrijving? Dit is noodzakelijk om te weten, want als het zoekwoord bijvoorbeeld in de albumtitel gevonden wordt moet de laatste foto van het album getoond worden.
En als de zoekwoord in een fototitel (items.title) gevonden wordt, moet die foto getoond worden.

Daarnaast moet de link ook aangepast worden zodat je erop klik, dat je direct de gevonden foto krijgt te zien. Dit is natuurlijk te controleren met php, maar nu komt de vraag, hoe maak ik zoiets in godsnaam? Ik heb er gisteravond (lees; vannacht) al even mee zitten te stoeien, alleen kom ik er niet uit. Wie kan een met goede tip geven?

code:

SELECT
    m.id,
    m.title,
    m.description,
    i.id AS item_id,
    i.title AS item_title,
    i.description AS item_description,
    DATE_FORMAT(m.post_date, '%d-%m-%Y') AS date_album,
    CONCAT(i.id,'_',i.fileid,'_s\.jpg') AS img
FROM
    fotoalbums m
LEFT JOIN
    items i ON m.id = i.albumid
WHERE
    (
    m.title LIKE '%beer%'
    OR m.description LIKE '%beer%'
    OR i.title LIKE '%beer%'
    OR i.description LIKE '%beer%'
    )
GROUP BY m.id
ORDER BY m.post_date DESC

[Mental]

Zou je er ook bij kunnen vermelden wat er nu exact niet goed gaat en met welke database je werkt? (Andere sql database = ander sql dialect, kan problemen opleveren)

edit:

Wat je natuurlijk kunt doen is beginnen met het oplossen van het probleem wat je hebt voordat je de query op je overige eisen aanpast:

code:

SELECT m.id,m.title,m.description
FROM fotoalbums m 
WHERE m.title LIKE '%beer%' 
OR m.description LIKE '%beer%';

In je eigen code:

code:

 GROUP BY m.id

Waarom staat dit hier? Hoe ben je tot deze query gekomen?

[ Voor 54% gewijzigd door Mental op 17-08-2009 14:19 ]

[whoami]

Alle gegevens die je nodig hebt, ophalen mbhv een SQL query.

Bepalen welke gegevens er moeten getoond worden, doe je niet in je SQL Query, maar doe je in je presentatie-laag. (En dus bijgevolg in de taal die je daar gebruikt; php, c#, whatever).

[Mental]

whoami schreef op maandag 17 augustus 2009 @ 14:19:
Alle gegevens die je nodig hebt, ophalen mbhv een SQL query.

Bepalen welke gegevens er moeten getoond worden, doe je niet in je SQL Query, maar doe je in je presentatie-laag. (En dus bijgevolg in de taal die je daar gebruikt; php, c#, whatever).

Dus jij gaat een tabel van 20000 regels inladen om 1 fotoalbum te laten zien via een search? Beetje vreemd om je webserver de load op zich te laten nemen ipv de databaseserver (die ervoor bedoeld is).

[Martine]

Er wordt gebruik gemaakt van MySQL 5.0.45 icm met PHP 5, verder gaat alles goed alleen wil ik controleren waar het zoekwoord in gevonden wordt. In het album of in het item. Dus in het album (fotoalbums.title, fotoalbums.description) of in het item (items.title, items.description)

[NMe]

whoami schreef op maandag 17 augustus 2009 @ 14:19:
Alle gegevens die je nodig hebt, ophalen mbhv een SQL query.

Bepalen welke gegevens er moeten getoond worden, doe je niet in je SQL Query, maar doe je in je presentatie-laag. (En dus bijgevolg in de taal die je daar gebruikt; php, c#, whatever).

Dit is op zich echter natuurlijk relatief makkelijk te filteren. Het probleem zal hier zijn dat die group by gewoon niet goed is, zoals zo'n beetje in elk topic met een group by hier op GoT. Zie ook Programming FAQ - SQL: Hoe werkt dat GROUP BY nu eigenlijk?

Martine schreef op maandag 17 augustus 2009 @ 14:21:
Er wordt gebruik gemaakt van MySQL 5.0.45 icm met PHP 5, verder gaat alles goed alleen wil ik controleren waar het zoekwoord in gevonden wordt. In het album of in het item. Dus in het album (fotoalbums.title, fotoalbums.description) of in het item (items.title, items.description)

Je zou een conditionele select kunnen doen waarbij je de letterlijke string 'album' selecteert als de like matcht op album, en anders 'item'. Netjes is dat echter niet, die check kun je veel beter in je code doen. Een database is bedoeld om data terug te geven in een door jou aangegeven vorm, niet om aan te geven in welke vorm deze data eigenlijk in de database staat.

[ Voor 37% gewijzigd door NMe op 17-08-2009 14:25 ]

[Mental]

Martine schreef op maandag 17 augustus 2009 @ 14:21:
Er wordt gebruik gemaakt van MySQL 5.0.45 icm met PHP 5, verder gaat alles goed alleen wil ik controleren waar het zoekwoord in gevonden wordt. In het album of in het item. Dus in het album (fotoalbums.title, fotoalbums.description) of in het item (items.title, items.description)

Ik sluit me dan alsnog aan bij whoami dat je dit gewoon in je presentatielaag (php/cgi/whatever) moet afvangen.
simpele if statement die kijkt waar het zoekwoord in voorkomt en voila.. WANT.. wat nou als het zoekwoord op 2 plaatsen voorkomt? Wat wil je dan als voorkeur? Dit soort dingen kan je veel beter gewoon 'handmatig' doen dmv if-statements / cases.

[Woy]

Wat wil er precies niet lukken? Ik zie wel een query, maar ik zie het probleem bij je LIKE gedeelte niet. Je geeft ook niet aan welke resultaten je krijgt, en wat daar niet aan klopt.

Verder zit er ieder geval wel een probleem in je GROUP BY, want ik zie geen aggregate functions ( Hoe werkt GROUP BY nou eigenlijk? )

L4m0r schreef op maandag 17 augustus 2009 @ 14:20:
[...]
Dus jij gaat een tabel van 20000 regels inladen om 1 fotoalbum te laten zien via een search? Beetje vreemd om je webserver de load op zich te laten nemen ipv de databaseserver (die ervoor bedoeld is).

Nee, maar wel alle records ophalen die aan de criteria voldoen, whoami bedoelt waarschijnlijk dat het tonen van de link waarop geklikt word in PHP moet gebeuren. En was dus een reactie op:

Daarnaast moet de link ook aangepast worden zodat je erop klik, dat je direct de gevonden foto krijgt te zien.

[Mental]

Woy schreef op maandag 17 augustus 2009 @ 14:27:
Wat wil er precies niet lukken? Ik zie wel een query, maar ik zie het probleem bij je LIKE gedeelte niet. Je geeft ook niet aan welke resultaten je krijgt, en wat daar niet aan klopt.

Verder zit er ieder geval wel een probleem in je GROUP BY, want ik zie geen aggregate functions ( Hoe werkt GROUP BY nou eigenlijk? )


[...]

Nee, maar wel alle records ophalen die aan de criteria voldoen, whoami bedoelt waarschijnlijk dat het tonen van de link waarop geklikt word in PHP moet gebeuren. En was dus een reactie op:

[...]

Hence the striketrough
Anyway, van wat ik ervan begrijp werkt de query goed (hoewel ik hem een beetje typisch vind) maar wil de TS graag in de output vanaf de database een veldje waarin staat waar het zoekwoord gevonden is.
IMHO is dat bijzonder lastig voor elkaar te krijgen en sowieso nogal onzinnig aangezien je met die gegevens in je frontend toch nog meer gaat doen.

[Woy]

L4m0r schreef op maandag 17 augustus 2009 @ 14:30:
[...]
Hence the striketrough

offtopic:
Ja ik was weer eens te langzaam, op de pagina waar ik op het quote knopje drukte was het nog niet doorstreept , en heb het resultaat ook niet goed genoeg bekeken blijkbaar

[tss68nl]

Hoi Martin, erg veel verwarrende antwoorden hierboven, had geen zin om ze allemaal van voor tot achter door te lezen maar dit is wat ik ervan begrijp:

Je doel:
Je stelt een query op 4 tekstvelden, en als in 1 van die velden de zoekterm voorkomt, dan wil je de resultaten tonen. Echter, wil je wel zien in welk veld deze matches zijn gevonden.

Mijn gedachten/oplossingen:
1. Als je enkel hoeft te checken of de match in het titelveld voorkwam, of in een van de andere, dan volstaat het om een CASE statement op te bouwen in de select list van je originele query. Dit case statement check je nogmaals of je de zoekterm kan vinden in een bepaal je zodoende waar je match zat. Dit is niet zwaar voor de database aangezien je de select list pas doorgerekend wordt 'na' de join, en je zodoende enkel al gematchte rijen opnieuw hoeft te checken. Je kan voor ieder veld natuurlijk een case statement bouwen in een apart veld mocht dat wenselijk zijn, of 1 case statement met meerdere checks om een soort classificatie toe te passen. Matches in meerdere velden rapporteren dan enkel de eerste match.

2. Aparte queries opbouwen voor zoeken in ieder veld, om deze vervolgens aan elkaar te plakken met een union. Je hebt dan binnen iedere match-set de mogelijkheid om een kenmerk mee te geven in de select list. Dit is een minder elegante oplossing, en je komt in de problemen wanneer een match in meerdere velden wordt gevonden van 1 item. Deze wordt dan meerdere malen geretourneerd.

3. Anderen geven als oplossing om dit in je presentatielaag op te lossen, en ofschoon dat een mogelijke oplossing is, kunnen er ontwerp restricties zijn waardoor dit onwenselijk is. Bijvoorbeeld, als de keuze is gemaakt voor een thin-client, zonder teveel business logica, dan horen dit soort berekeningen in de query thuis. Daarnaast kan het zijn dat meerdere schermen of modules van de logica gebruik moeten maken, en door de classificatie in SQL vast te leggen veranderen de verschillende front-ends automatisch mee met nieuwe logica.

Succes met het vinden van een oplossing, ik denk dat je zelf wel uit het gebruik van het case statement weet te komen, zo niet, dan horen we hier weer van je

Overigens, is het zoeken in strings met '%<zoekterm>%' vaak erg langzaam. En je voert er hier meerdere uit. Je kan ook je string velden door de database achter elkaar laten plakken, om vervolgens 1x met '%<zoekterm>%' dit samengestelde veld te doorzoeken. Scheelt vaak een hoop rekenwerk voor je database!

[ Voor 6% gewijzigd door tss68nl op 17-08-2009 14:55 . Reden: ff wat vergeten :) ]

[Martine]

Die GROUP BY wordt gebruikt om te voorkomen dat het album meerdere keren getoond wordt. Als er nu in de album omschrijving een stukje over beren, beer in het bos.. bla bla staat en ergens in datzelfde album een item met als titel 'beer in het bos', dan wordt de album twee keer getoond in de zoekresultaten. Dat is niet de bedoeling, dan moet alleen het item getoond worden.

Nu roept iedereen hier wel van dat het zo simpel is om het af te vangen waar het gevonden is dmv van php, maar ik krijg altijd een item_id terug, omdat het ook mogelijk is dat het gewoon de eerste foto gevonden foto is omdat het zoekwoord in de album titel gevonden is.

//edit;
* Martin gaat aal de slag met de reactie van tss68nl, deze reactie heb ik gepost voordat ik zijn/haar reactie had gelezen..

[ Voor 9% gewijzigd door Martine op 17-08-2009 14:56 ]

[Mental]

Wat willen we:

Gevonden in m.title: Laatste foto van het album tonen (hoogste m.id van dat album waar de foto in gevonden is)
Gevonden in m.description: De gevonden foto zelf tonen. (dus het m.id van de gevonden foto)

Met cases heb ik niet ontzettend veel ervaring maar wat mijn voorganger zegt bied perspectieven. Kijk er eens naar zou ik zeggen en los het anders gewoon op met 2 queries.


edit: dit topic gaat te snel

[ Voor 6% gewijzigd door Mental op 17-08-2009 14:58 ]

[tss68nl]

Martin, die GROUP BY is overbodig. Het kan niet zorgen voor een dubbeling van je resultaten als je enkel filtert in de WHERE-sectie. Mocht je toch dubbele resultaten krijgen dan zou ik als ik jou was de vulling van je tabel maar eens gaan nakijken, want dan zitten daar dubbele records in!

[Woy]

Martine schreef op maandag 17 augustus 2009 @ 14:54:
Die GROUP BY wordt gebruikt om te voorkomen dat het album meerdere keren getoond wordt.

Dan moet je de link die ik een NMe aanhalen eens goed lezen. De manier waarop je GROUP BY gebruikt is fout!!!!

tss68nl schreef op maandag 17 augustus 2009 @ 14:50:
Overigens, is het zoeken in strings met '%<zoekterm>%' vaak erg langzaam. En je voert er hier meerdere uit. Je kan ook je string velden door de database achter elkaar laten plakken, om vervolgens 1x met '%<zoekterm>%' dit samengestelde veld te doorzoeken. Scheelt vaak een hoop rekenwerk voor je database!

Ik geloof niet dat dat sneller zal zijn. Of je nu 4 textvelden met een lengte van bijvoorbeeld 25 chars door moet zoeken, of eerst die 4 aan elkaar plakken en dan een textveld van 100 door moet zoeken.

Als performance een probleem is kun je beter eens op FULL TEXT INDEX kunnen zoeken.

[Martine]

tss68nl schreef op maandag 17 augustus 2009 @ 14:58:
Martin, die GROUP BY is overbodig. Het kan niet zorgen voor een dubbeling van je resultaten als je enkel filtert in de WHERE-sectie. Mocht je toch dubbele resultaten krijgen dan zou ik als ik jou was de vulling van je tabel maar eens gaan nakijken, want dan zitten daar dubbele records in!

Nee, zo bedoelde ik het niet. Als er gezocht wordt op 'beer' en dat zoekwoord wordt gevonden in zowel album.titel als items.description dan worden er twee resultaten getoond. Dat klopt ook wel, het zoekwoord wordt immers twee keer gevonden.
Echter wil ik graag dat het album maar een keer getoond wordt. tsja, of eerst het album en daaronder het gevonden item..
Meuh, volgens mij wil ik soms wat teveel Eerst dit maar eens even oplossen, mocht het niet slagen dan meldt ik mij weer.

^{Dit topic gaat bijna te snel, beter te snel als geen reacties}

[Mental]

Ik weet wel een oplossing maar weet bijna zeker dat er een betere is

WHERE
m.title LIKE '%beer%' and m.description NOT LIKE '%beer%'
OR m.description LIKE '%beer%' AND m.title NOT LIKE '%beer%'
OR m.description LIKE '%beer%' AND m.title LIKE '%beer%'

Hang me niet op aan de syntax maar het idee is dus om een handmatige XOR uit te voeren in je WHERE statement. (die laatste OR is om ervoor te zorgen dat regels waarr het in beide velden voorkomt niet te vergeten).

edit: en die laatste OR heft natuurlijk de XOR op Ik zeg tijd voor koffie.

[ Voor 26% gewijzigd door Mental op 17-08-2009 15:09 ]

[whoami]

Martine schreef op maandag 17 augustus 2009 @ 15:04:
[...]


Nee, zo bedoelde ik het niet. Als er gezocht wordt op 'beer' en dat zoekwoord wordt gevonden in zowel album.titel als items.description dan worden er twee resultaten getoond. Dat klopt ook wel, het zoekwoord wordt immers twee keer gevonden.
Echter wil ik graag dat het album maar een keer getoond wordt. tsja, of eerst het album en daaronder het gevonden item..
Meuh, volgens mij wil ik soms wat teveel Eerst dit maar eens even oplossen, mocht het niet slagen dan meldt ik mij weer.

^{Dit topic gaat bijna te snel, beter te snel als geen reacties}

Dan nog is die group by overbodig (en je gebruikt 'm trouwens verkeerd; al laat mySQL het op die manier wel toe).
DISTINCT is wat jij nodig hebt.

[whoami]

L4m0r schreef op maandag 17 augustus 2009 @ 15:07:
Ik weet wel een oplossing maar weet bijna zeker dat er een betere is


[...]


Hang me niet op aan de syntax maar het idee is dus om een handmatige XOR uit te voeren in je WHERE statement.

Lekker als je al die combinaties moet gaan schrijven ...
Als je in 3 velden wilt zoeken, zijn dit al 9 combinaties ... Dat gaat lekker snel gaan ...

[Martine]

Woy schreef op maandag 17 augustus 2009 @ 15:04:
[...]

Dan moet je de link die ik een NMe aanhalen eens goed lezen. De manier waarop je GROUP BY gebruikt is fout!!!!

Ai, ja nu begrijp ik wat er mis gaat. Dit had ik eerst inderaad ook anders en pakte hij altijd het hoogste id van items, dit heb ik er later weer uitgemikt...

Maar ik zal nu echt even aan slag, want anders komt er helemaal geen goede query meer op het scherm en werkt de zoekfunctie nog steeds niet. Natuurlijk zijn alle tips tussendoor welkom!

[Mental]

Mwoah, zal wel meevallen hoor, ik denk dat de database sneller is met 100 keer die query uitvoeren dan jij het 1 keer moet typen
Het hele XOR idee moet je vanzelfsprekend lekker vergeten en gewoon DISTINCT voor je m.id zetten
(Waarom je uberhaubt een inner left join doet is me ook nog steeds niet duidelijk)

[tss68nl]

Woy schreef op maandag 17 augustus 2009 @ 15:04:
Ik geloof niet dat dat sneller zal zijn. Of je nu 4 textvelden met een lengte van bijvoorbeeld 25 chars door moet zoeken, of eerst die 4 aan elkaar plakken en dan een textveld van 100 door moet zoeken.

Nuja, ik heb geen testresultaten met MySQL aangezien ik eigenlijk uitsluitend nog met Microsoft SQL en Oracle werk, maar in SQL Server geeft dit een flinke performance boost van je query bij ongeindexeerde kolommen (wat tekstvelden in veel databases zijn). Het is het proberen waard, aangezien het enkel de tijd van een aantal plusjes tikken kost

[Voutloos]

L4m0r schreef op maandag 17 augustus 2009 @ 15:12:
(Waarom je uberhaubt een inner join doet is me ook nog steeds niet duidelijk)

In een album zitten 1 of meerdere items blijkbaar. Niet zo heel erg gek toch?

[whoami]

tss68nl schreef op maandag 17 augustus 2009 @ 15:12:
[...]


Nuja, ik heb geen testresultaten met MySQL aangezien ik eigenlijk uitsluitend nog met Microsoft SQL en Oracle werk, maar in SQL Server geeft dit een flinke performance boost van je query bij ongeindexeerde kolommen (wat tekstvelden in veel databases zijn). Het is het proberen waard, aangezien het enkel de tijd van een aantal plusjes tikken kost

Zowiezo kan er bij een LIKE '%melp%' zoekopdracht (waarbij je dus begint met een wildcard), geen indexen gebruikt worden.
Ik kan best geloven dat dit een performance boost geeft, en vind het zelf wel het proberen waard. (Zowiezo vind ik dit een betere oplossing dan die tip ivm het handmatig XOR'en, wat gewoon een onderhouds-hel wordt.

[NMe]

L4m0r schreef op maandag 17 augustus 2009 @ 15:12:
Mwoah, zal wel meevallen hoor, ik denk dat de database sneller is met 100 keer die query uitvoeren dan jij het 1 keer moet typen
Het hele XOR idee moet je vanzelfsprekend lekker vergeten en gewoon DISTINCT voor je m.id zetten
(Waarom je uberhaubt een inner join doet is me ook nog steeds niet duidelijk)

Ik zie geen inner join? Alleen een (left) outer die ervoor zorgt dat ook lege albums doorzocht worden.

En met of zonder distinct maakt geen fluit uit, je krijgt gegarandeerd een record per gematcht item terug, of dat item nu daadwerkelijk zelf gematcht heeft of dat er op het album gematcht is maakt daarbij niet uit. Die group by moet in elk geval weg, ofwel volledig uitgeschreven worden (waardoor hij overbodig wordt zonder aggregate function). Group by is in elk geval niet bedoeld waarvoor de topicstarter het hier wil gebruiken.

[Mental]

Voutloos schreef op maandag 17 augustus 2009 @ 15:19:
[...]
In een album zitten 1 of meerdere items blijkbaar. Niet zo heel erg gek toch?

Als je 1 keer fotoablums en 1 keer items leest wel ja
Iemand anders nog koffie? Ik heb het blijkbaar hard nodig.

[Martine]

NMe schreef op maandag 17 augustus 2009 @ 15:21:
[...]

Ik zie geen inner join? Alleen een (left) outer die ervoor zorgt dat ook lege albums doorzocht worden.

De gebruiker kan de laatste foto nooit uit zijn album verwijderen, dan krijgt hij een melding dat het hele album verwijderd wordt. Anders stikt het straks van de lege albums, daar heeft niemand wat aan.

[FragFrog]

tss68nl schreef op maandag 17 augustus 2009 @ 15:12:
Nuja, ik heb geen testresultaten met MySQL aangezien ik eigenlijk uitsluitend nog met Microsoft SQL en Oracle werk, maar in SQL Server geeft dit een flinke performance boost van je query bij ongeindexeerde kolommen (wat tekstvelden in veel databases zijn). Het is het proberen waard, aangezien het enkel de tijd van een aantal plusjes tikken kost

Micro-optimalisatie's..

Bij tekst doorzoeken in MySQL moet je gewoon MATCH(..) AGAINST gebruiken op een column met fulltext index, geen LIKE. Als er iets verschrikkelijk traag is dan is LIKE het wel.

* FragFrog heeft zo eens een query van een collega herschreven die van ~45 seconden naar 0.02 seconden ging

[tss68nl]

Ok, ik snap nu wat hij wil bereiken met die group by, alleen legt ie het wat ongelukkig uit, en zitten we allemaal langs mekaar heen te lullen

Je zegt, als er in de album omschrijving, en in de artikel omschrijving beide een match wordt gevonden, dan krijg ik dubbelen, en daarom heb ik een group by nodig. Dat is pertinent onwaar, aangezien je de items matcht aan het album waar ze bij horen. Wordt er een match gevonden in beide omschrijvingen, dan zal dat nog steeds maar 1 resultaatregel opleveren.

Wel, heb je een probleem als meerdere items een match hebben op hetzelfde album wat zelf ook een match heeft. In dit geval wil je enkel het album tonen, maar zorgen de item matches dat je toch meerdere resultaatrijen hebt.

Dan rijst de vraag, wat wil je doen als je album geen match heeft, maar 3 fotos uit dat album van 20 wel? Wil je dan de afzonderlijke fotos tonen, of het hele album? In je huidige situatie gooi je 2 foto matches weg en toon je 1 foto naar wat ik begrijp....oeps

[Woy]

tss68nl schreef op maandag 17 augustus 2009 @ 15:12:
[...]
Nuja, ik heb geen testresultaten met MySQL aangezien ik eigenlijk uitsluitend nog met Microsoft SQL en Oracle werk, maar in SQL Server geeft dit een flinke performance boost van je query bij ongeindexeerde kolommen (wat tekstvelden in veel databases zijn). Het is het proberen waard, aangezien het enkel de tijd van een aantal plusjes tikken kost

Ik zal het binnenkort eens proberen op MS Sql Server, maar het zou mij toch vebazen als het daadwerkelijk een flinke performance boost zou opleveren. Ik kan me voorstellen dat er in een langere text iets beter gezocht kan worden, maar aangezien er toch al een full-table scan gedaan moet worden lijkt het verschil me minimaal. Of heb je hier een goede verklaring voor?

Overigens moet je ook oppassen dat het verkeerde resultaten op kan leveren.
( "BLAA" + "PAADF" + "DFSF" ) en dan op "AAP" zoeken zal immers ook een hit opleveren. Met een goed gekozen separator die niet in je zoekstring voor kan komen los je dat natuurlijk weer op.

[ Voor 18% gewijzigd door Woy op 17-08-2009 15:33 ]

[NMe]

Martine schreef op maandag 17 augustus 2009 @ 15:25:
[...]

De gebruiker kan de laatste foto nooit uit zijn album verwijderen, dan krijgt hij een melding dat het hele album verwijderd wordt. Anders stikt het straks van de lege albums, daar heeft niemand wat aan.

Waarom gebruik je dan een left join en geen inner join? Als er geen album kan bestaan zonder items dan kun je gewoon een inner join gebruiken?

[Voutloos]

Inner join ipv left join is wellicht logischer, maar de rest begint weer klassiek-GoT-style over optimalisaties terwijl niemand beweert heeft dat er een serieus performance probleem is.

[tss68nl]

Woy schreef op maandag 17 augustus 2009 @ 15:27:
[...]

Ik zal het binnenkort eens proberen op MS Sql Server, maar het zou mij toch vebazen als het daadwerkelijk een flinke performance boost zou opleveren. Ik kan me voorstellen dat er in een langere text iets beter gezocht kan worden, maar aangezien er toch al een full-table scan gedaan moet worden lijkt het verschil me minimaal. Of heb je hier een goede verklaring voor?

Overigens moet je ook oppassen dat het verkeerde resultaten op kan leveren.
( "BLAA" + "PAADF" + "DFSF" ) en dan op "AAP" zoeken zal immers ook een hit opleveren. Met een goed gekozen separator die niet in je zoekstring voor kan komen los je dat natuurlijk weer op.

Je hebt helemaal gelijk met de valse resultaten. De kans daarop is echter redelijk klein, en het ligt aan de toepassing of dit resultaat toelaatbaar is natuurlijk. (Als je het gebruikt om een pickorder list van een bestelling mee samen te stellen is het een afrader, maar een zoekfunctie moet kunnen )

De snelheidswinst is te verklaren door een intern mechanisme waarbij strings worden gemapped naar een bitmap van de codetabel (varchar en char zijn dus sneller dan nvarchar nchar bij deze operatie), en deze codetabellen kunnen dan eenvoudig worden opgeteld in het geheugen voor aanwezigheid van bepaalde karakters. Het optellen gebeurt bij het aan elkaar plakken van de strings, waarna de zoekfunctie kijkt welke letters er minimaal aanwezig moeten zijn, en deze matcht met de bitmaps van iedere rij. Dat filtert al zoveel kolommen uit, dat de werkelijke scan van het tekstveld op inhoud en volgorde veel minder iteraties kent. Je kan dit gedrag zien als je het query plan opvraagt van dergelijke queries.

[ Voor 0% gewijzigd door tss68nl op 17-08-2009 15:42 . Reden: Spelvaut ;) ]

[Martine]

Voutloos schreef op maandag 17 augustus 2009 @ 15:38:
Inner join ipv left join is wellicht logischer, maar de rest begint weer klassiek-GoT-style over optimalisaties terwijl niemand beweert heeft dat er een serieus performance probleem is.

Dat is inderdaad beter om te gebruiken, maar maakt dat veel uit? Er zijn immers toch geen albums zonder items.

Volgens mij is dat programmeurs eigen om het hele zwikje zo optimaal mogelijk te maken en daarnaast met zo weinig mogelijk code te werken.

whoami schreef op maandag 17 augustus 2009 @ 15:08:
[...]
DISTINCT is wat jij nodig hebt.

DISTINCT gaat niet werken want er zijn verschillende foto's (die concat bla bla as img) die we terug krijgen.

[ Voor 19% gewijzigd door Martine op 17-08-2009 15:47 ]

[IntToStr]

Martine schreef op maandag 17 augustus 2009 @ 15:44:
[...]


DISTINCT gaat niet werken want er zijn verschillende foto's (die concat bla bla as img) die we terug krijgen.

Je zegt dat je unieke album ids terug wilt als ik me niet vergis. Waarom wil je dan eigenlijk nog foto-informatie teruggeven in je query resultaat? Als het je puur om het album gaat (waar je waarschijnlijk een link naar wilt geven) heb je dus voldoende aan albuminfo. In dat geval werkt distinct wel. Als je wel iets met de foto's wilt (waarvan er dus meer per album een resultaat kunnen geven), wil je blijkbaar geen unieke albums in je resultaat.

Wat wil je als resultaat hebben?

[NMe]

Martine schreef op maandag 17 augustus 2009 @ 15:44:
[...]

DISTINCT gaat niet werken want er zijn verschillende foto's (die concat bla bla as img) die we terug krijgen.

Dat zeg ik even hierboven ook al; je zal dit gewoon in je code moeten/willen doen.

[Martine]

IntToStr schreef op maandag 17 augustus 2009 @ 16:05:
[...]

Je zegt dat je unieke album ids terug wilt als ik me niet vergis. Waarom wil je dan eigenlijk nog foto-informatie teruggeven in je query resultaat? Als het je puur om het album gaat (waar je waarschijnlijk een link naar wilt geven) heb je dus voldoende aan albuminfo. In dat geval werkt distinct wel. Als je wel iets met de foto's wilt (waarvan er dus meer per album een resultaat kunnen geven), wil je blijkbaar geen unieke albums in je resultaat.

Wat wil je als resultaat hebben?

Die img moet ook mee om een thumbnail naast de album titel te tonen.

NMe schreef op maandag 17 augustus 2009 @ 16:07:
[...]

Dat zeg ik even hierboven ook al; je zal dit gewoon in je code moeten/willen doen.

Jup, ik kom steeds meer tot de ontdekking dat hier meer code voor nodig is

[NMe]

Martine schreef op maandag 17 augustus 2009 @ 16:10:
[...]

Die img moet ook mee om een thumbnail naast de album titel te tonen.

Heb je daar ook echt alle gematchte images bij nodig? Zo niet, dan zou je alsnog apart de image kunnen matchen in een subquery met een LIMIT 1 erbij.

[tss68nl]

Martine schreef op maandag 17 augustus 2009 @ 16:10:
[...]
Jup, ik kom steeds meer tot de ontdekking dat hier meer code voor nodig is

Vergis je niet hoe krachtig SQL is. Als je goed weet wat je wil (zie mijn post halverwege deze pagina omhoog, daar heb ik nog geen antwoord op gezien) dan is het met een doordacht query ontwerp zo uit SQL te toveren. Maar we kunnen moeilijk voor jou gaan bedenken hoe je zoekfunctie moet gaan werken