Keresés

Sziasztok,

 

Azon vagyok, hogy elsajátítsam a MySQL használatát, szóval könyvjelzőt rakok ide. :) 

Igérem elsőnek szakkönyveket nézek mielött hülyeséget kérdeznék, de most mégis lenne így az elején (hogy legyen mivel elindulni) egy amatör kérdésem:

- Lehetséges a Mysql telepítése és használata gyakorlásként egy gépen és offline?

Köszi, nyilván charset eltérés van, csak tudnám hogy hol.

Én azt tapasztaltam, hogy még mindig többségben vannal az iso-8859-2 kódolású oldalak, de én is híve vagyok az utf-8 terjesztésének, tehát legyen szabványos:

MySQL karakterkészlet: UTF-8 Unicode (utf8)
MySQL kapcsolat egyeztetés: utf8_unicode_ci
HTML meta tag--ban charset=utf-8
Böngésző nézet-encoding: utf-8

Ha phpmyadmin segítségével listázom a tábla tartalmát, akkor helyesen látom az összes ékezetet; ha a HTML oldalon íratom ki, akkor mostmár nemcsak az őű hanem a többi ékezet sem látszik, helyükön csúcsán álló sötét rombuszban kérdőjel látható.

Persze ami nem mysql adatbázisből iródik ki, hanem a HTML kódban van az mind jó így is.

Merre kutakodjak?

Valahol charset eltérés van. A charset ugyanaz kell legyen a meződefiníciótól kezdve a connection-ön és php-n át a html-ig.
MySQL-ben: 9.1.4. Connection Character Sets and Collations (a többit is olvasd el, pl. 9.1.5)
HTTP header: Content-Type: text/html; charset=UTF-8
HTML: <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />

Javaslom az UTF8 használatát, általánosabb, mint az ISO 8859-2.

Megint én...

A programocska, amit készítek iso-8859-2 kódolású weboldalakra írogat, ahol szépen megjelennek a magyar ékezetes betűk a HTML szövegben.
Ellenben a mysql adatbázisban tárolt, magyar ékezeteket tartalmazó string változóknál ő és ű helyett ? jelenik meg, ellenére annak, hogy adatbevitelnél persze rendesen ő és ű kerül a beviteli mezőbe.

Hogyan kellene kinyernem onnan az ő ű betűket?


Köszi!

nem, csak mysql -be az az ojjektumok nevenek a hatarolo karakterek. mas adatbazisokban altalaban a " az. A ' az cirka mindenhol a karakter ertekek hataroloja.

