Új hozzászólás Aktív témák
-
-
Sk8erPeter
nagyúr
Ja, hát a diák szempontjából ez a lelkesedés és szorgalom a jó hozzáállás ahhoz, hogy sikeres legyél abban, ami érdekel, a másik oldalról viszont az is tény, hogy ezt az érdeklődést akár meg is lehet teremteni azoknál is, akik korábban nem érdeklődtek az adott témakör iránt, csak ehhez ugye jó tanítási módszerek is kellenek.
Tipikusan a legrosszabb módszer az, hogy rábízzuk a diákra a piszkos melót, tanulja meg ő magától, rengeteg utánanézés és sikertelenség árán, aztán mi meg jól számonkérjük a tudását, és mossuk kezeinket. Az meg a tanár részéről nem mentség, hogy "dehát a diákok többsége úgyis leszarja", mert az ő dolga az, hogy megtanítsa az anyagot, lehetőleg minőségi formában...és erre nem lehet az sem válasz, hogy "dehát a tanár helyetted nem tanulhatja meg az anyagot" (sokszor ilyenkor ez a reflexszerű reakció) - valóban nem, de legalább kedvet és alapot adhat ahhoz, hogy foglalkozz vele, sokan épp az ellenkezőjét teszik ezzel a rohanással.(#919) ArchElf : jaja, egyetértek, sajnos így van. Túl kevés az idő ahhoz, hogy stabil tudást átadjanak. De azzal a módszerrel, hogy tényleg mindent rázúdítanak a diákra, ami nagyjából a webfejlesztés kapcsán első körben igazán fontos lehet, csak rontanak a helyzeten, mert akkor tényleg semmit nem fog átlátni normálisan, amennyiben nem szán a saját idejéből rengeteget arra, hogy megtanulja az anyagot.
Sk8erPeter
-
InfiniteReality
őstag
válasz PazsitZ #1051 üzenetére
Kell vagy nem, egy if (mysql_affected_rows() >0) paranccsal le van kezelve, hogy van-e a lekérdezésnek eredménye. Az első hozzászólásomban lévő mindkét lekérdezésnek van eredménye, az egyik jó, a másik hibás. Amiket beirtatok azoknak pedig nincs eredménye, de hibát sem okoznak...
http://logout.hu/cikk/samsung_led_tv_tudastar_d_szeria/alapok.html
-
InfiniteReality
őstag
válasz PazsitZ #1053 üzenetére
Biztos csak elírás annak a részéről, aki ezt leírta. Vagy régi php/mysql verzióra vonatkozik (nálam mindkettőből 5-ös van).
Szinten mindenhol lecseréltem a num_rows-t affected_rows-ra és működik.Ez működik:
SELECT jatekos, sum(pont) FROM jateklista WHERE pont >='1' GROUP BY jatekosl ORDER BY 2 LIMIT 50Utána egy if mysql_affected_rows() > 0 van annak eldöntésére vannak-e eredmények vagy sem. Ezzel a paranccsal (és egyben lévő adatbázissal) bemegy abba az ágba, ahol ki kell írni az eredményeket.
(SELECT jatekos, sum(pont) FROM jateklista2005 WHERE pont >= '1' GROUP BY jatekosl) UNION (SELECT jatekos, sum(pont) FROM jateklista2006 WHERE pont >= '1' GROUP BY jatekosl) ORDER BY 2 DESC LIMIT 50
Ez az évekre szétdarabol adatbázisra készült és működik, de nem a várt eredményt hozza, nem azt amire szükségem lenne.
http://logout.hu/cikk/samsung_led_tv_tudastar_d_szeria/alapok.html
-
Jim-Y
veterán
válasz PazsitZ #1065 üzenetére
a mysql nem egy felismerhető parancs:/
martonx: nincs elérésem a hosting mysqljéhez, itthon kell lokális gépen megírnom a programot, amit majd átportolok az éles környeztbe, egyszer...ezért szenvedek az xampp-al, meg a phpmyadminnal ami egyébként egy bughalmaz szerintem, de nincs jobb ötletem:S A fejlesztés szempontjából kénytelen vagyok itthon futtatni egy apachot és egy mysql-t, hogy úgy tudjam írni a programot..:/
-
Speeedfire
nagyúr
válasz PazsitZ #1122 üzenetére
Uhh, balga hiba volt.
Ugye anno mikor elkezdtem csinálni az oldalt, csináltam pár teszt adatot.
De ennél az egynél nem töltöttem ki egy mezőt, pedig kötelező kitölteni és a validator miatt nem lett sohasem elmentve.
Kitöltöttem a mezőt, most már megy.Fotóim https://fb.com/toth.szabolcs.art || IG: http://instagram.com/_tothszabolcs_ || Weblapom http://szabolcs-toth.com
-
Speeedfire
nagyúr
válasz PazsitZ #1157 üzenetére
Megjelenített sorok: 0 - 29 ( 1 001 összesen, a lekérdezés 0.0038 másodpercig tartott)
Megjelenített sorok: 0 - 29 ( ~1 001 összesen , a lekérdezés 0.0026 másodpercig tartott)Gyorsabb, amit te írtál meg.
Query cache ürítés volt az 1. teszt után.
2x is megcsináltam ezeket a teszteket, mind a 2 esetben gyorsabb volt a case szerkezet.Fotóim https://fb.com/toth.szabolcs.art || IG: http://instagram.com/_tothszabolcs_ || Weblapom http://szabolcs-toth.com
-
martonx
veterán
válasz PazsitZ #1366 üzenetére
Az SQL tudás mindennél többet ér (bár kitudja pár év múlva a NoSQL-ek felfutásával mire lesz jó a mostani SQL tudásunk ), az MS Access-ennek csak egy speciális vetülete. Az Access SQL meg különösen kilóg az SQL-ek sorából.
A fentebb hozott Access-es példámhoz egyébként SQL tudás kell. A kattitngatást nem arra értettem, hogy az Access designerével join-olod a táblákat, hanem az adatforrások Access-be behúzására. Személy szerint Access-ben is mindig kézzel írom az SQL kódot, a kód designert kb. soha nem használtam még benne.
És nehogy Access pártinak gondoljatok, csak próbáltam rávilágítani, hogy a világ nem szimplán fekete és fehér.Én kérek elnézést!
-
Ispy
veterán
válasz PazsitZ #2092 üzenetére
Én tudok neked mondani példát:
kedves ügyfél szervert cserélt és a kedves rendszergizda az új szerveren a Hungarian_CI_AS collation helyett valami Latin-t adott meg, és ettől a ponttól kezdve a szerver collation-je nem egyezett meg az adatbázis collation-jével és az összes string alapú join kifingott tőle, szóval mindegyiket kézzel meg kellett hekkelni (COLLATE DATABASE_DEFAULT), hogy ne szálljon el hibával. Ez az egész programban kb. 20x fordult elő. Ha nem integer alapú kötéssekkel lett volna tele az adatbázis, akkor ez a szám nem is tudom mennyi lenne, de biztosan 1000 felett.
[ Szerkesztve ]
"Debugging is like being the detective in a crime movie where you're also the murderer."
-
modder
aktív tag
válasz PazsitZ #2092 üzenetére
Csak hogy ne kanyarodjunk el nagyon, az előfeltételek, amiket már legelőször is említettem (vagy nem) a kutyafuttában összedobott hozzászólásomban:
- Átlagos/kis terhelésű weboldalról van szó, nem valami hatalmas terhelésről. Mit tudom én, napi pár 10e oldal lekérés
- Kis adatbázisméret: pár 10e rekord, pár 10MB adatbázis méret (ez mondjuk egy blog mérete sok cikkel)Azért fontos ezt megemlíteni, mert nagy tábláknál, amik sok I/O műveletet igényelnek, fontos, hogy ne növekedjen duplájára a rekord méret egy CHAR field miatt.
Mondok két előnyt:
- az egyik, amiből az egész kiindult, hogy ha a lekérdezéseket szerkesztem valamilyen kliens programban, akkor jobban esik az agyamnak, ha a konkrét információt látom a mezőben, ha ellenőrzöm, jó lekérdezést írtam-e meg. Ide tartozik még, ha valaki (vagy én) évek múlva hozzá akar nyúlni a szoftverhez és adatbázishoz, leegyszerűsödik a dolga.
- a városos példánál maradva nincsen szükség joinra, ami egy kicsit le tudja egyszerűsíteni a lekérdezést, ha egyébként az nagyon összetett; sok másik jointot is tartalmaz.
- ha szoftverben valamilyen ORM frameworkot használunk, közvetlenül benne lehet a város neve a személyek entitásban, ahelyett, hogy egy varos entitason keresztül kéne hozzáférnem az értékhez. (Elképzelhető, hogy egy-egy kapcsolatnál be lehet süllyeszteni a személy entitásba a várost, de most nem jut eszembe, hogy pl. JPA-nál lehet-e)...három lett
Egyébként én először olyan információt akartam szövegként tárolni, ami tipikusan egy enum (SQL) típus lenne, és a mező "kardinalitása" olyan 10 db érték körül mozog. Enummal az a baj, hogy nem elég dinamikus, ha új értékre van szükségem az alkalmazásban, akkor módosítanom kell az elérhető enumok listáját, ami MySQLnél azt is eredményezheti, hogy újragenerálja az egész táblát. És az enumra lett volna alternatíva a numerikus vagy szöveges érték, ahol én arra szavaznék, hogy legyen csak szöveges pl.
Státusz = {"active", "inactive", "suspended", "deleted"} ahelyett, hogy 1,2,3,4-t tennénk a mezőbe. És szerintem ez tényleg nem nagy eretnekség.VÁLASZOK:
----------------------------------------------------bambano, pazsitZ: De fontos ha rossz teljesítményt produkálna a szöveges tárolás. Az volt a gondom, hogy azt sugalltad, az SQLlel egyébként is teljesítményt vesztünk, következésképpen mindegy, hogy a szöveges tárolással teljesítményt vesztünk. Ezzel ki is dobhatnám az érvem, miszerint nem volt teljesítménybeli különbség. Egyébként itt az említett link - aki lemaradt volna -, érdemes megnézni, hogy 1.5 millió rekordnál, kis rekord méretnél, tehát befér a memóriába a tábla, nem volt különbség. http://www.mysqlperformanceblog.com/2008/01/24/enum-fields-vs-varchar-vs-int-joined-table-what-is-faster/
Egyébként nem hálós adatbázisról beszélünk, hanem relációs adatbázisokról (és nem SQL adatbázis).martonx: Ebben teljesen igazad van, hogy szöveges mező index esetén, ha mysql B-TREE indexről van szó, az index mérete bizony jócskán megnövekedhet a numerikus indexhez képest, de a keresés nem lesz annyival lassabb, mert a string összehasonlítás csak az első nem egyező karakterig hasonlít, a fa magassága pedig nem nő akkorát, jellegéből adódóan. Hash indexnél pedig mindegy, mert ott úgyis csak a hash van eltárolva az indexben.
pazsitZ: Szóval mégis csak szükséged van egy másik táblára.
Ahol mondjuk település adatokat tárolsz. Ekkor viszont már minek a string?
(Arról az esetről van szó, ha szövegként tárolom a város nevét, de kell egy másik tábla, ahol az összes lehetséges város tárolva van) Nincs szükségem string joinra lekérdezésnél, hiszen a város neve ott van a személyek táblában. Beszúrásnál van szükség idegen kulcs ellenőrzésre, ami index alapján történik.martonx: Ráadásul pont ez az az általad is sokat kritizált gányolós, kókányolós, hozzáállás az, ami miatt aztán tömegek bele is kövesednek ebbe a programozói attitűdbe. Elvégre minek normálisra megcsinálni az indexeket, meg a relációs kapcsolatokat, há' nem sokkal egyszerűbb, mindent beb***ni egy táblába, megfelelő indexeket rátenni, és ha megnézem ezer sorig még gyors is?
Azért ez nem teljesen így van. Akkor lenne kókányolás (amúgy imádom ezt a szót, én is sokat használom ), ha ezzel alapjaiban véve mennénk szembe a relációs adatbázis elvekkel, de ahogy kifejtettem a normalizálós hozzászólásomban, erről szó sincs. Egyébként én is nagy teljesítményhajhász vagyok, de nem szeretek lemondani a kényelemről ott, ahol nem kapok érte cserébe elég nagy előnyt teljesítményben. És úgy érzem, amíg tudom, hogy nem lesz több száz megabyteos az adatbázisom, addig ez egy ilyen helyzet. -
kezdosql
tag
válasz PazsitZ #3275 üzenetére
Koszonom, igen, ezek mar a kovetkezo lepesek lesznek.
Egyenlore azt kell kitalalnom, hogy milyen tipusu adatok vannak es mi az ertelmezesuk, utana jonnek majd a kapcsolatok.A fo problemam tovabbra is a nyilvantartas modja.
Az excel miatt adja magat a megoldas, hogy minden fajlba szurjak be egy lapot, amin szerepelnek az adott fajl leirasa, oszlopok adatai, adatformatum, stb.Ezt akarom egy olyan nyilvantartasban megoldani, amiben minden fajl adatait lathatom, es ezek reven tudok majd a kapcsolatokra es egyebekre kovetkeztetni.