syntax mysqli query
In de variabele var1 staat “ABCD”
Onderstaande query moet foto’s laten zien als een van de waarden uit var1 voorkomt in veld groep_id.
Ik ben dus op zoek naar de juiste syntax in regel 3 van de query
$query_rs_foto = "SELECT * FROM foto ";
$query_rs_foto .= "WHERE ocatID='$ocatID' ";
//$query_rs_foto .= "AND groep_id LIKE $var1 ;” ;
$query_rs_foto .= "AND sub_ocatID='$sub_ocatID' ";
$query_rs_foto .= "ORDER BY foto_volgorde DESC ";
$rs_foto= mysqli_query($verbinding,$query_rs_foto) or die(mysqli_error());
$row_rs_foto = mysqli_fetch_assoc($rs_foto);
$totalRows_rs_foto = mysqli_num_rows($rs_foto);
En goede gratis tip: echo ter debugging en testen eens $query_rs_foto voor je de query uitvoert. Dan zie je jouw volledige query.
Oh ja, je voert die regel nu niet uit, maar dat wist je vast al ;-)
Gewijzigd op 21/04/2019 22:31:08 door - Ariën -
Dat werkt dus wel maar zodra in var1 AC staat krijg ik geen resultaat meer. Ik zou dus graag zien dat bij AC kuist allebei de foto's worden getoond.
Het zijn dus twee typen foto's die gegroepeerd zijn in reeks A OF reeks C?
Splits $var1 in losse karakters, en doe dan per karakter een LIKE (samenvoegen via OR)
Een LIKE zonder wildcards (een underscore (_) voor een enkel karakter, een procentteken (%) voor nul of meerdere karakters) levert je ook niet zoveel op, want dan zouden het exacte matches moeten zijn. Meestal doe je zoiets als ... LIKE '%<frase>%' ... waarbij <frase> het ding is waarmee je vergelijkt.
Maar in dit geval (groepen (categorieën?) waartoe een foto zou moeten behoren) snijdt dat niet zoveel hout.
Simpel gedacht wilde ik bereiken als in de databaseveld groep_id een waarde voorkomt die ook in var1 staat dan True anders False.
Splits $var1 in losse karakters, en doe dan per karakter een LIKE (samenvoegen via OR)
Perfecte oplossing Rob. Het werkt, bedankt allen voor de support!
Simpelweg omdat iets werkt, maakt het nog niet juist.
Een oplossing met LIKE, hoe elegant de bovenstaande ook is, lijkt mij niet de juiste aanpak voor het bovenstaande vraagstuk.
Dit schreeuwt om een fotogroep-koppeltabel.
Wat je nu aan het doen bent is op een ingewikkelde (of "makkelijke", net hoe je het bekijkt he :)) manier coderen tot welke groep(en) een foto behoort, en vervolgens moet je je in allerlei bochten wringen om deze data weer uit de database te peuteren.
Dit soort coderingen zijn wellicht soms geoorloofd, maar niet in dit geval lijkt mij.
Merk ook op dat deze aanpak je query sterk kleurt (om het nog niet eens over de extra complexiteit of efficiëntie te hebben!), deze structuur bepaalt in sterke mate hoe de query er uit ziet. Dit is een signaal dat de databasestructuur niet zodanig is dat het makkelijk is om data weer uit de database te halen. Dit laatste zou altijd een streven moeten zijn: databases zijn bedoeld om data gestructureerd (en niet zozeer gecodeerd :p) op te slaan.
Eerlijk gezegd zou ik die extra mijl nemen en een extra tabelletje aanmaken. Wat je hierboven aan het doen bent is toch een beetje voortborduren op een verkeerde oplossing.
Ook wil je foto's straks anders gaan gebruiken waarbij het belangrijker wordt tot welke groepen deze behoren. Kun je met de huidige aanpak garanderen dat je dan niet hopeloos in de problemen komt?
Met deze oplossing schuif je dus ook potentieel werk voor je uit. Dit is na verloop van tijd mogelijk steeds lastiger aan te passen dus het nemen van deze "shortcut" leek nu wel slim maar die bijt jou later hoogstwaarschijnlijk in je broek.
Ook zou je een beetje vanuit een ander kunnen redeneren (karma?). Als iemand anders deze code van jou onder handen zou moet nemen, of als jij dit soort code van iemand anders op je bord krijgt, wat zou die persoon of jij daar van vinden? De eerste vraag is dan waarschijnlijk ook "waarom heeft deze gozer niet gewoon een koppeltabel gemaakt?".
Gewijzigd op 22/04/2019 15:10:29 door Thomas van den Heuvel
Gewijzigd op 22/04/2019 16:23:15 door Thomas van den Heuvel
Op zich kan een letter een prima ID zijn, en je kunt ze ook prima indexeren. Ivm afhankelijkheden verderop in de keten heb ik nog wel eens van doen met een base-36 ID (0..9 + A..Z, met voorloopnullen), werkt prima. Daarnaast ken ik ID's die toch niet "zomaar" ontstaan (dus geen artikelnummer ofzo - wat gewoon een volgnummer is dat de klant zelf "aan maakt", maar ID's die vaak een 1:1 relatie met een stukje code hebben - en dus ook eerst in code gedefinieerd moeten worden) gewoon een karakter of een (korte) string toe (echt als primary key). Voordeel is dat je in gekoppelde tabellen dan ook direct die letter of string terug ziet, en je bij het "data graven" (nav een probleem ofzo) niet steeds uit hoeft te vogelen wat ID = 35 ook alweer was (maar dat is dan gewoon "x" = status ID voor categorie "extra" - of zoiets).
Gewijzigd op 22/04/2019 21:34:33 door Thomas van den Heuvel