A következő problémába futottam bele! Van egy adatbázisom, amelyben felhasználó neveket, és jelszavakat tárolok! Van még egy oldalam, ahol a felhasználók bejelentkezhetnek, meg egy script, ami a bejelentkezés gombra kattintva annyit csinál, hogy a bejelntkező űrlapról vett adatokkal egy keresést futtat le az adatbázison, egyezést keresve! Ha talál, akkor megjelenít bizonyos adatokat. Szóval ennyi a működés, de a problémám az vele, hogy ékezetes karaktereket használva, nem talál egyezést, pedig az adatok ott vannak az adatbázisban! Az adatbázis utf8 kódolású! Mi lehet a gond? A script egyébként nem ékezetes karakterekkel tökéletesen működik!
Például azt az apróságot nem mondtam neki, hogy szervert vagy klienst fordítson-e... valamit csinál, az a lényeg... különben is, nem akarom én használni, csak úgy próbából elküldtem a fordítást, hadd szórakoztassa vele magát a gépem...
Gondoltam, próbálkozik, nem sikerül, nyom egy felnyilat, módosít, enter, s így tovább. És mondjuk még ezen a héten sikerül. Ha jövő karácsonykor folytatja, valóban szerencsésebb egy picike scriptet írni.
Amíg az ember naív és fiatal, addig reméli, hogy a history eligazítja az évekkel ezelőtti fordítási opciókat illetően;)
Egyébként kimaradt egy egyenlőségjel is belőle --with-charset=
További egyébként itt halt meg a fordítás:
libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../../include -I../../include -I../../include -I../../regex -I./include -I../../sql -I. -DMYSQL_DYNAMIC_PLUGIN -O3 -DUNIV_LINUX -DUNIV_LINUX -MT ha_innodb_plugin_la-page0zip.lo -MD -MP -MF .deps/ha_innodb_plugin_la-page0zip.Tpo -c page/page0zip.c -o .libs/ha_innodb_plugin_la-page0zip.o page/page0zip.c: In function `page_zip_decompress': page/page0zip.c:2928: error: `Z_BLOCK' undeclared (first use in this function) page/page0zip.c:2928: error: (Each undeclared identifier is reported only once page/page0zip.c:2928: error: for each function it appears in.)
esetleg a latin2 és az utf8 fordított helyzetben, mindenesetre érdemes mindezt egy saját kis fájlba tenni, hiszen nyilván sokadszorra találjuk majd el az igazi opciókat, pl.:
sikerült már esetleg valakinek forráskódból MySQL-t telepíteni Ubuntu-ra? Ha esetleg egy használható útmutató oldalra mutató linketek van, azt is szívesen venném. Köszönöm.
minek vennel fel uj mezot hozza? ha like-osan keresel %szoveg% formaval akkor mar teljesen mind1, hogy kozbe lower-re alakitja-e az adott szoveget keresesnel vagy sem. Esetleg hasznalj full text search-ot, ha myisam tablakat hasznalsz ezen adatokhoz, gyorsabb is lesz a keresesed.
Hümm. Csak átfutottam, mert kissé magas ez nekem, mint ló a nyúlnak.
Sokat reszeltem a karakterkódolás-problémán, mert az adatok Win98 alatt futó Access alkalmazásból jönnek, a weblapon keletkező adatok UTF8_bin-ben tárolódnak, a HTML anyagok viszont ANSI kódolásúak voltak. Mostanra minden szép és jó és lépesméz, az adatok helyesen megjelenítve futnak az Access-PHP-MySQL-Firefox tengelyen, nincsenek kérdőjelek meg kalapos betűk. De lekérdezéskor megjelennek a találati listán az ékeztes (vagy épp ékezettelen) találatok is, lásd a "szék" keresésére érkező "székely" és "szekér" példát. Még nem próbáltam Ó és Ú betűs keresést, de ha arra is találatnak vesz minden o, ó, ö, ő és minden u, ú, ü, ű betűs rekordot, akkor a hajamra kenhetem a keresőmet.
zizi ajánlásával :) kérdezek a T. Egybegyűltektől: hogy lehet MySQL-ben pontosan kezelni az ékezetes betűket? Hogy lehet megoldani, hogy ha a keresésem ... LIKE '%szék%', és a találatok között ott van a "szövőszék" és a "székely", ne legyen ott a "Szekszárd" és a "Mély szekérút" is? Mer' most ott vannak... (művészeti adatbázis)
"Es persze ismet hozzateszem - ebben a topicban nagon halkan - , hogy ezert szeretem en nagyon a PostgreSQL-t, mert ott alapbol van tomb tipusu mezo, es PL/PgSQL-ben csodasan lehet is vele dolgozni. Ott altalaban ezt hasznalom a cimkezesre."
a mostani cimkes kerdesben pont rossz pelda a tomb a pg-be, mert nem igazan erre valo :) Any-vel matcheltetni performancia killer, ha esetleg tudnal GIN index-et hasznalni jo lenne, de nem igazan lehet erre. Se nem int tombod nincs, se nem kulcs,ertek parjaid hstore-hez. Raadasul egy gyakran updatelt tablara nem jo dolog gin indexet rakni.
Szoval jo dolog az teny, de ha olyan kell, hogy mely kepek vannak a leggyakoribb cimkekkel, vagy csak siman melyek a leggyakoribb cimkek, maris nem alkalmas a kerdesre. (szimplan mivel nem arra talaltak ki, hogy a kapcsolotablakat helyettesitse)
Itt pl van egy ottletes felhasznalasa: http://geekblog.over-blog.com/article-24266883.html
"En nem emlekszem arra, hogy kovetelmeny lett volna, hogy egy mezoben csak egy cimke szerepeljen." Nem kell emlékezni, ott van a 1744. hozzászólás 3. bekezdésében.
"A masik, hogy egy adatmodell attol meg nem hibas, hogy egy bizonyos adatra nem indexelheto" Ezzel egyetértek és ilyent nem is írtam (ott egy felsorolás van, ami egy általad nem szeretett 1:N kapcsolatot jelent a lista fölötti mondattal - valami ilyesmi a lista definíciója, de semmiképpen sem az, hogy a 3. pont az 1. következménye). Az adatmodell attól hibás, hogy 1:N (1 kép - bármennyi cimke) kapcsolatot tárolsz 1:1 kapcsolatként (1 kép - 1 valami, ami nem cimke).
"Ugyanis ha az elsodleges szerepe a cimkeknek az, hogy egy tartalomtipus alatt szepen megjelenitsek oket (jellemzoen pl. a flickr ilyen)" Amiről írsz nem cimke, hanem a kép leírása, és az valóban 1:1 kapcsolatban van a képpel, ezért valóban a képek táblában a helye. A cimkék elsődleges szerepe a keresés segítése. Egy elemhez (pl. képhez) jellemzően több cimke is tartozik, ezért 1:n kapcsolatról beszélünk. A korábban használt kategóriákat váltották ki a cimkékkel, ugyanis a kategóriák túl merevek voltak (nem konkrétan a Flickr, úgy általában). Nem sok értelme van a cimkéknek ha nem használják őket keresésre. A Flickr-en is ez a céljuk, és ugye nem gondolod, hogy pl. a budapest lekérdezés table scant csinál több millió soron mert nincs index? Az pedig már abszurdum, hogy közben még soronként csinálna egy nagyon költséges stringműveletet is vagy like-ot. Egy Flickr méretű adatbázisban valószinűleg 3 táblában tárolják a képeket és a cimkéket: képek, cimkék, és képek_cimkéi (kapcsolótábla). Magam ismétlem: ennek az az előnye, hogy egy cimke csak egyszer szerepel a rendszerben, azaz kisebb a cimkék tábla mérete, a kapcsolótábla viszont csak numerikus mezőkből áll, melyek kezelése nagyon olcsó. Lásd még (1). Ugye azt sem gondolod komolyan, hogy minden lekérdezéskor lefut egy split és ez olcsóbb mint a join?
"mert egy ujabb tabla joinolasa a lekerdezesbe tul sok eroforrast pazarol el a hasznossagahoz kepest, foleg ha 10000-es nagysagrend fole emelkedik mondjuk a tartalomelemek vgy a cimkek szama." Tízezres nagyságrendű sor még a Paradoxnak sem okozott gondot, nemhogy a MySQL-nek vagy más mai SQL szervernek. A join költsége kicsi a stringműveletekhez és table scanhez képest, ezt általában ki lehet jelenteni a mai SQL szerverekről - természetesen ha van index a joinban szereplő mezőkön és a join feltétel olyan, hogy az index használható is (ha nem olyan akkor javítani kell az adatmodellen).
"Nem ismerem pontosan a MySQL motorjat ilyen szempontbol, de az szinte biztos, hogy egy barmilyen join az ON feltetel miatt igenyel egy plusz szekvencialis keresest egy tablan." Tudom, hogy a MySQL nem a legjobb SQL szerver, de azért kételkedem abban, hogy nem használja az indexeket. Én bízom benne, hogy csak egy index scan kell a joinhoz, és ez lényegesen olcsóbb, mint a split vagy a like.
"De ezt minden esetben a felhasznalas jellege donti el." Ez így tökéletesen igaz, DE a cimkék jellemzően olyan adatok, melyre keresni szoktak, sőt, a cimkék létezésének egyetlen célja a keresés, mert sokkal könnyebben kezelhetők mint a kategóriák és olcsóbban előállíthatók mint egy full text index.
Az a "cimke" amiben nem keresnek a kép cime vagy leírása (kedvenc példádban, Flickr-ben: Title - a kép címe, Description - a kép leírása, Tags - cimkék, és hidd el, hogy a cimkék nem egy újab mező a képek táblában a Flickr-nél sem). Persze kereshetnének a címben is, de az sokkal költségesebb mint a cimkék használata.
"megintcsak erosen felhasznalasfuggo" Nem. Ha cimkéK (fontos a végén a K betű), akkor több cimke van egy képhez, tehát 1:N. Ha cimke (nincs K betű a végén) akkor egy cimke van egy képhez, tehát 1:1, ezesetben pedig már nem cimke, hanem cím vagy leírás, csak te valamilyen okból másképpen nevezed (ennyi erővel pista is lehetne a neve).
Maradjunk a továbbiakban a cimkék klasszikus értelmezésénél, azaz 1 elemhez több cimke tartozhat (1:N kapcsolat), és a cimkék célja a keresés.
"A vilagon mindenhol van escape-elendo elvalaszto karakter, mar csak a bevitel miatt is. Kulonben egy php-ben vagy akarmi masban megirt parser honnan tudna, hogy egy formbol erkezo "anya, apa, csirke" harmasbol az "anya, apa" egy cimkenek szamit vagy kettonek? Vagyis ezt a problemat semmikepp sem tudod megkerulni." Meg tudnám kerülni, de sajnos már megelőztek: 1 beviteli mező - 1 cimke. A Flickr spórol, náluk egy mezőben lehet felvinni az összes cimkét, de sem elméleti sem gyakorlati akadálya nincs a több mezős bevitelnek. Van éles, nyilvános rendszer is, ahol 1 beviteli mezőben 1 cimkét rögzítesz, pl. Yahoo! Bookmarks.
"de az egyszeru tartalommegjelenites cimkestul meg sokkal egyszerubb es gyorsabb" Az egyszerűbbet nem nagyon tudom értelmezni, mert a megjelenítést nem befolyásolja a tárolás módja. A gyorsabbat pedig bízzuk az adatbázismotorra, én bízom bennük :-)
"normalformara hozod-e a tablat" Nemrég írtam már nem tudom melyik topikban, hogy a normálforma nem cél, hanem eszköz, vagyis ebben egyetértünk.
"Mivel az eredeti kerdes arra vonatkozott, hogy egy cimkezohoz altalaban milyen struktura szukseges" Az egyetlen gond az, hogy te nagyon egyedien értelmezed a cimkézést, azaz nem több cimkének tekinted a képhez tartozó cimkéket, hanem egy szövegnek. (1) A Flickr-en sem szöveg a képhez tartozó cimkék halmaza, hanem N db. cimke, külön sorban megjelenítve, tehát fel sem merül az igény arra, hogy egy mezőben, szövegként legyen tárolva, hiszen egy ilyen tárolásnál nemcsak a keresések, hanem a megjelenítés is lényegesen lassúbb lenne a minden képnél szükséges split miatt.
"en batorkodtam a legegyszerubb megoldasbol kiindulni" Mivel te szövegnek tekinted a cimkék halmazát ezért érzed úgy, hogy egyszerűbb. Ám ha a cimkék halmazát valóban halmaznak tekinted akkor máris split kellene, ami nem biztos egyszerűbb mint az 1:N tárolás.
Olyan "mellékes" dolgokat mint pl. tag cloud vagy "top 10 cimke" meg sem merek említeni. Van tipped hogyan lehetne megcsinálni, ha szövegesen tárolod a cimkéket? Elfogadhatónak találod a megoldást? Mert én nem. Normál esetben "select cimke, count(cimke) as darab from cimkék group by cimke order by darab desc limit 0, 50"?
"PostgreSQL-t, mert ott alapbol van tomb tipusu mezo" Az ilyen egyedi megoldásokkal az a gond, hogy a tudásod és az adataid is hordozhatatlanná válnak egy idő után.
Összefoglalva és részemről lezárva a témát: A cimkéket (akármit) tekintsük cimkének (akárminek) és kezeljük is aképpen, ezáltal lényegesen csökkentjük a jövőbeni módosítások szükségességét.
En nem emlekszem arra, hogy kovetelmeny lett volna, hogy egy mezoben csak egy cimke szerepeljen. Ez az egyik.
A masik, hogy egy adatmodell attol meg nem hibas, hogy egy bizonyos adatra nem indexelheto, ezt minden esetben a felhasznalas mikentje donti el. Ugyanakkor egy egyszeru lekerdezes szempontjabol nagyon nem mindegy, hogy egy adott - es kinyerni akart - adathalmaz hany adattablaban helyezkedik el. Ugyanis ha az elsodleges szerepe a cimkeknek az, hogy egy tartalomtipus alatt szepen megjelenitsek oket (jellemzoen pl. a flickr ilyen), akkor nem kell a cimkeket indexelni, mert egy ujabb tabla joinolasa a lekerdezesbe tul sok eroforrast pazarol el a hasznossagahoz kepest, foleg ha 10000-es nagysagrend fole emelkedik mondjuk a tartalomelemek vgy a cimkek szama. Nem ismerem pontosan a MySQL motorjat ilyen szempontbol, de az szinte biztos, hogy egy barmilyen join az ON feltetel miatt igenyel egy plusz szekvencialis keresest egy tablan.
Ha viszont (pl. YouTube) a cimkeket related tartalom eloallitasara is hasznalja a rendszer, vagy mas miatt gyakoriak a cimke szerinti lekerdezesek, akkor valoban van ertelme a cimkeket indexelni, es ez esetben valoban olyan adatbazissema kell, amiben a cimkek indexelhetok. De ezt minden esetben a felhasznalas jellege donti el.
Az, hogy a cimkezest 1-1 vagy 1-n kapcsolatnak tekinted, megintcsak erosen felhasznalasfuggo. Lasd feljebb.
A vilagon mindenhol van escape-elendo elvalaszto karakter, mar csak a bevitel miatt is. Kulonben egy php-ben vagy akarmi masban megirt parser honnan tudna, hogy egy formbol erkezo "anya, apa, csirke" harmasbol az "anya, apa" egy cimkenek szamit vagy kettonek? Vagyis ezt a problemat semmikepp sem tudod megkerulni.
A tobb cimkere kereses valoban bonyolultabb az altalam javasolt rendszerben, de az egyszeru tartalommegjelenites cimkestul meg sokkal egyszerubb es gyorsabb, mivel csak egy tablat kell vegiggyalogolnia az adatbaziskezelonek. Ezert mondom, hogy alapvetoen a felhasznalas jellege donti el, hogy a tervezest milyen iranyba viszed es mit akarsz indexelni, normalformara hozod-e a tablat, es ha igen akkor melyikre. En terveztem mar ilyet is, meg olyat is. Aztan volt, ahol a felhasznalas nem igazolta vissza a teoriat (ott indult sok kereses ahol nem teljesitmenyre optimakoltunk, stb), vagyis hiba csuszott az _uzleti_ tervezesbe, ilyenkor sajnos ujra kell tervezni a rendszer bizonyos reszeit, vagy kimagyarazni a teljesitmenyromlast :)
Mivel az eredeti kerdes arra vonatkozott, hogy egy cimkezohoz altalaban milyen struktura szukseges, en batorkodtam a legegyszerubb megoldasbol kiindulni, amit persze a felhasznaloi igenyek fuggvenyeben mar a tervezesi szakaszban is a vegtelensegig lehet bonyolitani.
Es persze ismet hozzateszem - ebben a topicban nagon halkan - , hogy ezert szeretem en nagyon a PostgreSQL-t, mert ott alapbol van tomb tipusu mezo, es PL/PgSQL-ben csodasan lehet is vele dolgozni. Ott altalaban ezt hasznalom a cimkezesre.
Jellemzően akkor kell több tábla, ha 1-n kapcsolatod van, és jellemzően akkor használható 1 tábla, ha 1-1 kapcsolatod van (de ebben az esetben is általában 2 vagy több táblád van, kivéve ha performancia miatt denormalizálni kell). m-n kapcsolat esetében pedig jellemzően 3 tábla szükséges.
Mutass egy sémát amiben egy képhez több cimke is rendelhető a képek táblában, nincs benne több cimke mező, egy mezőben csak egy cimke szerepel és képenként csak egy sor van a táblában.
A szeparátorral elválasztott szöveges tárolás több okból is hibás, pl: 1) Nem indexelhető cimkék szerint. 2) A cimke szerinti lekérdezés plusz műveleteket igényel, azaz előbb a szeparátorok szerint részekre kell bontani a stringet vagy like-ot kell használni. Mindkettő sokkal költségesebb művelet, mint egy indexelt mezőt használni, de azt is megkockáztatom hogy még index nélkül is előnyösebb az egy mező-egy cimke tárolás. 3) Megerőszakolod az adatmodellt, azaz 1-1 kapcsolatra erőltetsz 1-n kapcsolatot. 4) Escapelni kell a szeparátor karaktert és ezt a későbbiekben kezelni kell, mert miért korlátoznád a felhasználót a címkében levő karakterek szempontjából? Pl. "2008. május" is lehet cimke, mint ahogy "anya, apa" vagy "#12", esetleg "én@budapest" is. 5) A több cimkére keresés bonyolultabb, pl. annyi like szükséges ahány cimkére keresel.
Összefoglalva: ezzel a megoldással nem spórolsz meg semmit (a join és a cimke tábla költsége elhanyagolható), viszont beviszel a rendszerbe egy halom problémát.
Hát ha engem kérdezel, én nem vok egy matematikus zseni, még csak elméleti szinten képzett programozó sem ... :-) Én gyakorlati szemszögből szoktam megpróbálni a problémákat megoldani.
(magyarul kitalálok valamit, kipróbálom és ha működik akkor használom...)
Ha jól értem arra akarsz kilyukadni, hogy a double számaimat lebegőpontosan tárolja a MySql és hiába én azt írom bele elvileg hogy mondjuk 11, amikor megkérdezem legközelebb hogy melyik rekordban egyenlő 11-el, akkor nem adja ki, mert szerinte az lehet hogy csak 10.9999999998...?
Mitől függ hogy milyen kicsi eltérés esetén tekintődik egyformának, vagy hogyan kerekítődik ?
Ez gyakorlatilag is okozhat gondot, vagy csak elméleti probléma? (nem vettem eddig észre hogy ez gond volna, postgres-en futogat itt ott ez az új double-s módi...)
Off-topik tesztkérdés: hogyan ellenőrizzük (lehetőleg gyorsan), hogy melyik az a legkisebb lebegőpontos szám, amelyre x=x+1 (a tárolás pontatlansága miatt, mielőtt valaki megkérdezné).
Ez egy olyan háttérrendszer amelyik pc-s kliens programok alá dolgozik. Több telephely egymástól függetlenül működő adatbázisait szinkronizálja időnként egymáshoz egy központin keresztül. Valamikor, amikor az ISDN még hűde gyorsnak számított és az állandó internet még nem volt természetes, egy konkrét cégnek csináltam, nekik megfelelt akkor ahogyan volt (ma is működik még valahogy), de azóta továbbgondoltam és mostanában újraírtam benne sok dolgot, hogy rugalmasabb legyen, eltűnjön belőle pár korábbi korlát... A double mező tulképpen egy minden adatíráskor folyamatosan növekvő jelző mező. Nem agyaltam sokat a típuson, ráböktem a legnagyobbra, hogy a lehető legtovább kitartson.
A lényeg, hogy az ORDER BY -al működik a dolog, így fog maradni.
