Aktív témák
-
#2124
cucka
addikt
Peter Kiss
#2123
cucka
addikt
válasz
Peter Kiss
#2123
üzenetére
Szerintem ha alacsony szinten akarod kezelni az adatbázist (tehát query-ket akarsz összerakni), akkor jó a PDO meg bármi más. Ha magas szinten akarod kezelni, akkor meg beizzítasz egy ORM-et.
Amit te szeretnél csinálni, az az, hogy becsomagolod a PDO-t, mert így talán szebb lesz. Nem lesz az, mert amit leírsz, az csak szintaktikai varázslat, nincs neki túl sok funkcionális haszna. Ezernyi hasznosabb dolgot tudnék mondani, mint megírni a hatszázezredik php-s adatbázis wrapper osztályt. -
cucka
addikt
válasz
Briganti
#1967
üzenetére
az egyetlen gond a te lekerdezesesidben hogy csak a cikkek tabla tartalmat kapom meg, nem lesz melletuk 1-1 tag is
Mivel egy cikkhez tetszőleges számú tag tartozhat, nem látom, hol segít az, ha ezek közül véletlenszerűen 1 megjelenik a sorokban.Egyébként a lekérdetzéseid 1-2 ms alatt lefutnak, nem értem, mit akarsz még optimalizálni rajtuk. Ami jól működik, azt nem kell megjavítani.
-
cucka
addikt
válasz
Briganti
#1965
üzenetére
Valami hasonló esetleg?
select cikkek.* from cikk_tag left join cikkek on (cikk_tag.cikk_id=cikkek.id) group by cikkek.id
vagy
select * from cikkek where exists (select * from cikk_tag where cikk_tag.cikk_id=cikkek.id)Amennyiben a kulcsok indexelve vannak (primary és foreign egyaránt), mindkét lekérdezés elég gyors lesz.
-
#1918
cucka
addikt
Sk8erPeter
#1917
cucka
addikt
válasz
Sk8erPeter
#1917
üzenetére
Eszerint MyISAM storage engine-nél ne is próbálkozzak ilyesmivel, ugye?
Elképzelhető, hogy működik MyISAM-al is, nézd meg a doksit. Egy korábbi munkahelyemen készítettünk olyan adatbázis réteget, ami tudta a tranzakciók kezelését függetlenül attól, hogy az adott myslq táblák milyen storage engine-el voltak létrehozva.Csak úgy értettem, nem állhat-e elő mégis az az eset, aminek minimális az esélye, hogy két kérés esetén épp ugyanakkor próbálnak írni az adatbázisba, ezért a lock-olási folyamat megkergül
Nincs, ezt a problémát minden adatbázis kezelő rendszerben megoldották már szerintem, különben nem lenne üzembiztos a használatuk.Ilyenkor van egy bizonyos timeout idő, amíg vár a sorára, majd amikor már nincs lock-olva a tábla, végrehajtja a feladatot, igaz?
Igen, de ezt az adatbázis szerver intézi, szóval nem kell vele foglalkozni. -
#1916
cucka
addikt
Sk8erPeter
#1914
cucka
addikt
válasz
Sk8erPeter
#1914
üzenetére
ez miért fontos igazából? Mitől jobb az InnoDB, mint mondjuk a MyISAM, stb.?
Már írták előttem, a legfontosabb különbség, hogy az innoDB a tábla 1-1 sorát lock-olja insertnél, míg a MyISAM az egész táblát. Ha nagy forgalmú oldalnál és/vagy nagy méretű adatbázis tábláknál számít.Érdekes, localhoston phpMyAdminban (2.10.3) nem is látom most az opciók közt ezt a lehetőséget...
Az innoDB támogatást be kell kapcsolni a MySQL-ben, alapból ki van kapcsolva. Nem tudom, milyen MySQL-t használsz, de még az is előfordulhat, hogy bele se fordították az innoDB támogatást, ekkor értelemszerűen be se fogod tudni kapcsolni
.Mi történhet konkurrens írási kísérletnél?
Igazából olyan nincs, hogy konkurrens írás, egyszerre csak 1 írási művelet végződik, a többiek pedig várnak a sorukra. -
cucka
addikt
válasz
RedSign
#1911
üzenetére
16000 sor nem sok, igazából 160ezer se az, de ez persze attól is függ, hogy hogyan szeretnéd használni a táblát. Jelen esetben a válaszok táblában lesz 1 id mező, 1 user_id mező, egy kérdés_id mező és maga a válasz. Az id, user_id és kérdés_id mezőre készítesz indexet és a táblát innoDB engine-el tárold. Így kiértékelésnél (ahol user_id és/vagy kérdés_id szerint kérsz le pár sort) villámgyors lesz, az indexek miatt szinte azonnal meg fogja találni, hogy a több százezer sorból mely 20-30 sort adja vissza. Új válasz felvitelénél pedig az innoDB miatt nem fogja lockolni a táblát, tehát zavaró mellékhatások nélkül lesz ideje újraszámolni az indexeket.
(Feltételezem, hogy nem lesz százezres napi látogatottsága az oldalnak, így a fenti megoldás megfelelő teljesítményt fog nyújtani) -
cucka
addikt
válasz
RedSign
#1907
üzenetére
Kell egy tábla a felhasználóknak, meg egy a csoportoknak. A felhasználó pontosan 1 csoportba tartozik, tehát van neki csoport_id-ja.
Kell egy tábla a teszteknek, egy a teszt kérdéseknek, és egy a válaszoknak. A táblák közötti kapcsolatok nyilvánvalóak, tehát ha egy teszt egy csoporthoz tartozik, akkor a teszt táblában lesz egy csoport_id, vagy például egy válasznak lesz felhasználó_id-ja és kérdés_id-ja, és így tovább.A te ötleted, miszerint a válasz táblában ömlesztve tárold a kérdésekre a válaszokat, szerintem bohóckodás, túl sok értelme nincs. Esetleg úgy lehet értelme, ha a válaszokat feldolgozó php script számára könnyen kezelhető módon, serializálva tárolod a válaszokat a táblában.
-
cucka
addikt
Szerintem erre egy egyedileg elkészített script a megfelelő megoldás, nem tartom valószínűnek, hogy találnál olyan általános célú szoftvert, ami egy egyedi weboldalnál a megfelelő adatokat a megfelelő struktúrájú adatbázisba tudná menteni. Az előző hozzászólásban említett program annyit tud, hogy "bejárja" a weboldalt és lementi az egészet html formátumban, plusz minden mást, ami hozzá tartozik (képek, css, stb.), de ez elég távol áll attól az igényedtől, hogy az adatokat valamilyen strukturált formában kapd meg.
-
#1751
cucka
addikt
Speeedfire
#1750
cucka
addikt
válasz
Speeedfire
#1750
üzenetére
Azért, mert a ckeditor által küldött szövegben vannak html tag-ek is a szöveg közé ékelve (akár egy szavon belül is). Általában a like-os keresés is működik, de ha normálisan szeretnéd megcsinálni, akkor az általam vázolt megoldás jobb.
-
#1749
cucka
addikt
Speeedfire
#1748
cucka
addikt
válasz
Speeedfire
#1748
üzenetére
1. A ckeditor-t be tudod úgy állítani, hogy ne alakítsa át. Nézd meg a doksiját, rengeteg beállítási lehetősége van.
2. A keresett szöveget is átalakítot html kóddá és úgy keresel. Gondolom valamilyen php alkalmazásba szeretnél beilleszteni egy keresőt, ez esetben a htmlentities() függvényt használhatod.Amúgy a keresés már csak azért sem fog így működni, mert a ckeditor a szöveg mellett más html elemeket is eltárol. Kereséshez érdemes eltárolni minden cikkről a nyers szöveges változatot (tehát html tag-ek nélkül) és abban keresni. Ehhez a strip_tags() nevű php függvény tökéletes.
-
cucka
addikt
Egyébként a szerver ugyanabban a formában tárolja az adatokat, mint ahogy .sql-be le lehet menteni myadmin-ból?
Nem. A MySQL binárisan tárolja az adatokat, az sql-ben történő mentés pedig egy sql scriptet eredményez. Amúgy ezt hogy képzelted, hogy az adatbázis file-jában "insert into.." sorok találhatók és azokban vannak az adatok, amin dolgozik a mySQL?
A phpmyadmin-ban amúgy írja, hogy melyik tábla mennyit foglal. 50 mega nagyon sokra elég, ha mégis kifogysz a tárhelyből, akkor pedig majd szólsz a rendszergazdának, hogy többre van szükséged, szóval kár ezen pörögni.Minden cikknek, és képnek külön táblája legyen, ahol a hsz-ek vannak, a pontszámokat meg külön táblában tároljam?
Kell egy cikk tábla, benne egy id mezővel, ami azonosítja a cikket.
Kell egy képek tábla, amiben van egy cikk_id mező, ami megmondja, hogy melyik cikkhez tartozik az adott kép.
Kell egy hozzászólás tábla hasonlóan a képekhez.A pontszámokat tárolhatod egy külön táblában (ilyenkor eltárolod az összes szavazás értékét). A másik megoldás, hogy a cikk táblába lerakod az átlagot és a szavazatok számát, új szavazatnál ezt frissíted.
Kb. ennyi. Így minden cikkhez tetszőleges számú képet és hozzászólást tudsz eltárolni.
-
#1589
cucka
addikt
Louloudaki
#1587
cucka
addikt
válasz
Louloudaki
#1587
üzenetére
Nem lesz gyorsabb.
-
#1582
cucka
addikt
Fire/SOUL/CD
#1581
cucka
addikt
válasz
Fire/SOUL/CD
#1581
üzenetére
A mysql egy szoftver, amelyhez csatlakozol és utána lekérdezéseket tudsz rajta futtatni. Az adatbázisokat file(ok)ban tárolja, de azokat direktben nem kezelheted, mert azokat a mysql tartja rendben.
Mysql adatbáziskezeléshez rengeteg tutorialt találsz a neten. Csatlakozáshoz szükséged van - hostnévre, vagyis hol található az adatbázis. Általában lokálisan, akkor nem kell megadni, de lehet, hogy a rendszergazdád map-olta az egészet, ekkor az általa megadott adatbázis host-ot használd.
- felhasználónévre
- jelszóra
- az adatbázis nevére, amit használni szeretnél.Kérd meg a rendszergazdát, hogy állítsa be normálisan azt a szervert és adja meg ezeket az adatokat.
Amúgy meg lehet kérdezni, hogy milyen hosting szolgáltatóról van szó? Szeretném tudni, hogy kiket kerüljek el jó messzire. Természetesen inkább privátban, ne rontsuk mások üzletét. -
#1579
cucka
addikt
Fire/SOUL/CD
#1578
cucka
addikt
válasz
Fire/SOUL/CD
#1578
üzenetére
Mysql-ben a felhasználóknál be lehet állítani, hogy honnan csatlakozhat az adatbázis szerverhez. Pl. ha egy gépen van a php és a mysql, akkor jellemzően localhost-ra van korlátozva, így távolról akkor sem lehet elérni az adatbázist, ha megvannak a belépési adatok. Az első hibaüzenet pontosan ezt jelenti, hogy nem a felhasználónál megadott host-ról próbálsz csatlakozni.
A másodiknál gondolom a felhasználónévvel vagy a jelszóval van baj.
Amúgy ütném pofán azt a rendszergazdát, aki magyar nyelvű mysql-t telepít. Az angol hibaüzenetre rákeresel google-ben és 1 perc alatt megtalálod a megoldást.
-
cucka
addikt
válasz
attis71
#1576
üzenetére
A blob mező bináris adatok tárolására alkalmas, tehát a te esetedben a kép file teljes tartalma kerül bele.
Amiért nem javaslom:
- általában a mysql adatbázisok mérete korlátozott, könnyen elérheted a limitet
- külön programot kell írni, ami a bináris adatból böngésző számára megjeleníthető képet készít. Más header-öket kell elküldeni, mert az alapértelmezett text/html content type-al a böngésző nem fogja képként megjeleníteni a bináris adatokat.Másik kérdés, ha fájl-ként tárolom az mysql adatbázis mellett, akkor egy lekérdezésnél előtudja Nekem hívni azt (megjeleníteni)?
Az adatbázisban vannak táblák, benne sorok, oszlopok. Lekérdezésnél a sorokban található adatokat tudod kiszedni. Tehát ha a tábládban van egy oszlopod, amiben a filenevet tárolod, akkor a filenevet fogod visszakapni. Értelemszerűen ha a böngészőben ezt képként szeretnéd megjeleníteni, akkor a filenevet bele kell rakni egy <img> tag-be. -
#1574
cucka
addikt
vincent001
#1573
cucka
addikt
válasz
vincent001
#1573
üzenetére
a mysql_connect után a következőket:
mysql_query('set names utf8');
mysql_query('set character set utf8'); -
#1572
cucka
addikt
vincent001
#1571
cucka
addikt
válasz
vincent001
#1571
üzenetére
És a táblákban a szöveges mezők? Azokat is be kell állítani.
A php kódodban pedig a mysql_connect() után közvetlenül add ki ezt a két query-t:set names utf8;
set character set utf8;Természetesen ha más karakterkódolást szeretnél használni (amit nem javaslok), akkor utf8 helyett azt kell beírni
-
cucka
addikt
válasz
attis71
#1568
üzenetére
Lehetséges, a mySQL-ben van blob típus (többféle is), ott tárolhatod. Amúgy a feladatot megoldhatod úgy is, hogy a feltöltött file-okat egyszerű file-ként tárolod a szerveren, az adatbázis tábládba pedig csak a file neve illetve a plusz adatai kerülnek be (pl. ki töltötte fel, mikor töltötte fel, stb.), én első körben így csinálnám.
-
#1569
cucka
addikt
vincent001
#1567
cucka
addikt
válasz
vincent001
#1567
üzenetére
Karakterkódolási probléma, egész pontosan akkor történik ez, ha utf8-as kódolású szöveget szeretnél berakni egy latin1-es vagy latin2-es táblába.
Állítsd át az adatbázis tábláid és a táblákban található mezők karakterkódolását utf8-ra. -
#1565
cucka
addikt
vincent001
#1562
cucka
addikt
válasz
vincent001
#1562
üzenetére
Az sql insert lekérdezésedet irasd ki és meglátod, hogy a php kódod szar, vagy a mysql-el van valami..
Esetleg idemásolhatnád a kérdéses kódot is, mivel látatlanban meglehetősen nehéz segíteni. -
#1554
cucka
addikt
Louloudaki
#1552
cucka
addikt
válasz
Louloudaki
#1552
üzenetére
Nem.
Bejelentkezésnél bizonyos verziókban be lehet állítani a karakterkódolást és a nyelvet egy legördülő listából. Ugyanakkor valószínűsítem, hogy az általad írt beállítások is ugyanezt szolgálják.Esetleg nézd meg a böngésződben, hogy milyen karakterkódolással jeleníti meg az oldalt, lehet, hogy ott lesz a probléma. Ha az is stimmel, akkor valószínűleg tényleg az adatok rosszak a tábláidban.
-
#1551
cucka
addikt
Louloudaki
#1549
cucka
addikt
válasz
Louloudaki
#1549
üzenetére
Phpmyadmin-ba való bejelentkezésnél általában meg lehet adni a nyelvet és karakterkódolást. Nyilván, ha iso-8859-x van beállítva, akkor az utf8-as 2 byte-os karakterek szarul fognak megjelenni.
-
cucka
addikt
Ha megvannak az adatok, miért kell beilleszteni az adatbázisba azért, hogy kiszedd őket?
Az insert nem tér vissza semmilyen sorral, mert az új sor hozzáadására való.
További probléma, hogy az sql-ben minden olyan értéket, ami nem szám, sima idézőjelek közé kell rakni. A te lekérdezéseidben nem figyelsz erre. A lekérdezéseid szintaktikai hibásak. Mivel nem kezeled le a hibát a mysql_query-nél, ezért később kapod a hibát, amikor szeretnéd a query eredményét kiszedni egy tömbbe.Javaslom, vegyél valamilyen php/mysql alapú fejlesztéssel foglalkozó könyvet.
-
cucka
addikt
Mysql-ben stringekre varchar-t használunk, nincs sok értelme nchar-t használni. (Az nchar annyival több, mint a sima char, hogy alapból utf8-as kódolású, hacsak a rendszergazda át nem állította ezt a beállítást). [link]
Set names, set character set és hasonlókat minden esetben közvetlenül a mysql_connect után add ki egyszer. (Tehát nem minden egyes query előtt) -
-
cucka
addikt
Általában az ilyen cégeknek van php5/mysql 5 alapú rendszerük is, csak kérni kell. Ha nincs nekik, akkor alapból komolytalan a cég, nem érdemes semmit sem tartani a szervereiken.
Amúgy rengeteg a szarul megírt weboldal, ami nem is működne php5/mysql5-ben, ezért kénytelenek foglalkozni php4/mysql4-el is.A set names pedig valóban a kapcsolat karakterkódolását határozza meg, és azért kell beállítani, mert a mysql szerverek többségét úgy állítják be, hogy latin2 legyen a default karakterkódolás. (Vagy esetleg be sem állítják, és akkor marad a default svéd nyelvű kódolás..)
-
cucka
addikt
Tovább olvastam a topikot..
Miután a php-ban csatlakozol az adatbázishoz, futtasd le a set names utf8 query-t.
A char-varchar különbséget kipróbáltam, nálam jó.
Ugye nem valami ősrégi mysql-t használsz? 4.valahányas verzió előtt a varchar hosszát nem karakterekben, hanem byte-okban mérte.
Esetleg utf8_unicode_ci helyett próbálj utf8_general_ci kódolást használni. Unicode-osat soha nem használtam még, de a general-al még nem voltak ilyen problémáim, mint neked. -
cucka
addikt
Char helyett használj varchar típust a szöveges mezőknek.
A char előre lefoglalja a megadott karakterszámnyi helyet. A gond valószínűleg az lesz, hogy egy utf8 karakter 1 vagy 2 byte-ot foglalhat, a mysql pedig 1 byte-al számol, amikor előre lefoglalja a helyet. (Ezt igazából nem próbáltam, szóval lehet, hogy más lesz a gond, de logikus magyarázatnak tűnik ) -
cucka
addikt
- először beolvasom az öszeset mysql_query-vel, és utána mysql_fetch_array-el listázom,
vagy
- már a mysql_query-vel is csak annyit olvasok be, amennyit ki akarok írni?
Értelemszerűen ha van 1 millió sorod és csak 30-at akarsz kiírni, akkor nem kéred le az összeset az adatbázisból.A kérdés, hogy hogy érdemes rendszerezni a képeket, hogy a szervert ne terhelje nagyon.
Ahogy jól esik. Szerinted tényleg az terheli a szervert, hogy egy könyvtárban 100 vagy 200 kép van? Amíg nincs 10-20ezer képed, addig kár ezen pörögni, bőven elég, ha logikusan gondolkozol és jó kódot írsz.
Egy átlagos webszervert egy ésszerűen megírt, párezer soros adatbázisból és párszáz képből álló oldal kb. egyáltalán nem terhel le, szóval ne pazarold az idődet arra, hogy azon agyalj, mi mennyire terheli a gépet. -
cucka
addikt
Szerintem ezt oldd meg két lekérdezéssel - az egyikkel csak annyit kérdezel le, hogy hány sor van, a másikkal meg a listázáshoz szükséges adatokat szeded ki.
A sorok számát általában nagyon gyorsan megmondja a mysql, tehát nem ettől lesz lassú a weboldalad.
Amúgy biztos meg lehet egyben is csinálni, de sanszos, hogy gyorsabban lefut a két külön lekérdezés, plusz minél egyszerűbb a kód, annál jobb -
#1487
cucka
addikt
.:GoliBali:.
#1486
cucka
addikt
válasz
.:GoliBali:.
#1486
üzenetére
[link]
Hirtelen ezt találtam, a példa kód minősége mondjuk erős közepes, de kiindulásnak jó lesz. -
cucka
addikt
A fordfairlane által írt kód alapján indulj el.
Kicsit átfogalmazom. Van egy regisztrációs folyamatod, amit mondjuk képzelj el úgy, mint egy windows-os varázslót. Első állapotában ott a regisztrációs űrlap, második állapota a regisztrációs folyamat vége. Ha az űrlapot hibásan töltöd ki, a varázsló nem ugrik át a második állapotra.Sematikusan így néz ki a reg.php
//post-olt adatok ellenőrzése, amennyiben már nem regisztrált a tag
$eredmeny = (empty($_SESSION['regisztracio_sikeres']) ? adatok_ellenorzese($_POST) : true;
if ($eredmeny===true){
// az adatok jók, tehát berakod a regisztráló tag adatait az adatbázisba
adatok_mentese();
//elmentjuk a session-ben, hogy már sikerült az adatbázis
$_SESSION['regisztracio_sikeres']=1;
//kiirjuk a "kikuldtuk a szöveget" html-t
require('regisztracio_vege_sablon.php');
} else {
//kiirjuk a regisztracios urlapot.
require('regisztracio_urlap_sablon.php');
}A regisztrációs űrlap a korábbi adatellenőrzés, a $_POST vagy a session alapján találja ki, hova milyen hibaüzenetet kell írni (ha kell egyáltalán). Sablon alatt itt azt kell érteni, hogy ott csak html kód, illetve a html kód megjelenítéséhez szükséges php részek vannak, maga az adatfeldolgozás nem.
A kódot igyekeztem érdekesre venni, a ?: és az === operátornak, az empty függvénynek, az include és a require közötti különbségnek nézz utána. -
cucka
addikt
Azért ugyanoda, hogy pl. a reg.php újratöltésekor (F5) ne regeljen mégegyet, és ne is fárassza a felhasználót azzal a szöveggel, hogy már foglalt a név, inkább legyen üres a sok mező
Session-ben eltárolod, ha sikerült a regisztráció. A fárasztó üzenetek csak akkor jelennek meg, ha a session-ben nincs meg a kérdéses érték.Ott tartok, hogy megy a reg, POST-al átadom a cuccot a ment.php-nak, és ha valami gebasz van, akkor a ment.php beinclude-olja a form-ot tartalmazó php fájlt (ami őt meghívta) és egy globális változó segítségével visszaadom neki, hogy mely hibaüzeneteket kell kiírnia.
A reg.php adatait lehetőleg a reg.php-val ellenőrizd. Ha az ellenőrzés sikerült, akkor include-al a "sasold a mailed" oldalt rántod be, különben a regisztrációs űrlapot.Amiben viszont most elakadtam, hogy hogy tudom az ellenőrzés után visszaírni a mezők adatait a helyükre
Mezők kiírásánál megnézed, ott van-e a POST-ban a korábbi érték, ha igen, akkor beírod az értéket az űrlap elem megfelelő részébe. Ha bonyolult a navigáció (pl. több oldal megtekintése után is visszakeveredhetsz az űrlapos oldalra, és akkor is ott kell legyen az utolsó állapot), akkor pedig az elpost-olt adatokat rakd le a session-be, az űrlapod pedig mazsolázza ki onnan a rá vonatkozó adatokat.Lehetőleg úgy akarom megoldani, hogy fürge legyen az oldal, és ne terhelje a szervert a kelleténél jobban.
Ezen egyelőre ne görcsölj szerintem, a fentiek alap műveletek, szerver terhelésük konvergál a nullához.Ja, és alap jótanács - a session-t lehet bátran használni, sok dolgot könnyebb vele megoldani, mint mindenféle trükközéssel.
-
#1479
cucka
addikt
.:GoliBali:.
#1476
cucka
addikt
válasz
.:GoliBali:.
#1476
üzenetére
Session-el lehet megoldani, a session-ről szóló netes tutorial-ok és a php-val foglalkozó könyvek szinte kivétel nélkül beléptető rendszert hoznak fel példának, szóval sok sikert
Természetesen ha van kérdésed, arra biztos fog válaszolni valaki, de nem hiszem, hogy bárkinek lenne türelme n+1.-szer is leírni ugyanazt a 3-4 oldalnyi magyarázatot arról, hogy hogyan kell nulláról megcsinálni. -
#1478
cucka
addikt
fordfairlane
#1477
cucka
addikt
válasz
fordfairlane
#1477
üzenetére
Egyetértek, teljes form feldolgozás és validálás ajax-al (főleg 19 elemű formra) tömény szívás, tehát egyszerű példa alapján kevés háttértudással elég necces belevágni.
-
cucka
addikt
A form-okkal nem értem, mit akarsz kezdeni. HTML-ben a formok úgy működnek, hogy küldéskor a form action-jében megadott url-je töltődik be. GET típusú űrlap esetén az url-hez hozzá lesznek csapva az űrlap változói, POST típusú űrlap esetén a HTTP üzenet POST részében lesznek megtalálhatók. Tehát jól látod, bármely HTML űrlap elküldése mindenképp oldal újratöltést fog eredményezni.
Az ajax általánosan úgy működik, hogy az oldal "megtekintése közben" egy url-re elküld valami adatot (ez mondjuk a php program, ami ellenőrzi, hogy helyesen töltötték-e ki az űrlapot). A php program visszaküld valami szöveget (ez tulajdonképpen a php program standard kimenete), amivel a javascript kódod csinál valamit (pl. az eredménytől függően kiírja, hogy jól töltötted-e ki az űrlapot vagy sem). Az ajax lényege, hogy ehhez nem kell újratölteni az oldalt, mert nem küldesz el semmilyen html űrlapot sehova.
Ha nagyon nem megy, később írok egy kis rövid ajax gyorstalpalót, amúgy is akartam valami közhasznút írni a logout-ra
-
cucka
addikt
Ezt meg lehet tenni úgy, hogy a második linken csinálják, vagyis, hogy mögé lehessen írni, hogy class=akármi...
Ezt nem értem, írhatsz elé-utána amit akarsz, de ha lefut a kérdéses esemény, akkor elküldi a form-ot, mint ha egy input type=submit-al küldted volna.Amúgy jobban megnéztem az első linkedet, hát azt sem ajánlom tutorialnak, a javascript kódjában nulla komment van, ráadásul a sima szabványos httprequest létrehozás helyett valami előre megírt, direkt olvashatatlanra alakított cuccot használ.
Most komolyan, így mi értelme a tutorialnak, ha a példa kódod direkt úgy van megcsinálva, hogy ne lehessen megérteni? Amúgy a hozzászólások is tök jók azon az oldalon, az emberek 98%-ának fingja nincs, hogyan működik a kód, de a legérdekesebb, hogy nem is nagyon érdekli őket. -
cucka
addikt
Az első megoldás ajax-os, abból lehet tanulni, csak ugye nem űrlapokkal dolgozik.
A másodikat kicsit erős tutorial-nak vagy cikknek nevezni. Annyit csinál, hogy amikor ráklikkelsz a linkre, a szövegdobozba írt szöveg alapján átirányít a search.php-ra.
Más szóval erről a negyed sornyi beágyazott javascript kódról szól a cikk, és amúgy semmi ajax nincs benne. (Ráadásul jó szarul is csinálja, mert elég lenne meghívni a form submit metódusát küldésre, és akkor menne POST-al is meg akárhány űrlapelemmel)Esetleg nézd meg ezt: [link]. A W3Schools-on is van javascript és ajax tutorial, azzal is lehet kezdeni.
-
#1466
cucka
addikt
fordfairlane
#1465
cucka
addikt
válasz
fordfairlane
#1465
üzenetére
Ha az egyik helyről eléred a másik adatbázist is, akkor korrekt.
Ha viszont nem éred el, esetleg univerzálisabb megoldást szeretnél, na akkor jön a sz*pás. Csináltam ilyen programot, megvalósítható, csak egyáltalán nem triviális (pl. odafigyelni a tranzakciókra, lekezelni a hibákat/megszakadt vonalat, stb.) -
cucka
addikt
Például itt egy Netpincér rendelés igazolás fejlécének spam-el kapcsolatos része. Ingyenes levelezőkkel nem tudom, mi a helyzet, olyannal nem teszteltem.
X-ELTE-VirusStatus: clean
X-ELTE-SpamScore: -0.4
X-ELTE-SpamLevel:
X-ELTE-SpamCheck: no
X-ELTE-SpamVersion: ELTE 2.0
X-ELTE-SpamCheck-Details: score=-0.4 required=5.9 tests=BAYES_00,SUBJECT_NEEDS_ENCODING,SUBJ_ILLEGAL_CHARS autolearn=no SpamAssassin version=3.2.5
1.1 SUBJ_ILLEGAL_CHARS Subject: has too many raw illegal characters
-1.5 BAYES_00 BODY: Bayesian spam probability is 0 to 1%
[score: 0.0000]
0.0 SUBJECT_NEEDS_ENCODING SUBJECT_NEEDS_ENCODINGAmúgy nyilván szerverbeállítás kérdése, hogy berakja-e ezeket a fejlécbe. Ha nagyon nem megy, küldd át a teszt levelet az adatlapomon látható címre és megmondom, mi a probléma a levéllel.
Mod: közben eszembe jutott, hogy jó lenne mutatni valami olyat, ami több ponton vérzik el a spamszűrőnél, szóval itt van egy valódi spam, amit hajszál híján megfogott a spamAssasin:
X-ELTE-VirusStatus: clean
X-ELTE-SpamScore: 5.7
X-ELTE-SpamLevel: sssss
X-ELTE-SpamCheck: no
X-ELTE-SpamVersion: ELTE 2.0
X-ELTE-SpamCheck-Details: score=5.7 required=5.9 tests=BAYES_50,HTML_MESSAGE,RCVD_IN_PBL,RCVD_IN_SORBS_DUL,RDNS_DYNAMIC,URI_HEX autolearn=no SpamAssassin version=3.2.5
0.4 URI_HEX URI: URI hostname has long hexadecimal sequence
0.8 HTML_MESSAGE BODY: HTML included in message
1.0 BAYES_50 BODY: Bayesian spam probability is 40 to 60%
[score: 0.5197]
2.5 RCVD_IN_SORBS_DUL RBL: SORBS: sent directly from dynamic IP address
[87.16.175.134 listed in dnsbl.sorbs.net]
0.9 RCVD_IN_PBL RBL: Received via a relay in Spamhaus PBL
[87.16.175.134 listed in zen.spamhaus.org]
0.1 RDNS_DYNAMIC Delivered to trusted network by host with
dynamic-looking rDNS -
cucka
addikt
A "szépség" alatt nem az esztétikát értettem, hanem hogy nem kezelted le, hogy a mysql_num_rows egyaránt visszatérhet false-al és 0-val is. Ettől még működőképes a kódod, valószínűleg soha nem fogod észrevenni a weboldal tesztelése során, hogy valami gond van vele, de ettől még nem 100%-osan helyes a fentiek miatt.
-
cucka
addikt
Például
select count(*) as cnt from tabla where nev='Rezső'
Pont ugyanannyira szerverkimélő, mint a te megoldásod, ugyanakkor rákényszerít a lentinél szebb php kód írására
Konkrétan azzal a mysql_num_rows-al van a baj:
Egyrészt így nem fog működni, mert meg kell adni neki a mysql_query által visszaadott resource-t. (jelen esetben a $eredmeny-t)
Másrészt ez a függvény egyaránt visszatérhet 0-val (nincsenek sorok) vagy false-al (hiba történt). Ha így rakod be a feltételbe, akkor mindkét esetben false-ra fog kiértékelődni, tehát a hibás esetet nem kezelted le. A felhasználói oldalon meg annyit látsz majd belőle, hogy bármit írsz be, el fogja fogadni, mint érvényes felhasználónév. -
cucka
addikt
Concat függvény.
select * from tabla where concat(mezo1,mezo2,mezo3) like '%szoveg%'
Nem a legjobb megoldás, nagy adatmennyiség esetén elég lassú lesz, de kis forgalmú oldalakhoz megteszi ez is. Ha ennél több kell, lehet trükközni, pl. létrehozni egy mezőt, amiben ott van az adott rekord összes szöveges adata és abban a mezőben keresni - ekkor a rekord beszúrásánál/frissítésénél ezt a mezőt is frissíted, cserébe megspórolod a concat-ot. Ezen kívül lehet cache-elni a kereséseket külön táblában, stb. Erre nincs igazából szabály, kreatívnak kell lenni.
-
cucka
addikt
Úgy, hogy átalakítod html-es sortöréssé (vagyis <br> ). Erre van a nl2br() függvény, de str_replace()-el is könnyen megoldható.
HTML-ben akárhány whitespace karaktert egymás után rakhatsz, mindig csak egy fog belőle látszani. Ez azért van így, hogy rendesen tudd tördelni a html kódot anélkül, hogy a böngészőben látható oldalon gondot okozna. -
cucka
addikt
azért mert a print függvény arra való, hogy a képernyőre kiírj dolgokat. a print visszatérési értéke mindig 1, ez kerül a $ido változóba, majd ezt rakod be a táblába.
sőt, hogy egészen pontosak legyünk, a print valójában nem is függvény, de függvényként is meg lehet hívni, ekkor lesz ugye visszatérési értéke.
-
cucka
addikt
de, valamennyivel biztos lassabb, bár nem hinném, hogy számottevő lenne a különbség.
ha 1 text mezőben tárolod a 220 oszlopot, akkor annak a kezelhető formára hozása is időigényes. egyébként ha nem extrém terhelésre készíted az alkalmazásodat, akkor kb. teljesen fölösleges ilyen apró sebességkülönbségek miatt szenvedni egy rossz, nehezen kezelhető, átláthatatlan kóddal. -
cucka
addikt
a kis függvény semmi mást nem csinál, csak megkímél attól, h minden lekérdezésnél oda kelljen rakni a set name-es cuccot, meg a hibakeresést.
mysql_connect után elég egyszer lefuttatni azt a set names részt, fölösleges terhelés minden egyes query előtt.
(#1286) föccer a jegyzettömb nem tud utf8-ba menteni (meg igazából semmilyen mód nincs rá, hogy beállítsd a karakterkészletet), használj olyan szövegszerkesztőt, amelyik tartalmaz ilyen funkciókat.
karakter-kódolásos kavarodás elkerüléséhez a következőket csekkold le
- a html lap meta részében beállítottad a kódolást utf8-ra
- a html lap tartalma utf8 kódolású
- php-ban set names futtatása connect után
- adatbázisban a táblák utf8-as kódolásúak
ha ez mind megvan, akkor működnie kell
[Szerkesztve] -
cucka
addikt
nem túl érthető, hogy mi a túrót akarsz. érdemi segítséghez ne a html-es űrlapodat meg a mysql_connect-eded pakold ide, hanem próbálj értelmesebben fogalmazni.
egyébként szerintem ott akadtál el, hogy
a) nem tudtál felépíteni egy normális fát az adatbázisban.
b) nem tudod bejárni a fát.
a)-hoz: van a személy táblában egy személyed (vagyis 1 sor a táblából), neki van egy apa_id-ja meg egy anya_id-ja, ami szintén ugyanennek a személy táblának 1-1 sorára mutatnak, oszt kb. ennyi.
b) rekurzívan szépen bejárod a fát. -
cucka
addikt
ha hiba van a query-vel akkor ugye azt a mysql_query visszatérési értéke jelzi. (az az ''or die'' rész pont erre van).
ha azt akarod tudni, hogy hány sort ''talált'' a query, de nem akarsz lekérni egyet sem, akkor mysql_num_rows (vagy mysql_affected_rows, nézd meg a manualt, hogy mi a különbség köztük.)
másik megoldás, hogy ugye a mysql_fetch függvények false-al térnek vissza, ha nincs több sor, ha amúgy is lekérnéd az eredményeket, akkor ezt is használhatod.
mod: és erősen ellenjavallott beírni ide a fórumba az extrás jelszavadat
[Szerkesztve] -
cucka
addikt
stringeknél a '' annyival több, mint a ', hogy
- behelyettesíti a változókat és az objektum adattagokat
- behelyettesíti a tömb elemekre való hivatkozásokat, ha azok { } között vannak megadva
- behelyettesíti a speciális karaktereket (pl. újsor \n vagy tabulátor \t )
- ha nem kell semmit behelyettesíteni, akkor nem okoz lassulást a használata mérések szerint a ' '-vel megadott string-ekhez képest. (ez furcsa, de volt valami teszt a neten és ott ez jött ki)
[Szerkesztve] -
cucka
addikt
kiváncsiságból megnéztem a kódot, két építő jellegű észrevétel:
- a 10 soros dátumos szórakozás helyett nézd meg a date() függvényt, azzal 1 sorban megkapod azt, amivel itt fél oldalon keresztül küzdesz.
- ha már '' '' közé rakod a string-eket, akkor használd ki, hogy ezekbe a php automatikusan behelyettesíti a változók értékeit. például
''szoveg '' . $valtozo . '' szoveg'' helyett írhatsz
''szoveg $valtozo szoveg'' -et, amit jóval egyszerűbb elolvasni és szebb is, mint a sorminta string összefűzésekből.
mod: és a tömbös kérdésedre a válasz: törekedj arra, hogy a kapott sorokat mysql-ben szűrd le, mert az lényegesen gyorsabb (főleg ha indexelt oszlop szerint szűrsz, mert azt megcsinálja ~logaritmikus időben) és a kevés sort tartalmazó szűrt eredményt dobd át a php-nek. ez jobb, mint hogy rengeteg adatot átküldj a db kapcsolaton keresztül a programodnak, ami előbb mindnek memóriát kell foglaljon, aztán pedig futtatsz rajta egy lineáris keresést és végeredményben az adatok többségét kidobod a kukába.
[Szerkesztve] -
cucka
addikt
a phpmyadmin egy php-ban írt szoftver amellyel mysql adatbázisokat tudsz kezelni, gyakorlatilag egy olyan webes eszköz, amivel az adatbázisokat tudod matatni.
természetesen a szerveren fut, te böngészőből tudod elérni. próbáld ki és rájösz, hogy mire jó, konkrétan weboldal adminisztrálásához nem igazán megfelelő. -
#1210
cucka
addikt
--=Gefi=--
#1208
cucka
addikt
válasz
--=Gefi=--
#1208
üzenetére
nézd meg mondjuk az ipon webshopját. ha valami hasonlóan teljeskörű megoldást szeretnél, akkor bizony lesz annyi tábla. (persze gányolással redukálható a táblák száma, de nem éri meg szerintem)
tudom, időközben kiderült, hogy az eredeti kérdés egy sokkal egyszerűbb feladatra vonatkozott, ahova valóban felesleges az általam felvázolt brutál megoldás.
[Szerkesztve] -
cucka
addikt
válasz
szabi6k
#1205
üzenetére
ötlet még annyi, hogy használj valamilyen grafikus-egeres adatbázis-tervező progit. ha ezt a hardveres adatbázist rendesen meg szeretnéd csinálni, akkor simán lesz 70-80 táblád, ezt átlátni nehézkes.
(plusz ezek az adatbázis-tervező progik tudnak sql-t gyártani a modelledből, tehát még 1 probléma kilőve) -
#1204
cucka
addikt
Louloudaki
#1203
cucka
addikt
válasz
Louloudaki
#1203
üzenetére
ez azért nem jó így, mert eltérő termékcsoportoknak eltérő tulajdonságai vannak, pl. processzornak frekvenciája, monitornak meg felbontása. szerintem valami hasonló kéne legyen:
vannak tulajdonságok és vannak termékek. a tulajdonságok lehetnek közösek (minden termékcsoportra jellemző, például hogy hány év garancia van rá) illetve egyediek (lásd a fenti példát). egy ilyen tábla így néz ki:
felbontas
id: int (primary key, autoinc)
nev: varchar
minden termékcsoportnak van egy táblája, ami valami hasonló (persze több adattal, ez itt csak egy rövid példa):
monitor
id: int (primary key, autoinc)
gyarto_id: int (fk)
tipus: varchar
monitor_meret_id: int (fk)
felbontas_id: int (fk)
ar: int (not null)
értelemszerűen minden külső kulcs (fk) az adott tulajdonság táblára mutat. így rengeteg tábla lesz, viszont előnyös oldalai is vannak a dolognak. tegyük fel, hogy az oldaladon van egy kereső, amelyikben egy legördülő menüből kiválaszthatod, hogy mekkora monitort keresel és ezt a legördülőt a rendszer a monitor_meret táblából tölti fel. namost ha a boltba érkezik egy új méretkategóriájú monitor, akkor elég lesz felvinni a monitor_meret táblába az új méretkategóriát és onnantól az egész rendszeredben használható lesz. a legjobb ebben, hogy akár a titkárnő is fel tudja vinni ezt, ha adsz neki valamilyen eszközt erre (adminisztrációs felület). -
#1018
cucka
addikt
Forest_roby
#1016
cucka
addikt
válasz
Forest_roby
#1016
üzenetére
pedig az a select elvileg jó kell legyen. ha esetleg megmutatnád, hogy pontosan hogyan lett átírva, akkor az segítene abban, hogy érdemi választ adjak..
-
#1014
cucka
addikt
Forest_roby
#1013
cucka
addikt
válasz
Forest_roby
#1013
üzenetére
komment mellé a user_id-t tárold el, ne a usernevet, így az külső kulcs lesz. ezen kívül nagyon-nagyon melegen ajánlott, hogy oszlopoknak ne adj olyan nevet, ami foglalt szó (pl. a date).
több táblából select:
mondjuk select commentek.comment, commentek.date, commentek.user_id, userek.user_nev from commentek left join userek on (commentek.user_id=userek.user_id); -
cucka
addikt
nem értem pontosan, mit értesz hirdetési felület alatt.
ha mondjuk van az oldaladon 3-4 bannernek hely és a bannerek egyszerű hivatkozások (mondjuk animált gif-re vagy flash-re), akkor simán mehetnek egy táblába. a táblához hozzáadsz egy hirdetesi_felulet_id oszlopot, és az alapján szűröd a tábládat. ha kulturált admin felületet akarsz, mondjuk új hirdetés hozzáadásánál legördülő dobozból lehessen kiválasztani, hogy hova kerüljön az a banner, akkor csinálhatsz egy hirdetesi_felulet táblát, ahol felsorolod a felületek neveit. ebben az esetben a fentebb említett hirdetesi_felulet_id oszlop külső kulcs lesz és a hirdetesi_felulet táblára fog mutatni. -
cucka
addikt
mit érdemesebb inkább használni, kevesebb táblát sok oszloppal, vagy több táblát kevés oszloppal?
normálisan megtervezett adatbázist érdemes használni. egy táblába logikailag összetartozó dolgok kerülnek (pl. a személy táblába a név, jelszó, mailcím, satöbbi). ha a személynek sok tulajdonsága van, akkor sok oszlop lesz, ez van.
logikailag különálló fogalmakat külön táblában tárolsz. például a személynek van rengeteg olyan tulajdonsága, amelyeket legördülő menüből választhat (ergo előre adott opciók közül választhat). például milyen színű a haja, melyik a legmagasabb iskolai végzettsége, stb. namost ha nagyon sok ilyen tulajdonsága lesz, akkor nagyon sok kis tábla lesz. máshogy is meg lehet oldani, de az valószínüleg rossz megoldás: nehezen érthető struktúra és kód, az egész karbantartása horror, vagyis összességében rossz adatszerkezet és ebből adódóan szar kód.
egyébként pontosan mi a felállás, aminek kapcsán feltetted a kérdést? milyen adatokat szeretnél tárolni? -
-
cucka
addikt
válasz
Briganti
#964
üzenetére
jójó, de ha simán csak két táblázatot kell egymás mellé rakni, akkor berakod a kettőt két dobozba vagy táblázat cellába és külön-külön kiírod őket, ez a normális megoldás.
ha a két táblázat funkcionálisan összefügg, akkor lehet értelme egyszerre kiírni a kettőt. na akkor tudsz írni join-os query-t amivel kiírod egy menetben.
a fapados megoldás két egymás utáni foreach-al megoldható. először az egyik sort írod ki táblázat cellá(k)ba, utána a másikat. -
cucka
addikt
válasz
Briganti
#962
üzenetére
szerintem a foreach szar így
van olyan, hogy array pointer, úgy érzem, hogy még nem hallottál róla, meg lehet azzal is oldani (each, current, next, reset, stb. függvények). mivel fetch_array-el szeded ki a sorokat, ezért azok számokkal lesznek indexelve 0-tól, tehát egy klasszikus for ciklussal is végigitetrálhatsz rajtuk. ha a két tábla között van kapcsolat, akkor pedig egyetlen sql lekérdezéssel is megoldhatod az egészet.
vagy szétszeded azt a foreach-et kettőbe.
pontosan mire lesz ez jó egyébként, akkor esetleg tisztább lesz, hogy mit szeretnél.. -
#892
cucka
addikt
Forest_roby
#891
cucka
addikt
válasz
Forest_roby
#891
üzenetére
pedig ott van. eszközök menüpont és utána klikk a mysql manager nevű gombra.
ez a hibaüzenet valami extrás helyi sajátosság lehet, tehát passz
[link] -
#890
cucka
addikt
Forest_roby
#889
cucka
addikt
válasz
Forest_roby
#889
üzenetére
igen, extrán van sqlite manager is, de azt még nem próbáltam, jó az a phpmyadmin.
(illetve annyira nem jó, de azért el lehet vele lenni. )
toad for mysql lenne a királyság. régebben próbáltam, akkor egy bug miatt nem működött nálam, lehet, azóta kijavították. -
#887
cucka
addikt
Forest_roby
#886
cucka
addikt
válasz
Forest_roby
#886
üzenetére
például a phpmyadmin-ra gondoltál?
az admin felületen az eszközök között találod mysql manager álnéven. -
#885
cucka
addikt
Forest_roby
#884
cucka
addikt
válasz
Forest_roby
#884
üzenetére
meg szabad kérdezni, hogy miért pont php-ból akarsz táblákat létrehozni? vannak erre jó adatbázis-matató eszközök, például a phpmyadmin, mysql query browser, elvetemülteknek meg a parancssoros kliens.
ha a query-d (bármilyen query) hibát ad, akkor azt meg tudod nézni a mysql_error() függvénnyel. ha nem ad hibát, akkor értelemszerűen lefutott. -
cucka
addikt
válasz
woodpaul
#876
üzenetére
kis pontosítás:
char - max. 255 hosszú lehet
varchar - 1 vagy 2 byte-on tárolja a karakterlánc hosszát, vagyis max. ~65ezer byte fér bele.
(2 byte-os karakterkódolásnál nyilván ennek a fele)
azt egyébként el tudnád magyarázni, hogy miért lenne gyorsabb a char mint a varchar? nem találtam erről semmi információt, és érdekelne.
[Szerkesztve] -
#870
cucka
addikt
Forest_roby
#868
cucka
addikt
válasz
Forest_roby
#868
üzenetére
1 - 1 sor. Milyen paramétereket érdemes eltárolni? ( count, nev, pass, mail, mégvalami? )
mindenképp kell egy id mező, amivel azonosítod a júzert. ez legyen primary key és célszerű, ha auto increment-es. kell még usernév, jelszó, ezen kívül pedig olyan adatok, amelyeket fel szeretnél használni. példa: ha minden szerző cikkje mellé oda akarod rakni a képét is, akkor kell majd egy mező, ahol eltárolod az illető kép nevét. (képet tárolhatod adatbázisban is, de ez nem feltétlenül jó megoldás)
kommenteket szintén illene indexelni, vagyis itt is lesz egy id mező (primary key, satöbbi), ezen kívül itt lesz a szerző id-ja, hogy tudd ki írta azt a cikket. ez egy foreign key és a users tábla id oszlopára mutat. ezeken felül pedig bármit eltárolhatsz a cikkhez, amit később fel akarsz használni, pl. szöveg, cím, bevezető, ilyesmi.. -
cucka
addikt
ennek így nincs sok értelme. :)
először is a #831-ben írt kódom hibás, count(*) helyett simán * kell a lekérdezésbe.
a védett oldalra való átirányítás előtt pedig a legegyszerűbb, ha a user összes adatát benyomod a session-be, mert amúgy sem túl nagy adatmennyiség.
például így.
if (mysql_num_rows($result)===0) header(''Location: login.php'');
else {
$_SESSION['user_adatok']=mysql_fetch_assoc($result);
header(''Location: vedett_tartalom.php'');
}
így a továbbiakban az isset($_SESSION['user_adatok'])-al tudod megnézni, hogy be van-e jelentkezve a user és ha például a user nevét szeretnéd kiírni valahova, akkor azt a $_SESSION['user_adatok']['nev'] fogja megmondani. -
cucka
addikt
nem értem, mi okoz ebben nehézséget :)
$user=mysql_real_escape_string($_POST['user']);
$jelszo=mysql_real_escape_string($_POST['jelszo']);
$result=mysql_query(''select count(*) from felh where user=$user and jelszo=$jelszo'');
if (mysql_num_rows($result)===0) header(''Location: login.php'');
else header(''Location: vedett_tartalom.php'');
die();
mod: későbbiekben érdemes lehet eltárolni a belépett user adatait, mondjuk session-ban, ilyen esetben count(*) helyett *-ot válassz ki a táblából, és mielőtt átirányítanád a védett oldalra, fetch-eld a result tartalmát és pakolgasd be a session-be a szükséges adatokat.
[Szerkesztve] -
#742
cucka
addikt
Realradical
#741
cucka
addikt
válasz
Realradical
#741
üzenetére
például a href=''oldalnev.php?topik_id=234''
az oldalnév.php-ban ilyenkor a $_GET['topik_id'] értéke 234 lesz. -
#740
cucka
addikt
Realradical
#739
cucka
addikt
válasz
Realradical
#739
üzenetére
a fórumokat/topicokat ne név alapján azonosítsd, hanem legyen mindegyiknek egy egyedi id-ja. akkor ugye linkre klikkelésnél get-el átadod a php-nak az illető id-t és utána az alapján matathatod az adatbázist.
(egyébként meg elég rossz ötlet szerintem egy fórumnál minden topiknak külön táblát fenntartani, lassú és bonyolult az egész karbantartása). -
cucka
addikt
válasz
Briganti
#736
üzenetére
ez esetben a programod elég sok sebből vérzik
1. url-t ne get-ben küldd át, mert vicces eredményeket kaphatsz. használj post-ot.
2. az insert rész úgy ahogy van rossz. először is nem új sort kell beszúrni, hanem meg kell növelni a view értékét az illető sorban, vagyis insert helyett update.
első ránézésre ennyi.
elegáns megoldás az lenne, hogy javascript-ből küldésnél küldesz egy httprequest-et a szerveren található php filenak, ami pedig megoldja a háttérben az adatbázis matatását (azt, hogy éppen mire kattintott a júzer meg mondjuk kiolvassa post-ból). -
cucka
addikt
válasz
Briganti
#734
üzenetére
egyrészt: debugolj lépésről lépésre. nézd meg az első query-det, figyeld meg mit csinál pontosan a programod. irass ki debug üzeneteket.
másrészt: ha kérdezel, akkor próbáld úgy tenni, hogy a többiek segíthessenek. itt egy nem dokumentált kód, amiről még annyit sem árultál el, hogy mire jó. mi van a $_GET[url]-ben? mit akarsz a $view-al csinálni? mire kell a $view++ sor? satöbbi satöbbi.
.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
=='127.0.0.1')
Aktív témák
Hirdetés
- Intel Core Ultra 7 265 /// Bontatlan, Teljesen Új // Üzletből, Számlával és Garanciával
- Csere-Beszámítás! Ryzen 9 9950X Processzor!
- Újszerű Gamer Asztali PC Számítógép 2026-ig Garis ASUS H510M-K R2.0 i5 11400F RTX 4060 8GB Dobozába
- Samsung Galaxy Tab A8 (2021) , 3/32 GB,
- Samsung Galaxy S6 Lite (2022) , 4/64 GB ,Wi-fi
- Tablet felvásárlás! Samsung Galaxy Tab S10+, Samsung Galaxy Tab S10 Ultra, Samsung Galaxy Tab S10 FE
- Okosóra felvásárlás!! Samsung Galaxy Watch 5 Pro, Samsung Galaxy Watch 6 Classic
- ÁRGARANCIA! Épített KomPhone Ryzen 5 5500 16/32/64GB RAM RTX 4060 8GB GAMER PC termékbeszámítással
- Bomba ár! Dell Latitude 7390 2in1 - i7-8G I 16GB I 256SSD I 13,3"FHD Touch I HDMI I Cam I W11 I Gar
- Telefon Felvásárlás!! iPhone 14/iPhone 14 Plus/iPhone 14 Pro/iPhone 14 Pro Max
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft
Város: Budapest
Cég: Promenade Publishing House Kft.
Város: Budapest