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.
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.
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?
Ü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!
most ugye viccelsz hogy 1 dos ablak megjelenesen probalmazol? :D) Mi koze annak hogy a dos ablakodba hogy jelenik meg, hogy valojaban hogy van az adat az adatbazisban? AMugy latszik a keprol is hogy oke. Az ekezeteket nem tudom, az lehet azert nem latszik mert a dos promp-od nem jeleniti meg.
Nezd meg ertelmes cuccal a db-det ne dos-bol mysql prompt.
Talán nézd szépen sorban a problémákat, hátha mindegyiknek megvan a magyarázata, pl:
Idő: úgy látszik, ebben a kontextusban nem működik a now() függyvény Ékezetek: A DOS-ablak cp852-t használ, az adatbázisban meg latin2 van (valószínűleg), szóval ez a hiba nem hiba. Elcsúsztak a mezők: lehet, hogy nem jól értelmezted az importfájl formátumát?
Ja, bocs. Közben elbeszéltünk egymás mellet. engem nem érdekel hogy a Date-time mező alapértéken marad és nem tölti ki az aktuális dátummal.... Hanem az a bajom hogy amint látszik a képen is hogy szétvan csúszva az egész tábla mikor lekérem select-el a tartalmát, hogy ékezeteket nem ír ki az még haggyál, de hogy a nevek össsze vannnak csúszva a primary mezővel. meg kb az utolsó oszlopban (termekek, kapcsolatok) bele veszi a határóló karaktert (;) meg ilyenek.
Persze megoldast azt kinalnak, kihagyva a now-t a file-bol, es a load data infile parancs-ba set-elve az oszlopot, megadhato hogy now() legyen. De persze load data manual mindent leir.
