Új hozzászólás Aktív témák
-
#631
Sk8erPeter
nagyúr
martonx
#630
Sk8erPeter
nagyúr
Igen, de azért az is fontos szempont, amit az utóbbi hsz.-ben írt, hogy igen komoly adatforgalmat is generálhat, így kisebb erőforrásokkal és kapacitásokkal rendelkező rendszernél viszont nem biztos, hogy megéri.
Igazából én még pl. nem próbáltam, egyelőre nem is vágom, mi a módja a képek ilyen módon való eltárolásának adatbázisban, mert még nem néztem utána (bár gondolom nem lehet olyan hű de bonyolult), de nem is igazán volt még rá szükségem, meg elég kényelmesen kezelhető a fájlfeltöltés, az elérési utak lekérése, ráadásul általában a MySQL számára biztosított kapacitások jóval alacsonyabbak, mint a fájlrendszerszintűek.
Éppen ezért tehát - az erőforrások végessége, kapacitásbeli kérdések miatt, plusz azért, mert tulképpen semmivel sem kevésbé kényelmetlen - kezdésnek n-tek számára én személy szerint nem ajánlottam volna a képek ilyen módon való tárolását, nyilván ha most fog bele az SQL elsajátításába, akkor nem nagyvállalati környezetben fog fejlesztgetni, így elég gyorsan, már többszáz (vagy mérettől függően annál kevesebb) képnél is beleütközhet a szolgáltató által felállított MySQL-korlátokba.Sk8erPeter
-
#664
Sk8erPeter
nagyúr
Sk8erPeter
nagyúr
Sziasztok! Bocsi, ide is bedobom a kérdést, hátha valaki a másik topicot nem olvassa: [link].
Köszönöm a segítséget előre is!
Sk8erPeter
-
#666
Sk8erPeter
nagyúr
gaben
#665
Sk8erPeter
nagyúr
TIMESTAMP-pel megoldva:
CREATE TABLE `teszt_tabla` (
`id` INT NOT NULL AUTO_INCREMENT PRIMARY KEY ,
`valami` VARCHAR( 256 ) NOT NULL DEFAULT 'blabla',
`timestamp` TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP
) ENGINE = MYISAM CHARACTER SET utf8 COLLATE utf8_hungarian_ci;[ Szerkesztve ]
Sk8erPeter
-
#690
Sk8erPeter
nagyúr
Frigo
#689
Sk8erPeter
nagyúr
SQLiteSpy
Nem egy phpMyAdmin, de azért talán megteszi.
Meg még SQLite Maestro, SQLite Database browser, FF-beépülő, stb.Sk8erPeter
-
#809
Sk8erPeter
nagyúr
Brown ügynök
#807
Sk8erPeter
nagyúr
válasz
Brown ügynök
#807
üzenetére
Igazából mi az oka, hogy nem mondjuk INNER JOIN-nal csinálod?
Úgy értem, van valami előnye? Tulajdonképpen melyik a gyorsabb? Én úgy tudtam, hogy előnyösebb ilyen esetekben INNER JOIN-t használni, de lehet, hogy valamiről nem tudok.Sk8erPeter
-
#812
Sk8erPeter
nagyúr
martonx
#810
Sk8erPeter
nagyúr
Ja, köszi, én is így tudtam, de tudtommal MySQL-re is pontosan ugyanez igaz.
Egyébként a beágyazott selectnél valahogy szerintem jóval logikusabb is az inner join-os lekérdezés, már akkor is, amikor ránéz az ember a query-re, érti, hogy itt mi fog történni. Ennél az "alselectnél" először néztem, hogy ezt most miért úgy.Sk8erPeter
-
#827
Sk8erPeter
nagyúr
Kommy
#826
Sk8erPeter
nagyúr
Elég nagy könnyítés lenne, ha megmutatnád a táblaszerkezeteket. Legalábbis most ennyiből nehéz kitalálni, mi szerint kéne joinolni a `comments` táblát is a jelenlegi query-hez, melyik id-nak kell stimmelni. Persze találgatni lehet, de egyszerűbb lenne, ha a konkrét megoldást tudnánk megmutatni, nem?
Ha pl. phpmyadminban rámész az exportra, mutatja a CREATE TABLE... részt (sql dump), abból már elég jól látható lenne a dolog.
[ Szerkesztve ]
Sk8erPeter
-
#834
Sk8erPeter
nagyúr
Kommy
#831
Sk8erPeter
nagyúr
Eleve azt nem értem, miért URL szerint csoportosítod... Az URL szerinti "összekötéssel" sem értek egyet, nagyon rossz megoldás.
Szerintem az lenne a normális megoldás erre, hogy van mondjuk egy cikked/bejegyzésed, annak pedig van egy id-ja, és egy másik táblában meg az ehhez a cikkhez és id-hoz tartozó kommentek, hozzászólásoko vannak nyilvántartva. A másik, kommenteket tároló táblában tehát tárolod a cikk id-ját is, és ennek segítségével JOIN-olod a két táblát (nem pedig az url mező segítségével; vagy csak simán lekérdezed a cikkhez tartozó kommenteket), így megkapod a cikkhez tartozó kommenteket.
Most a Te comments tábládban nem látok ilyen, a konkrét cikkre vonatkozó id-t, ami jelezné, hogy a kommentek melyik cikkhez tartoznak, az entries táblában viszont látok egy "comments" mezőt. Ennek most nem nagyon értem a szerepét, mert ha ebben felsorolásszerűen vannak a kommentek id-jai, akkor az nagyon rossz megoldás. De lehet, hogy ennek ehhez nincs köze, erről nem írtál, kitalálni meg nehéz.
Viszont ezt az url mezőn keresztüli összekapcsolgatást gyorsan felejtsd el. Az sem világos, hogy ha ennek a két url mezőnek elvileg azonosnak kellene lenni, akkor mi értelme, hogy ebből kettő van... Szerintem átalakításra szorul a táblastruktúrád, vagy most hirtelen csak én nem veszek észre valamit.Sk8erPeter
-
#836
Sk8erPeter
nagyúr
Kommy
#835
Sk8erPeter
nagyúr
Ja értem, így már más a helyzet.
Akkor végül megoldódott a dolog a CONCAT-tal?Amúgy szerintem az is gáz, hogy ha már eleve nem adnak a kezedbe egy normális dokumentációt az egészről, akkor legalább használnák ki a kommentelési lehetőséget a táblákhoz és annak egyes mezőihez. Azt sem véletlenül találták ki. Mondjuk ritkább, hogy komplex rendszernél az adatbázison belül kommenteket helyeznének el, de akkor jobb esetben legalább van valami doksi az egészről.
[ Szerkesztve ]
Sk8erPeter
-
#843
Sk8erPeter
nagyúr
Brown ügynök
#841
Sk8erPeter
nagyúr
válasz
Brown ügynök
#841
üzenetére
"Stick to using single quotes."
Mondjuk én MySQL-ben pont a dupla idézőjelekhez ragaszkodom a query-knél a PHP-s kódjaimban.
Ennek egyszerű a magyarázata, PHP-ben ha duplaidézőjelbe teszek egy adott stringet - pl. az egész query-t, amit majd le akarok futtatni -, akkor a PHP megpróbálja megkeresni a benne lévő esetleg behelyettesítendő változókat, ez meg lassít. Ezért az egész stringet (magát a query-t) aposztrófok közé rakom, és hogy ne kelljen escape-elni mindig az ezenbelül lévő aposztrófokat, inkább macskakörmöt használok. Ha működik, és nem számít hibásnak, a tököm se fog szenvedni az escape-elgetéssel. (Persze más adatbázisnál akkor marad az escape-elés, vagy az egész string macskakörmök közé rakása.)
[ Szerkesztve ]
Sk8erPeter
-
#867
Sk8erPeter
nagyúr
thumb
#861
Sk8erPeter
nagyúr
"A joomla, drupal stb. nekem tól blogos"
Ha ezt állítod, akkor röviden és tömören összefoglalva fogalmad sincs egyikről sem.
A Wordpress-re még lehet állítani, mert az tényleg inkább gyors blog-összedobálás irányába megy, de egy Drupalra azt mondani, hogy "túl blogos"...bullshit, köze nincs az igazsághoz. Ja, és tapasztalatból mondom, nem a levegőbe beszélek.Egyébként a "mert nekem ez tetszik"-hozzáállással (és kicsit gőgös, "mert csak azért is"-válasszal, legalábbis ez jött le abból, amit írtál) csak saját magadat szívatod. Pl. hogy a Drupalra visszatérjek, brutális nagy közösség áll mögötte, folyamatosan fejlesztik hozzá a modulokat, írásos tutorialok készülnek hozzá, videóismertetők, stb., így jelentős terhet levéve a programozók válláról, és mindezt ingyen osztják meg, ezzel durván felgyorsítva a fejlesztői munkát.
Ha viszont olyan rendszert használsz, ami kevésbé támogatott, akkor az ahhoz való fejlesztés annál nagyobb többletmunkát is jelent számodra/a megbízott fejlesztő számára, ergo több költséggel jár (had ne dobáljak olyan elcsépelt mondatokat, mint hogy "az idő pénz").Ezentúl az általad később linkelt oldalon szereplő dolgok mindegyikét meg tudja jeleníteni ugyanígy egy Drupal vagy egy Joomla.
========
Többiektől bocs az OFF-ért, de nem hagyhattam reakció nélkül.[ Szerkesztve ]
Sk8erPeter
-
#871
Sk8erPeter
nagyúr
ArchElf
#868
Sk8erPeter
nagyúr
Igazából a stílusa volt, ami nálam kicsit kiverte a biztosítékot. Lehet, hogy én is ennek megfelelően reagáltam.
martonx segítőkészen reagált a srácnak, ő meg szerintem eléggé flegmán-lekezelően válaszolt, miközben neki van szüksége segítségre.
Ha meg valaki azt tanácsolja neki, hogy "ugyan már, ne szívasd magad ezzel, van ennél jobb megoldás is", akkor arra nem az a normális reakció, hogy "te meg rohadj meg, nekem akkor is ez tetszik". (Nyilván szándékos túlzásokkal teledobva, de érted.)
Ezentúl az is kicsit rosszul veszi ki magát a kommentjeiből, hogy "na majd én megmondom"-stílusban negatív véleményt alkot olyasmiről, amit nem ismer.
Ha valaki segítséget kérni jön egy fórumba, akkor vegyen vissza kicsit az arcából, és kicsit higgadtabban fogadja a jóindulatú tanácsokat, ennyi.===
(#869) thumb:
igazán nincs mit!
"de sebaj ez egy fórum, itt mindenki beírhat"
Igen, sajnos olyan stílusban is, ahogy Te tetted.===
(#870) martonx: pontosan.
Wordpress-szel nekem egyelőre csak nagyon rövid tapasztalatom van, de hallottam róla hideget-meleget is, dicsérik amiatt, hogy gyorsan lehet vele összehozni jól működő oldalakat, de egy-két negatív kritikát is lehet olvasni róla a kódja miatt, gondolom mindegyikben van némi igazság.
A noname, vagy kevéssé támogatott CMS-ekkel meg tényleg egyszerűen már csak a saját idegrendszerünk kímélése érdekében sem érdemes foglalkozni.[ Szerkesztve ]
Sk8erPeter
-
#892
Sk8erPeter
nagyúr
Azazello-
#888
-
#894
Sk8erPeter
nagyúr
Azazello-
#893
Sk8erPeter
nagyúr
válasz
Azazello-
#893
üzenetére
Nem értesz hozzá, nem is érdekel az egész, de azért mi oldjuk meg helyetted. Ez azért nem így működik. Nem tudjuk neked elejétől a végéig leírni, hogyan oldj meg egy ilyet, nekünk sincs tengernyi időnk. Úgy tudunk itt segíteni, ha már elindultál egy úton, de valahol megakadtál, és segítséget kérsz a továbbjutáshoz. Az úgy már egészen más, mert akkor már legalább van valami alapod, amire lehet építeni. Ha viszont komolyabb segítséget kérsz, nem árt egy kis alázat is, ahelyett, hogy felháborodva reagálnál a hozzászólásokra (lásd "ez most komoly?", meg "gurukám"), úgy több sikered lenne. Meg azért ne az jöjjön le, hogy igazán elkészíthetnénk mi az egésznek a vázát.
Sk8erPeter
-
#900
Sk8erPeter
nagyúr
Azazello-
#898
Sk8erPeter
nagyúr
válasz
Azazello-
#898
üzenetére
"elszoktam a magyar reakcioktol"
Te miről beszélsz?
Milyen érdekes, rajtad kívül más tudott normálisan kérdezni, és kapott is segítséget ebben a topicban és máshol is a PH! fórumain.
Talán mielőtt ujjal mutogatsz másokra, másban keresed a hibát, egy kicsit fordulj magadba, értelmezd (!), amiket írtunk, és gondolkozz el azon, hogy valószínűleg nem véletlenül írtunk annyian egybehangzó véleményt arról, amit kérdeztél (ti. hogy túl nagy téma ahhoz, hogy ezt csak úgy iderittyentsük neked). Elég szomorú, hogy erre így reagáltál, de legalább ezzel bebizonyítottad, hogy semmiféle segítséget nem érdemelsz meg, amíg nem veszel vissza az arcodból. Tudod, ez úgy van, hogy ha én kérek tanácsot, akkor nem nekem nagy a pofám.Sk8erPeter
-
#916
Sk8erPeter
nagyúr
martonx
#914
Sk8erPeter
nagyúr
Ezt bírom egyébként az ilyen sulis "webmester"-kurzusokban - legalábbis az alapján, amiket eddig hallottam, illetve olvastam (és ez is megerősíti) -, hogy mindenen átrohannak, mint egy őrült, az alapok normális lefektetése nélkül, hogy ebből is, abból is legyen egy kicsi, mindenből csipegetünk valamennyit, de pont annyit, hogy lehetőleg a diák egy árva szót ne értsen az egészből, és ne tudja összerakni, hogy most akkor mi a szar is ez az egész, ha önszorgalomból nem fekszik rá keményen.
Azt nem értem, miért nem építenek fel egy logikus struktúrát (nyilván naiv felvetés, de annyira azért nem földtől elrugaszkodott elképzelés). Legyenek ezek a nyelvek elkülönítve, ne ömlesztve tanuljanak mindent, hanem tematikusan, de akkor már legalább az alapok normális lefektetése után. Az még mindig többet ér, ha valaki kevesebb nyelvbe kóstol bele, de legalább azt biztosan tudja. Így a későbbi nyelveknél is esélyes, hogy jobban át fogja látni a logikáját az egésznek. Ha kevés az idő, akkor egyszerű a megoldás: kevesebb dolgot kell jobban átvenni, nem minden-mindegy alapon ömleszteni a trágyát a diák fejére.Szerk.: OFF.
[ Szerkesztve ]
Sk8erPeter
-
#942
Sk8erPeter
nagyúr
PazsitZ
#918
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
-
#943
Sk8erPeter
nagyúr
retrox
#930
Sk8erPeter
nagyúr
"csak ez egy kész cms.Minden php-val van megcsinálva"
És akkor mi van?
A Drupal is egy kész CMS, attól még modulokat lehet írni hozzá, ami a saját céljaidnak megfelelően jelenít meg adatokat.
Egyébként meg egyáltalán nem értem, hogy Te ezek szerint egy plusz lekérdezéssel, UPDATE-tel ki tudtad egészíteni az e107 működését, akkor miért ne tudnád annyival is, hogy miután már a felhasználó születési dátuma el van tárolva, ebből egy egyszerű lekérdezéssel megjeleníted az aktuális korát? Így legalább ütemezett update-ekre sem lenne szükség...
Szerintem valamit félreértesz az itt javasoltakból. A lényege, hogy ugye a születési dátumod nem túl sokszor változik jó esetben - ebből az adatból pedig "on-the-fly" bármikor ki lehet számolni az aktuális életkort, nem kell hozzá még PHP sem, elég MySQL-ből kiszámolni.Egyébként meg martonx már mondta, de az e107 már régóta elavult, azóta más felhasználóbarát CMS-ek is bőven vannak.
Én mondjuk a Drupalt ajánlanám, bár azt hallottam, hogy a Wordpress kezdőknek ideális választás (vagy azoknak, akik haladók, és ezt jobban ismerik). Haladók a Drupal moduljaival is gyorsan elboldogulnak némi help olvasgatása után.Sk8erPeter
-
#960
Sk8erPeter
nagyúr
Lacces
#959
Sk8erPeter
nagyúr
Nem benned van a hiba, örülj neki, hogy normális lekérdezéseket jobban átlátsz.
Amúgy az is kérdés, milyen "alselectekre" gondolsz: van, amikor igazából nem is nagyon lehet másképp megoldani egy ilyet, vagy nehézkes, és most ne kérd, hogy azonnal mondjak neked ilyen példát, mert nem jut eszembe. Gyakorlatban jönne elő.Más: úgy tudom, MySQL-t használsz, ebben az esetben ezt ajánlom az egyszerűbbek közt viszonylag összetettebb (na, szóval érted
) lekérdezések elkészítésére: dbForge Studio for MySQL. Szerintem nagyon hasznos tud lenni, amikor az embernek hirtelen a fáradtságtól vagy a pillanatnyi elmezavartól a neve sem jut eszébe, nem hogy egy picit is összetettebb query. 
Van ilyen, ilyenkor jól jön egy grafikus alapú query-összedobálós program, ami meglepő módon egyáltalán nem gyárt gány kódot. Most ez persze elsősorban a JOIN-okra vonatkozik, nem arra, amikor mondjuk durvább query-d van, meg temporary táblák sora van több "alselectben", stb., tehát azért még mindig a viszonylag egyszerű query-k összerakására kell gondolni.Sk8erPeter
-
#974
Sk8erPeter
nagyúr
bpx
#972
Sk8erPeter
nagyúr
Miért lenne már ez "kliensoldal"?
Egész eddig szerveroldali authentikációról és authorizációról beszéltünk - nyilván, mi másról, ha itt webes alkalmazásról van szó? -, hol van itt kliensoldali jogosultságkezelés?
Egyébként számomra sem világos, miért kellene kitekerni az adatbázist ahhoz, hogy valaki admin-jogosultságokkal bejelentkezve hozzáférjen az adatbázis bizonyos adataihoz. Ha már valaki rossz szándékkal hozzáfér az adatbázisodhoz, akkor már úgyis teljesen mindegy, nem valószínű, hogy az ilyen szintű elbonyolítással fogod hűdebiztonságossá tenni az oldalt.
Ráadásul nézd meg akár a jóféle CMS-eket is, ezek biztonsági részét is próbálják lehetőleg minél jobbá tenni az idők során (mindig van mit foltozgatni; de akár a form injectionös problémára is megoldások vannak) a hitelesítés és minden egyéb kapcsán is, de átlátható adatbázis-szerkezete van, nem adatbázisszinten akarják megoldani a jogosultságkezelést. A lényeg, én is azon az állásponton vagyok, mint martonx, hogy az alkalmazásra kellene bízni ilyen esetben (is) a jogosultságkezelést, nem pedig SQL-szintre tenni.De ha van ellenérved, írd le.
Sk8erPeter
-
#976
Sk8erPeter
nagyúr
#65304576
#975
Sk8erPeter
nagyúr
válasz
#65304576
#975
üzenetére
Köszi az Oracle-lel kapcsolatos infót.
Oracle-ben simán lehet, hogy ez már jól megoldott kérdés, én mondjuk elsősorban MySQL-re szorítkoztam jelen esetben (igaz, ezt nem tettem hozzá), mivel a másik topicban a srác konkrétan MySQL-ről kérdezősködött (MySQL+PHP kérdés).
Ezt írtad: "Komoly helyeken ma már elvárás, hogy az adatbázis rendszeradminok ne férhessenek hozzá érzékeny adatokhoz"
Itt az érzékeny adatok alatt érthetünk akár jelszavakat vagy más adatokat is, amiket nyilvánvalóan egy mezei MySQL-táblában is többnyire valamilyen hash-elt formában tárolnak el, hogy akár egy adatbázis-rendszergazda se lássa ezeket nyers formában, bár önmagában még ez sem jelent komoly védelmet.
Különben úgy állítottad be, hogy az, hogy a DBA pozíció komoly bizalmon alapszik, az ellentmond annak, hogy a jogosultságkezelést elsősorban NEM adatbázisban kell megoldani - amit én és martonx állítottunk. Ezt továbbra is tartom, hogy egy normális alkalmazás esetén a jogosultságkezelés megoldása nem csak akkor dől el, amikor az adatbázissal kommunikálsz, hanem belépés után egészen a munkamenet erejéig egyértelműek a szerepkörök és a hozzájuk tartozó jogosultságok...
Másrészt már hogy ne lenne egy DBA állás egy valamit is jelentő cégnél komoly bizalmi pozíció? Teljesen nyilvánvaló, hogy az, mivel egy komplett adatbázis van a kezedben, azt megfelelő szerződéskötés híján akár nyugodtan jogszerűen ki is adhatnád más cégeknek, vagy csak szivárogtathatnál belőle adatokat, így egyértelmű, hogy egy cégnél azért meg kell fontolni, kivel, mit írnak alá - be kell biztosítaniuk magukat önmaguk védelme érdekében, ez így normális.[ Szerkesztve ]
Sk8erPeter
-
#1074
Sk8erPeter
nagyúr
Jim-Y
#1071
Sk8erPeter
nagyúr
"Más" utáni részre reagálva:
A PDO exec() függvényét használod itt? Vagy ez saját wrapper osztály?
Ha a PDO-é, akkor azonnal felejtsd el, hogy exec() metódus használatával közvetlenül beleraksz felhasználótól érkező adatot. Meg nem ártana, ha kivételeket kezelnél.
Nem is értem, pont az a lényege a PDO-nak, hogy szépen lehet vele az adatokat kezelni, prepared statementeket lehet vele használni, így escape-elgetni sem kell a karaktereket, épp ez az egyik legjobb benne, de a másik pedig az előkészített query által megvalósítható szép kód - nincs szükség okádék string-összefűzögetésre, mint - bocs - a Te kódodban.Tele von Zsinór kolléga a PHP topicban belinkelte a saját cikkét a témában, ami elég jól összefoglalja a dolgot:
http://maerlyn.eu/2011/12/03/pdo.htmlTehát
$db->exec("INSERT INTO offers (offer_id,description,images) VALUES ('$provider_id','$htmlcontent', '".$_FILES['uploaded_image']['name']."');");
FELEJTŐS, HELYETTE:$dbh = NULL;
try {
// felhasználónév, jelszónál saját adat behelyettesítendő
$dbh = new PDO("mysql:host=localhost;dbname=test", "root", "root", array(
PDO::MYSQL_ATTR_INIT_COMMAND => 'SET NAMES UTF8;',
PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION
));
// ..............
$sth = $dbh->prepare('INSERT INTO offers (offer_id,description,images) VALUES (:offer_id, :description, :images)');
$sth->bindParam(':offer_id', $provider_id, PDO::PARAM_INT);
$sth->bindParam(':description', $htmlcontent, PDO::PARAM_STR);
$sth->bindParam(':images', $_FILES['uploaded_image']['name'], PDO::PARAM_STR);
$sth->execute();
echo 'Úgy tűnik, minden OK.';
}
catch (PDOException $err) {
echo 'Hiba: ', $e->getMessage();
}
catch (Exception $e) {
echo 'Másik hiba: ', $e->getMessage();
}Itt feltételeztem, hogy az offer_id egy INT.
Meg természetesen a kivételeket inkább naplózni kéne, és felhasználóbarát üzeneteket kiírni.Ja, és a fentivel nagy eséllyel kerülhető el az általad említett probléma.
Legalábbis remélem. Majd írd meg, mire jutottál.Sk8erPeter
-
#1076
Sk8erPeter
nagyúr
Jim-Y
#1075
Sk8erPeter
nagyúr
"egyébként az exec-et már korábban átírtam prepare-re, de tény, hogy attól a paramétereket ugyanúgy beleírtam a query-be"
Akkor esélyes, hogy ez volt a gond egyik okozója.
OK, majd írd meg, mi lett a vége.Szerk.:
"Kivételt nem kezeltem, de otthon majd átírom ilyenre, remélem megoldódik ilyen módszerrel"
Hát nem a kivételkezeléstől fog megoldódni, az biztos.
A kivételkezelés csak egy szép módja a hibakezelésnek, ennyi. Attól még önmagában nem megoldott az adatok helyes feltöltése, csak így könnyű elkapni az eldobott kivételt, ha valahol hiba keletkezett.[ Szerkesztve ]
Sk8erPeter
-
#1091
Sk8erPeter
nagyúr
Speeedfire
#1090
Sk8erPeter
nagyúr
válasz
Speeedfire
#1090
üzenetére
Nyilván MySQL-ről van szó.
Lehet 2 timestamp 1 táblában.
Ami a baja, hogy ha van két timestamp egy táblában, azt nem lehet megcsinálni, hogy az egyik mezőnek defaultból CURRENT_TIMESTAMP az értéke, ÉS a másiknak pedig on update CURRENT_TIMESTAMP tulajdonsága van. Ahogy az sem lehet, hogy mindkettő mezőnek on update CURRENT_TIMESTAMP tulajdonsága van, vagy mindkettő mezőnek CURRENT_TIMESTAMP a default értéke.
Választani kell.Sk8erPeter
-
#1094
Sk8erPeter
nagyúr
WolfLenny
#1093
Sk8erPeter
nagyúr
válasz
WolfLenny
#1093
üzenetére
Pont ilyen kérdést tettek fel Stack Overflow-n: [MySQL - Selecting data from multiple tables all with same structure but different data]
Ott javasolt megoldás:
(SELECT * from us_music where `genre` = 'punk')
UNION
(SELECT * from de_music where `genre` = 'punk')Sk8erPeter
-
#1099
Sk8erPeter
nagyúr
B-L-A-C-K
#1098
Sk8erPeter
nagyúr
válasz
B-L-A-C-K
#1098
üzenetére
Remélem csak viccelsz... [link] >>> második találat.... (de persze az első is a php.net oldalára visz, onnan is nyugodtan elkalauzolhatsz...)
Már a Wikipédia vonatkozó szócikkéből is kiderül kb. 3 másodperc Guglizás után, hogy "a PHP szabad szoftver"...
Ha már ez is gondot okoz, akkor szerintem jobban jársz, ha felkeresel egy rendszergazdát, aki X összegért bevállalja neked az egész összeállítását, lehet, hogy nem lesz olcsó, de esélyes, hogy működőképes lesz a rendszered - most ezt nem rosszindulatból mondom, de azért egy publikusan elérhető szerver felállítását nem lehet elviccelni, meg ingatag lábakon hagyni.Sk8erPeter
-
#1101
Sk8erPeter
nagyúr
B-L-A-C-K
#1100
Sk8erPeter
nagyúr
válasz
B-L-A-C-K
#1100
üzenetére
Nem, nem rázom kisujjból ezeket a dolgokat, nem vagyok rendszergazda. Bár csináltam már szerverállítgatós mókákat bőven melóhelyen is, de ez csak megerősítette bennem, hogy tuti soha nem akarnék rendszergazda lenni, ha nem muszáj.
Annyira macerás és szerteágazó témakör, plusz rengeteg hibalehetőség van - ezért is javasoltam, hogy inkább bízz meg valakit a feladattal, nem azért, mert feltételezem, hogy bekapcsolni sem tudod a gépet. De azért vannak dolgok, amikbe az embernek nem ártana legalább minimális erőfeszítést belefektetnie, ha már ezzel akar foglalkozni komolyabban is (pl. egy szerver megfelelő beállítása már elég komoly dolog) - pl. azt kideríteni, hogy honnan tudod letölteni a PHP-t, és egyáltalán ingyenes-e, pont ilyen dolog...ezekkel a kérdésekkel csak azt bizonyítod be, hogy kicsit sem néztél utána a témának, de azért mástól várod a segítséget, hogy majd neki kerüljön energiájába, hogy szinte megfogja a kezedet, és idegenvezetés jelleggel elkalauzoljon téged az internetes nagyvilágban.Sk8erPeter
-
#1103
Sk8erPeter
nagyúr
B-L-A-C-K
#1102
Sk8erPeter
nagyúr
válasz
B-L-A-C-K
#1102
üzenetére
"oda is beírják minden nap 20x szinte ugyan azt a kérdést amire a választ a keresőből is megtudná, de mégis mind a 20x meg is válaszoljuk ugyan azt"
És úgy gondolod, ez követendő példa?
Sajnos ez a "divat" a Prohardver fórumain tényleg nagyon elharapózott manapság, pont ez a probléma. Ez nem csak az én szélsőséges véleményem, épp a napokban beszélgettem erről egy modival, sajnos ő is hasonlóan látja a helyzetet.Félreértesz, nem az a baj, ha felteszel kérdéseket, amik másnak alapvetőek lehetnek (valakinek az is alapvető lehet, hogyan kell csatlakozni egy adatbázishoz PHP-kódból), hanem az a "baj", ha olyan kérdést teszel fel, ami tényleg kideríthető kevesebb, mint 1 percnyi utánanézéssel - kb. annyi idő alatt, amennyi idő alatt megírtad a kérdésedet. Igazából csak nem értem az okát, hogy miért jó ez. Ha megkérdezed, hogyan kell telepíteni a PHP-t, még az is jobb, mint azt megkérdezni, egyáltalán letölthető-e valahonnan legálisan. Az oka, hogy ez zavaró, az az, hogy ezekkel a hozzászólásokkal csak hígul a topic szakmaisága, ráadásul ennek már köze nincs az SQL-hez. Írod is, hogy "Tényleg nem néztem utána" - felmerül a kérdés, hogy vajon miért nem? Egy fórum nem arra való, hogy helyetted gondolkozzanak az emberek, hanem hogy segítsenek, ha valahol elakadtál, és nem sikerült megtalálnod a kellő információt.
Szerk.: most utálhatsz azért, hogy ezeket leírtam, de ha mindenki csendben marad, és soha senki nem szól semmiért annak érdekében, hogy a Prohardver szakmai színvonala azért ne süllyedjen a békának ama bizonyos testrésze alá, akkor csak egyre rosszabb irányba fogunk haladni.
[ Szerkesztve ]
Sk8erPeter
-
#1107
Sk8erPeter
nagyúr
WolfLenny
#1106
Sk8erPeter
nagyúr
válasz
WolfLenny
#1106
üzenetére
Lehet, hogy ilyenre gondolsz: [link]. Nem?
Szerk.: bár most már akkor kevésbé értem a feladatot. Először azt írtad: "Van két (vagy több) tábla ami azonos struktúrával rendelkezik." - és ezekből "egyesítve" (union) kellene lekérni adatot.
Akkor lehet, hogy a kettő kombinációja kellene. Összefűzni a fájlokat, majd union, de már kicsit összezavartál.
Igazából most nem vágom, az a sok különálló file egy-egy adatbázis dump file? Tehát nincsenek eleve felküldve az adatbázisba? Pontosíts plíz.[ Szerkesztve ]
Sk8erPeter
-
#1113
Sk8erPeter
nagyúr
Speeedfire
#1111
Sk8erPeter
nagyúr
válasz
Speeedfire
#1111
üzenetére
"Hogy lehetne engedélyezni ezt a felhasználót az adatbázisban?"
Screenshot
1.) "Jogok" fül
2.) itt hozzá tudod adni az új felhasználót; de nálad ez már megtörtént, úgyhogy "Jogok szerkesztése" az adott felhasználónál
3.) "Adatbázis-specifikus jogok" résznél "Jogok hozzáadása a következő adatbázison:", kiválasztod a megfelelő adatbázist,
4.) itt a "Jogok szerkesztése" ablakban kiválasztod, milyen jogokat akarsz adni az adott felhasználónak (kattints a "Mind kijelölése" linkre, ha minden jogot meg akarsz adni az adott felhasználónak ezen az adatbázison belül
5.) Indítás, és kész vagy.Sk8erPeter
-
#1114
Sk8erPeter
nagyúr
WolfLenny
#1112
Sk8erPeter
nagyúr
válasz
WolfLenny
#1112
üzenetére
Többek közt a táblák megfelelő indexelésével... Query cache használatával...
EXPLAIN segít, hogy hol kellene többek közt az indexelésen javítani...
Itt van pár tipp.
Aztán még számtalan más oka lehet.Túl általánosan írtad le a problémádat ahhoz, hogy konkrétan tudjunk segíteni. De a fentiek közül valamelyik segíthet.
===
Szerk.: egyébként -Zeratul- írt neked egy elég jó választ itt korábban, de arra nem reagáltál... ez végül is megoldotta az előző problémádat? Nem árt - illik - válaszolni az illetőnek, ha segítséget kaptál...[ Szerkesztve ]
Sk8erPeter
-
#1119
Sk8erPeter
nagyúr
Speeedfire
#1115
Sk8erPeter
nagyúr
válasz
Speeedfire
#1115
üzenetére
Hát akkor lehet, hogy az adott táblára globális jogok vonatkoznak, hogy minden felhasználó hozzáférhessen, szóval akkor az adott adatbázisnál a "Jogok ellenőrzése" résznél meg kellene kukkantani, milyen jogosultságok vannak beállítva; vagy az adott júzereknek túl sok a joga. Az tényleg nem jóféle, ha mindenki hozzáfér.
=====================
WolfLenny : nincs mit![ Szerkesztve ]
Sk8erPeter
-
#1121
Sk8erPeter
nagyúr
Speeedfire
#1120
Sk8erPeter
nagyúr
válasz
Speeedfire
#1120
üzenetére
Az adott felhasználónak, akivel kapcsolódsz a Yii-n keresztül, van joga a feltöltéshez is?
Sk8erPeter
-
#1136
Sk8erPeter
nagyúr
WolfLenny
#1135
Sk8erPeter
nagyúr
válasz
WolfLenny
#1135
üzenetére
Olvasd el még egyszer, amiket írt neked martonx. Pl. ezt, elég érthetően írja le.
Szerk.:
azt írja, hogy "egy SQL tábla kb. bármennyi adatot elbír", ergo tárolhatsz bármennyi adatot így, de lehet, hogy hosszú lekérdezési időkkel kell számolnod.
Gyorsaság szempontjából - ha azonos hónapon belül lekérendő adatokról beszélünk - lehet, hogy gyorsabb külön táblákban tárolni, de aztán kérdés, hogy milyen lekérések gyakoribbak, havi szintű vagy hosszabb időtartamú, aztán lehet, hogy a UNION-nal való lekérdezések, VIEWS-ba rakás ront a teljesítményen, meg "logikailag" nem biztos, hogy szerencsés a különbontás.
Na jó, a hsz. végére már magamat is belekavartam, szóval nem tudom, mi lenne az optimális megoldás.[ Szerkesztve ]
Sk8erPeter
-
#1139
Sk8erPeter
nagyúr
WolfLenny
#1138
Sk8erPeter
nagyúr
válasz
WolfLenny
#1138
üzenetére
Nem azt mondom, hogy a view lassabb, hanem UNION-nal bohóckodni itt felesleges - ha a havi lekérdezés extrém ritka, akkor főleg biztos, hogy egy táblába tenném. Teljesen felesleges szétbontani. Szerintem jóval könnyebben optimalizálható a tábla, de majd remélem martonx megmondja a tutit, hogy mi a helyzet ezzel.
Sk8erPeter
-
#1160
Sk8erPeter
nagyúr
SektorFlop
#1159
Sk8erPeter
nagyúr
válasz
SektorFlop
#1159
üzenetére
Te most minden alkalommal egy view-t akarsz létrehozni? Hát az úgy nem lesz jó.
Akkor inkább a view-t selecteld, vagy hagyd a view-t.Sk8erPeter
-
#1162
Sk8erPeter
nagyúr
SektorFlop
#1161
Sk8erPeter
nagyúr
-
#1165
Sk8erPeter
nagyúr
kisbandima
#1163
Sk8erPeter
nagyúr
válasz
kisbandima
#1163
üzenetére
Én is a tárolt eljárásra szavaznék, de nem ártana látni a "favágó" módszert, meg az alap query-t, vagy valami példaszerűséget, hogy meg tudjuk mondani, hogyan tudnád azt szebben elkészíteni.
Pl. a WHERE-ben is lehetne CASE-ek.(#1164) lakisoft :
Most már érdekelne, hogy ez a dynamic SQL miért jó? Ahogy nézegettem, ez igazából egy query feltételektől függő konkatenálgatása, aztán a query "elkészítése" során annak végrehajtása, ami szerintem elég randa.
Akkor már a WHERE-be elhelyezett, kicsit komplex CASE-ek is szebbnek tűnnek.
Persze aztán lehet, hogy csak nem találkoztam durva esetekkel, ahol nincs jobb, ezért kérdezem.[ Szerkesztve ]
Sk8erPeter
-
#1168
Sk8erPeter
nagyúr
Speeedfire
#1167
Sk8erPeter
nagyúr
válasz
Speeedfire
#1167
üzenetére
Hát én komplexebb feladatokra tárolt eljárást használok, mióta belekóstoltam.
De a te feladatodat igazából nem értem, hogy miért akarod tömbökbe szedni a userek id-ját... Adott userekhez tartozó bejegyzéseknél X időközönként csak Y mennyiséget akarsz törölni, tehát azt akarod, hogy valamennyi az adott júzerhez mindenképp megmaradjon?
Szóval nem csak törölni kell a táblából azt az Y sort, azt' kész?
Fejtsd ki, MOST!===
(#1166) lakisoft :
"Tárolt eljárást is sokszor használok Dynamic SQL-lel együtt. Ott már nem látod hogy csúnya
."
Miért, a tárolt eljárás önmagában még nem ocsmány, de el lehet rondítani.Sk8erPeter
Akkor végül megoldódott a dolog a CONCAT-tal?
Ennek egyszerű a magyarázata, PHP-ben ha duplaidézőjelbe teszek egy adott stringet - pl. az egész query-t, amit majd le akarok futtatni -, akkor a PHP megpróbálja megkeresni a benne lévő esetleg behelyettesítendő változókat, ez meg lassít. Ezért az egész stringet (magát a query-t) aposztrófok közé rakom, és hogy ne kelljen escape-elni mindig az ezenbelül lévő aposztrófokat, inkább macskakörmöt használok. Ha működik, és nem számít hibásnak, a tököm se fog szenvedni az escape-elgetéssel. 
Milyen érdekes, rajtad kívül más tudott normálisan kérdezni, és kapott is segítséget ebben a topicban és máshol is a PH! fórumain.
Van ilyen, ilyenkor jól jön egy grafikus alapú query-összedobálós program, ami meglepő módon egyáltalán nem gyárt gány kódot. Most ez persze elsősorban a JOIN-okra vonatkozik, nem arra, amikor mondjuk durvább query-d van, meg temporary táblák sora van több "alselectben", stb., tehát azért még mindig a viszonylag egyszerű query-k összerakására kell gondolni.
Egész eddig szerveroldali authentikációról és authorizációról beszéltünk - nyilván, mi másról, ha itt webes alkalmazásról van szó? -, hol van itt kliensoldali jogosultságkezelés?
."Új hozzászólás Aktív témák
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest