Új hozzászólás Aktív témák
-
trisztan94
őstag
válasz SirRasor #9984 üzenetére
Én sütivel csinálnám. Egy darab süti, ami mindig változik, ha változik a termék vagy a termékek száma.
Adatbázisos megoldást képzeld el 10.000 user esetében Leterhelné az egészet, míg a süti az a felhasználó gépén van, így nincs vele probléma
https://heureka-kreativ.hu
-
Sk8erPeter
nagyúr
válasz SirRasor #9984 üzenetére
"Webshopot készítek saját kútfőből."
Az jó móka lesz, sok sikert hozzá... Amúgy ha élesben is fogod használni, akkor inkább felejtős, rengeteg webshopmotor van, és túl kockázatos ujjgyakorlat gyanánt, tanulásként (vágod, itt konkrétan pénzzel és szenzitív adatokkal játszol), de ha hobbiból csinálod, és nem megy ki élesbe, akkor no para."PHP+CSS3+AJAX"
És hol az adatbázis?Az előttem szólóval vitatkoznék, nincs semmi gond az adatbázisba mentős megoldással. Így van lehetőség arra is, hogy legközelebbi bejelentkezéskor ugyanonnan tudja folytatni a vásárlását egy tök másik gépről bejelentkezve, ahol legutóbb abbahagyta. Bizonyos idő elteltével persze ezt érdemes üríteni cron jobként. Tárolod, hogy mikor történt a legutóbbi módosítás, és ha azóta már X idő eltelt, akkor törlöd a bejegyzéshez tartozó elemeket. Persze ezt értelmesen tárold el, kapcsolótáblákkal: például lenne egy kosártábla, meg egy kosártartalmat részletező másik tábla. Mindenhol csak azonosítókat tárolsz, pl. első táblában adott kosártöméshez tartozó egyedi azonosító, másik táblában kosártöméshez tartozó egyedi azonosító, termékazonosító. Vagy lehet még sok más módszerrel is. Ebben kérhetsz segítséget az adatbázishoz kapcsolódó topicban.
Szóval a lényeg, hogy ez a megoldás legalább nem géphez+böngészőhöz kötött.Természetesen ettől még tárolhatod sessionben is, vagy cookie-ban, ahogy érzed, de én biztos, hogy utóbbit például nem választanám.
Szerk.:
ja, és csatlakozom moltam88-hoz, a 10/20-as sessionös parádat én sem értettem.==============================
(#9985) trisztan94 :
"Adatbázisos megoldást képzeld el 10.000 user esetében "
Miért, 10 ezer bejegyzést nem bír el az adatbázis?
Amúgy meg ha 10 ezer felhasználó egyszerre vásárol, az már amúgy is az átlagosnál igencsak magasabb terhelésű szerver, ergo így is-úgy is elég komolyan fel kell készíteni a potenciális terhelés elbírására.
Nem az fogja hazavágni, hogy egy-egy bejegyzést beszúr vagy kiolvas, amikor a felhasználó rákattint, hogy berakja a kosárba a termékét.[ Szerkesztve ]
Sk8erPeter
-
válasz SirRasor #9984 üzenetére
Session használandó erre, a 10-20 problémát meg nem értem. Csak ugye készletváltozás következhet be vásárlás közben, így ezt figyelembe kell venni a további működés során.
@trisztan94: marha nagy terhelés lenne, főleg, hogy rengetegen adatbázisba tolják a session-t is.
-
fordfairlane
veterán
válasz SirRasor #10081 üzenetére
Első körben egy phpmyadminnal ellenőrizd, hogy a megfelelő betűk vannak-e benne az adattáblákban.
Ha csak kódbeállítási probléma lenne, akkor általában krikszkraxok jelennek meg a böngészőben az ékezets karakterek helyett. A kérdőjelek azt jelzik, hogy valószínűleg az adatbázis tartalmának konvertálása során az ékezetes karakterek elvesztek, mert olyan karakterkiosztásba eültek, ahol az adott karakterek nem ábrázolhatóak. iso-8859-2 (latin-2) után iso-8859-1 (latin-1) kódolás szokott ilyet okozni, és azután már hiába állítgatod a mezőket utf-8-ra, az elveszett adat nem kerül meg.
[ Szerkesztve ]
x gon' give it to ya
-
trisztan94
őstag
válasz SirRasor #10087 üzenetére
Nem az utf-8-al van a baj, az támogat szinte minden karakterkódolást, a magyart hiba nélkül. Az a nemzetközi karakterkódolás, nem a latin2.
Phpmyadminba adatbázis kollacióját, tábla kollacióját és minden sor kollacióját, hogy nincs-e valahol elállítva.
https://heureka-kreativ.hu
-
CSorBA
őstag
válasz SirRasor #10093 üzenetére
Én open-nél végrehajtom még ezt is:
"SET NAMES 'UTF8'";
"SET CHARACTER SET 'UTF8'";
"SET COLLATION_CONNECTION='utf8_general_ci'";
"SET character_set_results = 'UTF8'";
"SET character_set_server = 'UTF8'";
"SET character_set_client = 'UTF8'";Egy próbát megér még.
[ Szerkesztve ]
-
Sk8erPeter
nagyúr
válasz SirRasor #10093 üzenetére
"de még a bérelt szutyokban se láttam ilyen lehetőséget"
Ha a "bérelt szutyok" alatt a Tárhelyparkot érted, amit említettél korábban, akkor teljesen egyértelmű, hogy nálad van a hiba, és NEM a Tárhelyparknál. Ott ugyanis semmi probléma nincs az alapbeállításokkal. Van ott oldalam, és az ékezetes dolgok ékezetesen jelennek meg az adatbázisban, és a weboldalon is.
Nem látjuk a kódodat, nem látjuk a karakterkódolásait a fájloknak, hogy a headerek nincsenek-e felülbírálva, nem linkeltél honlapot, legalább tesztcéllal, hogy lássunk egy lapot belőle, így nehéz megmondani, hol keresd a hibát. Meg kellene nézned, hogyan csatlakozol az adatbázishoz, és azt a kódrészletet nekünk megmutatni. Azt is, hogy a kiadott header() nincs-e felülbírálva még a kimenet megjelenése előtt. Satöbbi.
Ha a szavaiddal élve az "egész fost" ISO-8859-2-ben rögzíted, akkor jól korlátok közé szorítod saját magadat. Ha nem érzed az UTF-8 előnyét, akkor olvasd el még egyszer a cikkeket, amiket belinkeltél, mert ezek szerint nem figyeltél oda rájuk olvasás közben."Headerek alapján a böngészők úgyis tudják mire álljanak, tehát egy külföldinek is ugyanúgy jelenik meg."
Was?Sk8erPeter
-
fordfairlane
veterán
-
Sk8erPeter
nagyúr
válasz SirRasor #10108 üzenetére
Akkor még egyszer, másként, amit eddig nyomattam, direkt, és még más is rajtam kívül: az a kódrészlet kellett volna, ahol csatlakozol az adatbázishoz... Esetedben a connect.php fájl tartalma. Amúgy ja, a SET NAMES UTF8-as megoldást CSorBA már itt említette, de ezek szerint kellett még pár hsz., mire kipróbáltad.
Azért kérdeztem rá én is arra a kódrészletre, ahol csatlakozol az adatbázishoz, mert az UTF-8-as karakterkészletet még ott kellene beállítani.Mivel nagyon helyesen mysqli-t használsz (a PDO is jó lenne, ez is jó), és nem azokat a szerencsétlen elavult mysql_* kezdetű függvényeket:
http://php.net/manual/en/mysqli.set-charset.php$mysqli->set_charset("utf8");
és ehhez még egy fontos idézet, ha már a SET NAMES utf8 szóba került, ebben az esetben - ha már van ez az említett függvény - NEM ajánlott:
"This is the preferred way to change the charset. Using mysqli_query() to set it (such as SET NAMES utf8) is not recommended. See the MySQL character set concepts section for more information."http://www.php.net/manual/en/mysqlinfo.concepts.charset.php
$mysqli = new mysqli("localhost", "my_user", "my_password", "world");
// Will not affect $mysqli->real_escape_string();
$mysqli->query("SET NAMES utf8");
// Will not affect $mysqli->real_escape_string();
$mysqli->query("SET CHARACTER SET utf8");
// But, this will affect $mysqli->real_escape_string();
$mysqli->set_charset('utf8');(Igaz, a mysql_* kezdetű függvényeknél sem kellett: mysql_set_charset('utf8', $conn);)
=============
(#10106) Athlon64+ :
Egyetértek, ez egy jó kérdés![ Szerkesztve ]
Sk8erPeter
Új hozzászólás Aktív témák
- Bomba ár! Asus VivoBook X412F - i5-8GEN I 8GB I 256GB SSD I 14" FHD I HDMI I Cam I W11 I Garancia!
- Bomba ár! HP ProBook 650 G5 - i7-8GEN I 8GB I 256GB SSD I 15,6" FHD I Cam I W11 I Garancia!
- Bomba ár! Lenovo ThinkPad L380 - i5-8GEN I 8GB I 256SSD I 13,3" FHD Touch I Cam I W11 I Gari!
- Bomba ár! Asus VivoBook S410U - i5-8GEN I 8GB I 256GB SSD I 14" FHD I HDMI I Cam I W11 I Garancia!
- Bomba ár! HP ProBook 450 G3 - i7-6G I 8GB I 256GB SSD I HDMI I 15,6" FHD I Cam I W10 I Gar!
Állásajánlatok
Cég: Alpha Laptopszerviz Kft.
Város: Pécs
Cég: Ozeki Kft.
Város: Debrecen