Most látom, hogy az nem is apostrof ( ' ) amit írtál, hanem backtick ( ` AltGr-7), az valami különös dolgot tesz vele?
Köszi!

"a linuxuser"

Nagyon köszönöm, átneveztem a mezőt 'made' -re és működik, de jól esett volna, ha a phpmyadmin, amivel létrohoztam a táblát, figyelmeztet, hogy foglalt kulcsszó a when.
Nem rémlik, hogy 'when'-t adtam volna meg, hiszen nem gyanakodtam.

Az INSERT query-nél így is '$made' kell az dátum és idő adatok közti space miatt, hiszen string típusként szeretném eltenni.

Kösz mégegyszer.
"a linuxuser"

en gyanakodom arra a when-re. Esetleg ha `when` -kent hasznalod a query-dbe is?
Csak mert amikor letrehoztad a tablat sem adhattad meg `` karakterek nelkul, mert a when az foglalt szo mysql-be.

CREATE TABLE `single_res` (n `id` bigint(20) NOT NULL auto_increment,n `user_id` bigint(20) NOT NULL default '0',n `person_id` bigint(20) NOT NULL default '0',n `age` int(3) NOT NULL default '0',n `when` datetime default '0000-00-00 00:00:00',n PRIMARY KEY (`id`),n KEY `user_id` (`user_id`,`person_id`)n) ENGINE=MyISAM DEFAULT CHARSET=latin2 COLLATE=latin2_hungarian_ci

bocs, show create table tabla

ettol igy siman biztos nem. muti a
#create table tabla
kimenetet

Sziasztok!

Nyilván pofon egyszerű, de sajna nem látom a fától az erdőt!

Van egy DATETIME típusú mezőm, amibe akár NOW(), akár '2009-02-12 23:00:00' kerülne bele, folyton #1064 syntax error-t kapok:

INSERT INTO tabla (epp_most) VALUES (NOW())

INSERT INTO tabla (epp_most) VALUES ('2009-02-12 23:00:00')

MySQL 4.1.15 ha ez számít.

Előre is köszönöm:

"a linuxuser"

Átnézek majd oda is, köszönöm!

OFF
"objektum orientáltan vannak megírva, amiről egyenlőre lövésem sincs"
Hibás a hozzáállásod, egyből OO megközelítéssel kellene tanulj. Semmi bonyolult nincs benne, első lépésben két fő fogalmat kell megismerj: osztály és példány. Ráadásul maga az OO univerzális (persze vannak implementációs eltérések és hiányosságok, mint SQL-ben), vagyis később más programnyelvekben is hasznosíthatod ezt a tudást.

Ha most elkezdesz procedurálisan programozni, akkor nehezebb lesz az átállás, ráadásul megtanulsz rossz, hibás, vagy csak kerülendő technikákat.
A php-ben elég új az OO, régebben nem volt választási lehetősége a fejlesztőknek, ezért van még mindig rengeteg procedurális kód. Egyébként az erős fejlesztői nyomás hatására fejlődik egyre jobban ez a rész is a PHP-ben, ami célzás arra, hogy egy hasznos dologról van szó.
Arról nem is beszélve, hogy nagyon sok könyvtár már OO, pl. a Pear.

Másik dolog, amit érdemes kezdetektől alkalmazni: MVC (Modell View Controller). Ezt sem érdemes nulláról implementálni, vannak rá kész könyvtárak (pl. Symfony, CakePHP).

A kész könyvtárak nem használata kb. olyan, mintha Windowsban nem a beépített ablakkezelőt használnád, hanem sajátot írnál, vagy MySQL helyett saját adatbázismotort írnál (egy kivétel van, amikor ez indokolt: ha ez a feladat).
A tanulás nem indok a nem használatra, nem leszel okosabb attól, hogy nem Smarty-t vagy Pear::DB-t használsz. Ezek létezése pont elősegíti a tanulást, mert sok fölösleges munkától szabadít meg, a felszabadult időben pedig fontosabb dolgokat tanulhatsz.

Van php és OO topik is, ha érdekel a téma.

Nemáno! :)
Ha megnézed az SQL86-ot nyoma sincs még a FROM mögött megadható megszorításnak ( JOIN ) és ha lefelé kompatibilisnek tekintjük az új szabványokat akkor a FROM mögött nem értelmezhetik az adatbázis-kezelők másként a táblafelsorolást. Persze, hogy vannak eltérések egyéb értelmezésben az adatbázis-kezelőknél, de nem ilyen szinten. Gondolom, ha ennyire ellenzed a vesszővel történő táblafelsorolást akkor valami erre vonatkozó leírást is tudsz adni mysql szinten, én nem tudok ilyen eltérésről.

"Ennyi sok jobbnál jobb ingyenes blogengine mellett mi értelme van ezzel tölteni az időt?"

Tanulás. Ráadásul a legjobb engine-ek objektum orientáltan vannak megírva, amiről egyenlőre lövésem sincs. És azoknak az írói is így kezdhették :)

Össze ne balhézzatok a kérdésemen! :-)

Szóval JOIN... Majd utána nézek.

Mivel tényleg a tanuló fázisban vagyok, bármilyen bevett szokást szívesen átveszek, ha nem ellenkezik a józan paraszti ésszel. Ahogy látjátok feleim szümtükkel, a mezőnevek megadásakor is a `tábla`.`mezőnév`formát használom mindenütt, mert így könnyebb értelmezni a kódot és túlélni a mezők elnevezésekor elkövetett esetleges következetlenségeket.

