Keskustelu: Nettisivujen teko: MySQL; LIKE kirjainkoosta riippumattomaksi

Onnistuu miten?

Sen pitäisi olla oletuksena kirjainkoosta riippumaton. Vai onko sinulla ongelmia erikoismerkkien kuten ääkkösten kanssa? Käytätkö UTF-8:aa?

http://jjp.jouluserver.com/lataushaku.php?hakusana=Quick
...yksi hakutulos, mutta...
http://jjp.jouluserver.com/lataushaku.php?hakusana=quick
...ei hakutuloksia.

Käytän UTF-8:aa.

Millaisella kutsulla valitset viestit?

Tässä on yksi vaihtoehto LIKElle:

$phrase = mysql_real_escape_string($phrase);

$sql = "SELECT post_id FROM posts_table
WHERE MATCH (post_subject, post_text)
AGAINST('$phrase' IN BOOLEAN MODE)
LIMIT 10";

Auttaisiko muuttaa merkkijonojen merkit pieniksi?

SELECT * FROM taulu WHERE LOWER(teksti) LIKE LOWER('AbC%')

Olet ilmeisesti määrittänyt taulun collationiksi jotakin_bin. Tässä infoa. Vaihda kentän collation haluamaksesi ja sitten toimii.

Hakukysely: SELECT name, LEFT(content,300), id, url, image, imagelarge FROM downloads WHERE name LIKE '%$hakusanasql%' OR content LIKE '%$hakusanasql%' LIMIT 15

Merkkijonojen pieneksi muuttaminen ei auttanut, ja Merrin ensimmäisellä esimerkillä ei löytynyt yhtään hakutulosta, vaikka nimet olisi kirjoitettu oikein. Sen sijaan huomasin, että esim. http://jjp.jouluserver.com/lataushaku.php?hakusana=lAbYlAnD löytää kyllä LabyLand-pelin... mutta miksi tuo Quick-sana sitten ei löydy?

Vaikuttaa siltä, että kentässä "name" kirjainkoolla ei ole merkitystä mutta kentässä "content" sillä on merkitystä. Mikä on kentän "content" tyyppi? Sopiva tyyppi kentälle voisi olla TEXT.

Vika on varmasti kentän tyypissä tai tuossa collationissa, kuten Merri arvelee. Ilmeisesti name-kenttä toimii oikein mutta content-kenttä väärin, joten katso, mitä eroa niillä on.

Alla toimiva esimerkki:
Eli huomaa sulut ja lainausmerkit.

$hakeesanat = $_GET['hakeesanat'];
$nouto = "SELECT * FROM juomat WHERE (Nimi LIKE '%$hakeesanat%' OR Valmistaja LIKE '%$hakeesanat%' OR Valmistusmaa LIKE '%$hakeesanat%' OR Alue LIKE '%$hakeesanat%' OR Tyyppi LIKE '%$hakeesanat%' OR Vuosikerta LIKE '%$hakeesanat%' OR Luonnehdinta LIKE '%$hakeesanat%')
 ORDER BY Valmistusmaa DESC LIMIT 0, 900 ";

Vaihdoin content:in tyypin mediumblobista TEXTiksi, jolloin se toimii, mutta joissain paikoissa tarvitsen noita blobbeja, eli miten tämä toteutettaisiin niiden kannalta?

Missä tilanteissa tarvitset BLOB-kenttiä?

Viesteissä olen käyttänyt.

edit: Ja profiilikentissä

Voisitko käyttää niissäkin TEXT-kenttiä?

Juhko kirjoitti:

Viesteissä olen käyttänyt.

edit: Ja profiilikentissä

http://dev.mysql.com/doc/refman/5.0/en/blob.html:

BLOB values are treated as binary strings (byte strings). They have no character set, and sorting and comparison are based on the numeric values of the bytes in column values. TEXT values are treated as nonbinary strings (character strings). They have a character set, and values are sorted and compared based on the collation of the character set.

Mikä on TEXTin pituusrajoitus?

https://www.ohjelmointiputka.net/oppaat/opas.php?tunnus=mysqlphp07:

Merkkijonotyyppi TEXT voi sisältää 65535 merkkiä. Jos tämä ei riitä, voi käyttää tyyppejä MEDIUMTEXT ja LONGTEXT, jotka voivat sisältää vastaavasti 16777215 (yli 16 miljoonaa) ja 4294967295 (yli 4 miljardia) merkkiä.

Ok, muutan ne MEDIUMTEXTeiksi. Olin lukenut mediawikin tietokantoja ja siellä oli tallennettu nuo blobbeihin, joten otin mallia. -.-

Foorumeilla yleensä tekstien pituudella taitaa olla rajoituksia, esim. 10000 merkin viesti on jo suht pitkä, mutta voi loppua kesken joidenkin koodilistausten kanssa. 65535 on kyllä aika riittävä merkkimäärä yhdelle viestille.

Samaan aiheeseen liittyen, minkä ihmeen takia http://jjp.jouluserver.com/keskustelu/search.php?query=a löytää käyttäjätunnukset "Plööö" ja "Kyrpäjyrä"? Kysely:

SELECT userid, username FROM users WHERE username LIKE '%$query%' ORDER BY username LIMIT 50

Oletko tietokantayhteyden muodostamisen jälkeen lähettänyt kutsua 'SET NAMES utf8' tai käyttänyt funktiota mysql_set_charset('utf8');? Mikäli et ole, ja tietokanta on oletuksena säädetty latin1:lle (hyvin todennäköistä), niin MySQL on enkoodannut UTF-8:n toistamiseen UTF-8:lla tietokantaan... ja tämä sitten tietysti aiheuttaa häikkää.

Kiitos.