"mert a szabványban így van benne"
1) Melyik szabványban a sok közül?
2) A szabványokat (az SQL92-t is) eltérően értelmezik az adatbázisok, van ahol erre fel is hívják a figyelmet (pl. a MySQL dokumentációban többször is, még a join oldalon is figyelmeztetnek eltérésekre), van ahol némán hallgatnak róla.

Tudományosság: nem tudom mire gondolsz, de ha valaminek ez a neve, akkor azt használom, nincs benne semmi varázslat (nézd meg pl. a 1606-ban belinkelt MySQL oldalt). Aki nem ismeri nézzen utána, én nem fogom körülírni, spórolnom kell a billentyűzettel :-)

Nem igazán értem mit nevezel "vessző operátornak". Ha a FROM utáni táblafelsorolásra gondolsz akkor az nem adatbázis-kezelő függő, mert a szabványban így van benne. A kérdező a saját megoldásában volt a probléma amit írsz, mert semmilyen feltételt nem adott meg a táblák között ezért kapta a Descartes-szorzatát eredményül, ha ennyire tudományosan akarjuk a kérdést megközelíteni ;)

A kérdező szerintem nem ragaszkodik semmihez, ő most tanulja a MySQL-t.
Az explicit join azért jobb, mert különböző adatbázisok másképpen értelmezhetik a vesszőt, sőt, egyazon adatbázis különböző verziói is másképpen értelmezhetik.
Nem elemeztem mélyebben az eredeti kérdést, de az egyik kérdésben (1605) pont az volt a gond, hogy cartesian szorzat lett az eredmény a vessző join miatt.

Én szabványosan írtam le az ezt megelőző SQL utasítást ( a COUNT(T2.*) hiba volt, Postgres ezt eszi ), de a kolléga ragaszkodik ehhez a formához, ezért gondoltam nem zavarom meg újra a szokásos dolgokkal. Lehet join-al is csinálni, de ennél a kihívásnál még nem feltétlenül célszerű. A két megoldás csupán megszokás kérdése:

SELECT COUNT( * )
FROM blog_text T1, blog_list T2
WHERE T1.blogtext_id=T2.blogtext_id AND T1.blogtext_stat='a' AND T2.blogcat_id=3

vagy

SELECT COUNT( * )
FROM blog_text T1 INNER JOIN blog_list T2 ON T1.blogtext_id=T2.blogtext_id
WHERE T1.blogtext_stat='a' AND T2.blogcat_id=3

ugyanazt az eredményt produkálja.

A másodikat szigorú szabályok alkalmazásánál azért nem szeretem, mert sokan itt is a gyakrabban használt LEFT és RIGHT joinokat használják ami más eredményhez vezethet. A legegyszerűbb ilyen esetben szerintem a WHERE feltétel T1.blogtext_id=T2.blogtext_id, ahol tényleg csak a mindkét táblában meglévő értékek adnak eredményt.

Tisztább, szárazabb, olvashatóbb érzés, ha explicit módon leírod a join kifejezést, és nem az adatbáziskezelőre bízod, hogy az adott verziója éppen hogyan értelmezi a , (vessző) operátort.

Eddig csak az volt a hiba a selectedben, hogy nem rendelted össze a táblák megfelelő kulcsmezőit. Ezt az első feltételben most elkövettük. Ez próbáltad:

SELECT COUNT(*)
FROM `blog_text`, `blog_list`
WHERE `blog_text`.`blogtext_id`=`blog_list`.`blogtext_id`
AND `blog_text`.`blogtext_stat`='a'
AND `blog_list`.`blogcat_id`=3

Azt hiszem valamelyik másik join kell neked, mivel azt hiszem most inner-t használsz, a vessző azzal egyenértékű, és ez az, amelyik mindent mindennel összeszoroz - Cartesian product.
Az is lehet, hogy a count(*) helyett subselect kell, mert most minden sorban _ugyanazt_ kapod vissza, azaz a select sorainak számát.
Pontosabb válaszra most nem telik, túl késő van hozzá :-)
Lehet egy group by is kell majd valahová.

OFF
Ennyi sok jobbnál jobb ingyenes blogengine mellett mi értelme van ezzel tölteni az időt?

Ezen a COUNT(T2.*) dolgon syntax error-ral hanyatt dől a MySQL, de belepiszkálva a kódodba (köszönet érte!) közelebb értem a megoldáshoz. Már csak azt kellene elérnem, hogy ez a változat összesítse az eredményt: ne soronként írja ki, hogy melyik az a 33 `blogtext_id`, amelyikből van egy-egy, hanem azt, hogy 33 van összesen:

SELECT `blog_list`.`blogtext_id`, COUNT(*)
FROM `blog_text`, `blog_list`
WHERE `blog_text`.`blogtext_id`=`blog_list`.`blogtext_id`
AND `blog_text`.`blogtext_stat`='a'
AND `blog_list`.`blogcat_id`=3
GROUP BY `blog_list`.`blogtext_id`

Próbáltam, hogy az egészet bedobom egy SELECT COUNT()-ba, de az nem működik. Van ötleted?

Én ezzel próbálkoznék, de nem biztos, hogy jól értelmezem amit csinálni akarsz:

SELECT COUNT( T2.* )
FROM blog_text T1, blog_list T2
WHERE T1.blogtext_id=T2.blogtext_id AND T1.blogtext_stat='a' AND T2.blogcat_id=3

...jobban mondva a WHERE-nek azt a feltételét nem nézi, amelyik a `blog_text`.`blogtext_stat`-ra vonatkozik, a `blog_list`-es feltételt kezeli.

Ezt is kipróbáltam:

SELECT COUNT( DISTINCT (`blog_list`.`blogtext_id`) )
FROM `blog_text` , `blog_list`
WHERE `blogtext_stat` = 'a'
AND `blog_list`.`blogcat_id`=3


De ez nem veszi figyelembe a WHERE feltételeket.

Üdv, kezdő MySQL-esként blogmotort építek, és belefutottam egy problémába, amit nem tudok megoldani.

Van három táblám:
a bejegyzéseknek: BLOG_TEXT, benne blogtext_id, blogtext_text, blogtext_stat, stb.
a kategóriáknak: BLOG_CAT, benne blogcat_id, blogcat_name, stb.
a kategorizálásnak: BLOG_LIST, benne blogtext_id és blogcat_id.

Mivel egy blog bejegyzés 0 vagy több kategóriában szerepelhet, úgy láttam jónak, ha nem egy táblában "ikszelgetem", hogy mi miben szerepel, hanem külön táblába írom, mert így könnyebb bővíteni a kategórialistát. Ez a része működik is, de a lapozó összeállításához tudnom kell, hogy hány blogtext_id van besorolva egy bizonyos blogcat_id alá. Ezt az adatot egy tábla lekérdezésével nem tudom megszerezni, mert az, hogy egy bejegyzés megjelenhet-e, a BLOG_TEXT táblában van, a kategorizálása viszont a BLOG_LIST-ben.

Ezzel próbálkoztam:

SELECT COUNT(*)
FROM `blog_text`, `blog_list`
WHERE `blogtext_stat`='a'
AND `blog_list`.`blogcat_id`=3

De ez mintha összeszorozna mindent mindennel. Ha a FROM-ból kihagyom a `blog_list` részt, nem megy a `blohcat_id` lekérdezése.

Próbálkoztam a GROUP BY használatával is, de nem tudtam megszülni a jó megoldást. Plíz help!

Akármiben jeleníted meg az adatokat fontos, hogy a karakterkészlet jól legyen beállítva. Pl. phpMyAdmin-ban a login oldalon lehet választani.