- Eltűnhet a Dinamikus Sziget
- Huawei Watch 5 - okosóra érintőlegesen
- Huawei Watch GT 5 Pro - egészség + stílus
- Xiaomi 15 - kicsi telefon nagy energiával
- iPhone topik
- Okosóra és okoskiegészítő topik
- Az Oppo Find X8 Ultra lett a legvékonyabb kameramobil
- Az Euronics is elkezd használt mobilokkal foglalkozni
- Keretmentesít a Galaxy S25 FE
- Samsung Galaxy Watch6 Classic - tekerd!
Új hozzászólás Aktív témák
-
cucka
addikt
Mindkettő helyes, de az első talán szebb.
A lényegi különbség, hogy a tömb indexében hogyan fűzöd össze a stringeket. Igazából tökmindegy, a lényeg, hogy a végeredmény is string legyen.(#526) emitter
A képek adatbázisban való tárolásánál nem csak az az előny, hogy könnyebb lementeni. A lényeg, hogy sokkal elegánsabb, ha nem választod szét a képeket a többi adattól, mert ugye mindkettő ugyanahhoz az adatstruktúrához tartozik. További előny, hogy nehezebb hibásan megírni. File-os tárolásnál a könyvtár és filenevek generálását azért eléggé át kell gondolni, hogy ne legyen benne potenciális hibaforrás.
A hátrány, hogy bizonyos adatmennyiség fölött lassíthatja az adatbázis működését a sok blob adat, szóval ügyesen kell megtervezni. -
cucka
addikt
Join:
A join-oknak érdemes lenne utánaolvasnod, totál téves, amit írtál.
A korábbi hozzászólásomban ott volt egy sql lekérdezés. Az annyit csinált, hogy a szállás táblához hozzácsapta a megye tábla név mezőjét is. Tehát nem kell külön lekérdezned az összes megye nevét, vagy minden egyes szálláshelyre lekérni a nevet, mert annak az egy lekérdezésnek az eredményében ott lesz.
Próbáld megérteni azt a lekérdezést, cseréld ki a mezőneveket a megfelelőre és nézd meg, mi lesz az eredménye.Viszont az echo"..."-ban lévő tömbindexelésnél meg csak úgy működik, ha elhagyom az egyszeres idézőjeleket, így:
Megint csak nem jó, méghozzá azért nem, mert egybefolyik nálad a tömb indexelés szintaktikája és a stringek megadásának a szintaktikája.1. PHP-ban string-eket kétféleképpen lehet megadni: sima és dupla idézőjelekkel. A dupla idézőjeles megadás annyiban tér el a simától, hogy az abban található egyszerű változókat kiértékeli.
2. Dupla idézőjellel megadott string-ben a "komplex" változókat (pl. tömb egyik eleme, ahogy a példádban van) úgy tudod kiértékeltetni, hogy { } közé rakod.
3. Ha a tömb indexe string, akkor indexbe mindig stringként kell írni.
4. Ha egy string-be egy függvény visszatérési értékét akarod berakni, vagy egyszerűen csak sima idézőjelesen akarod megadni, akkor használj összefűzést (ez a . operátor)
5. HTML-ben az egyes elemek tulajdonságai mindig dupla idézőjelekben vannak. Tehát a példádban a <span style="float:left"> lenne a helyes.Példák a string-ed helyes megadására:
Sima behelyettesítéssel. Figyeld meg, hogy a dupla idézőjeles string-ben a dupla idézőjeleket le kell zárni a \ karakterrel. Ez sima idézőjeleknél is így van.
echo "<span style=\"float: left;\">{$row['nev']}</span>";
String összefűzéssel:
echo "<span style=\"float: left;\">".$row["nev"]."</span>";
Sima idézőjelekkel:
echo '<span style="float: left;">'.$row['nev'].'</span>';Ja, és a fentiek ellenére a te kódod is működik, csak egyrészt rossz, mert kihasználja a php gyenge ellenőrzését, másrészt ilyen stílusú kódok legtöbbször elég sok notice-t vagy warning-ot eredményeznek. Ezek ellenére a php kód le fog futni, de a jó kód az, ami nem generál ilyeneket.
-
cucka
addikt
Az indexnek (idegen kulcsnak) mi pontosan az értelme?
Bizonyos esetekben gyorsít. Olvass lejjebb.Ez akkor is működne, ha a megye_id nem lenne idegen kulcs, csak egy sima mező, nem?
Igen.
Viszont ha jól látom, azt csinálod, hogy a szállás tábla összes sorára lekéred a megye táblából az adott megye_id-hez tartozó nevet. Na ezt leginkább join-okkal szokás megoldani, mert a lényeg, hogy kevés és gyors query-t adjunk ki az adatbázisnak. Plusz itt már jól jönnek az idegen kulcsok is..Például
select szallas.id id,szallas.nev nev,szallas.cim cim,megye.nev megye_nev from szallas left join megye on (szallas.megye_id=megye.id)
Természetesen azt nem tudom, milyen oszlopaid vannak a szállás táblában, de a lényeg remélem érthető így is. Próbáld ki, nézd meg, mit kapsz eredményül.
A másik, hogy miért nem működik az a szintaktika, hogy:
Azt nem tudom, miért nem működik, de valóban nem. Igazából abban az egy sorban 4, azaz négy hiba van
1. A tömb indexei vagy számok, vagy string-ek. Nálad egyik sem, mert lemaradtak az idézőjelek ahhoz, hogy string index legyen.
2. Ha függvény visszatérési értéke tömb, akkor annak nem tudod ilyen formában elérni valamelyik mezőjét.
3. A mysql_fetch_assoc nem mindig tömbbel tér vissza, semmi nem garantálja, hogy létezik az a ['nev'] mező, amire hivatkozol. Ez esetben a minimum, hogy kapsz egy warning-ot, de valószínüleg további problémát is okozhat (mert a $megye változód így null marad)
4. A mysql_fetch_assoc függvénynek csak egy paramétere van. A második paramétert a mysql_fetch_array-nél használjuk és arra jó, hogy megmondja neki, hogy legyen indexelve az eredményül kapott tömb - számokkal, mezőnevekkel vagy mindkettővel. A mysql_fetch_assoc() ugyanezt csinálja, de kizárólag mezőnevekkel indexel. -
cucka
addikt
A mysql szervernek ezzel mondod meg, hogy az adatbázis kapcsolaton milyen kódolással fogja megkapni a szöveget. (Nem csak a stringeket, hanem tulajdonképpen minden input-ot)
Pl. amikor elküldöd a szervernek a "Bács-kiskun" szövegrészletet, akkor azt nem tudja automatikusan kideríteni, hogy milyen karakterkódolásban küldted, ugyanis ahogy láttad, utf8 mellett más kódolásokkal is értelmezhető az adott bináris adathalmaz. -
cucka
addikt
ha egy szállásnak sok jellemzője van, pl. fürdő, konyha, étkezési lehetőség, sportolás, stb. akkor ezeket tegyem bele nyugodtan a 'cim' táblába, vagy csináljak nekik egy külön táblát mondjuk 'adat' névvel?
Tedd bele nyugodtan, minden szempontból jobban jársz így, mint ha szétdarabolnád a táblát.Akkor ebben a táblában az id mező csak simán pr. key, vagy foreign key a 'cim' tábla 'id' mezőjére?
Ahogy javasoltam, az alap, hogy minden táblában van egy id mező, ami minden esetben auto_increment és primary key tulajdonságokkal rendelkezik. Ez egyébként nem kötelező, van aki máshogy csinálja, de szerintem sokkal előnyösebb mindenhova automatikusan berakni azt az id mezőt..Először is: minden képet külön sorban tárolj. Így nem szúrsz ki magaddal, és gyakorlatilag bármely szálláshelyhez tetszőleges számú képet hozzá tudsz majd rendelni.
A fotó tábla ezek szerint:
Minden képnek van azonosítója, ugyanakkor azt is akarjuk tudni, hogy az adott kép melyik szálláshoz tartozik, ezért be kell venni a táblába a szállás_id nevű mezőt. Ez a mező foreign key, méghozzá azért, mert egy másik táblában található indexelt mezőhöz köthető. Itt konkrétan a szállás_id a szállás tábla id mezőjével van összekötve. Például az 5-ös azonosítójú szálláshelyhez a fotó táblában azok a sorok tartoznak majd, amelyeknél a szállás_id mező értéke 5.tehát a fotó tábláa szerkezete:
id (primary key, auto increment)
szallas_id (foreign key)
további mezők, amire szükséged van (elérési út, kép címe, stb.)Remélem érthető volt, ha nem, kitalálok valami példát.
-
cucka
addikt
A megyék táblája valahogy így nézzen ki
id (primary key)
nevA szálláshely tábla pedig
id (primary key)
megye_id (foreign key)
nev, leiras, stb.Megye szerinti keresésnél a szálláshely táblát fogod megye_id szerint szűrni.
(#506) Louloudaki
Azt írtad, hogy az auto_increment php-ből történő szimulálása lassabb és bonyolutabb, mint a mysql-es. Valójában a probléma nem a sebességgel vagy a bonyolultsággal van, hanem azzal, hogy a php-s megoldás alapvetően nem jó, mert két azonos időben érkező kérés esetén előfordulhat, hogy hibásan működik. Ráadásul egy bonyolult rendszerben elég csúnya dolog ilyen jellegű hibákat keresni, mert ugye hiába próbálgatod, az esetek 99.99%-ában azt fogod látni, hogy minden hibátlanul működik.
Megkereshetsz privátban, de valószínüleg csalódást fogok okozni, a látszattal ellentétben egyátlalán nem érzem magam nagy db gurunak. -
cucka
addikt
mező attribútumoknál be kell állítani valamit (unsigned; unsigned zerofill; on update current timestamp), vagy hagyjam üresen?
Attól függ, mire akarod használni azt a mezőt. Az unsigned azt jelenti, hogy a mezőben található számnak nincs előjele (tehát midnig pozitív), az unsigned zerofill ugyanez, csak ott a mezőben található szám elé berak annyi 0-t, ami befér. Az on update current timestamp azt csinálja, hogy amikor kiadsz egy update-et a sorra, az adott mezőbe berakja az aktuális unix timestamp-et. Tehát pl. ha valamilyen hozzászólásnál/cikknél/stb. el akarod tárolni az utolsó módosítás időpontját, akkor arra jó.továbbá, ha van több táblám, amelyeknél az id mező azonos lesz, csak a legelső(nek nevezett) táblában legyen primary key, a többiben foreign-key; vagy mindegyikben prim.key?
Az id mezőt a sorok egyszerű és gyors azonosítására használd. Ebből következik, hogy javaslom, mindegyik tábládnak legyen egy id mezője, amely primary key.
Foreign key akkor jó, amikor két tábla közötti relációról van szó. Tehát pl. van egy személy táblád, benne egy id mező. Van egy hozzászólás táblád, amiben van egy személy_id meződ. Értelemszerűen a két tábla között kapcsolat van, amit az említett mezők valósítanak meg. Ilyenkor a személy_id mezőre kell a foreign key.És az auto_increment mire jó, hogyan működik?
Az auto_increment az tulajdonképpen egy szekvenciát jelent. Kb. úgy képzeld el, mint egy változót az adatbázisodban, ami minden lekérdezésnél megnöveli 1-el az értékét.Főleg a táblák id mezőjénél használod. Beállítod az id mezőre, hogy primary key és auto_increment, ekkor minden egyes új sor beszúrásánál az id mező automatikusan egy értéket, ami szigorúan egyedi az adott mezőben és mindig nagyobb, mint az előzőleg beszúrásnál kapott érték. (Tehát az azonosítók szigorúan monoton növekvő sorozatot alkotnak)
(#503) Louloudaki
Az auto_increment php-ból történő szimulálása elsőre nagyon rossz ötletnek tűnik. A mysql által megvalósított auto_increment az atomi műveletnek számít, míg php-ból lekérdezni a legnagyobbat majd 1-et hozzáadni az nem atomi művelet.
Ha egy időben jön két ilyen kérés a szerverre, akkor a mysql megoldása működik, a php-ból megvalósítottnál pedig előfordulhat, hogy két sor ugyanazt az azonosítót kapja. (Ami primary key-nél rögtön hibát is fog jelenteni) -
#503
Louloudaki
aktív tag
emitter
#502
Louloudaki
aktív tag
unsigned szám típusú mezőknél kell, ha biztos nem lesz negatív szám
a current timestamp dátum típusú mezőknél az aktuális dátumot veszi alapból
auto increment magától növeli a mező, pl id értékét minden új felvitelnél. de növelheted phpval is, kérdés mire jó, hogy lekérdezed az aktuális legnagyobb id-t, majd hozzáadsz egyet és úgy rögzíted az új adatokat, mikor ezt a db megcsinálja magától rövidebb idő alatt 1 lekérdezést spórolva.most ezt hogy érted, hogy több táblánál azonos az id mező? minden táblába kell egy primary key ami általában az id szokott lenni.
cucka, hasznos volt a link, köszi én is ;)
-
#500
Louloudaki
aktív tag
emitter
#498
Louloudaki
aktív tag
-
cucka
addikt
duplicate entry for key azt jelenti, hogy van egy unique meződ, amibe insertnél már meglévő dolgot szeretnél pakolni, vagyis ettől már nem lenne unique.
elvileg ha utf8 van mindenhol, akkor nem kéne ilyen karakterkódolási probléma előjöjjön. ha az adatbázis utf8as, akkor valószínüleg a phpmyadmin kódolása lesz elrontva.. -
vakondka
őstag
Szia,
Itt valami nagyon nem stimmel...két meződ van, egy word és egy count nevű ebben a táblában ?
Mert ha igen, akkor csak az első insert a helyes, a töbinek hiányzik az eleje.
INSERT INTO `search_total` ( `word` , `count` ) VALUES ('menüpont', 0.30103);
INSERT INTO `search_total` ( `word` , `count` ) VALUES ('megszünik', 0.30103);
stb..
ja igen, és kell a pontosvessző is az insert-ek közé.
[Szerkesztve] -
Tyrael
senior tag
ha az ftp-vel elersz egy olyan mappat, ami webrol elerheto, akkor oda feltoltod a phpmyadmin-t, majd ezutan weben keresztul phpmyadminba belepsz, es nyomsz egy exportot.
ehhez persze rendelkezned kell a kivant adatbazishoz felhasznaloi fiokkal.
illetve ha az adott felhasznaloi fiokhoz engedelyezve van a tavoli eleres, akkor barmilyen db klienssel tudod tavolrol kezelni az adatbazist.
mi a cegnel az EMS-t favorizaljuk.
Tyrael
[Szerkesztve]
Új hozzászólás Aktív témák
Hirdetés
- Külföldi rendelések: boltok, fizetés, postázás
- A látszat ellenére helyesen működik az NVIDIA-féle Resizable BAR implementáció
- Renault, Dacia topik
- Sony MILC fényképezőgépcsalád
- Háztartási gépek
- Egyre csak fejlődik az AI, emberek tízezreit rúgja majd ki a BT
- Milyen légkondit a lakásba?
- EA Sports WRC '23
- Melyik tápegységet vegyem?
- Gyúrósok ide!
- További aktív témák...
- Kingmax 1x2GB DDR2 800 RAM eladó
- BESZÁMÍTÁS! Intel Core i9 9900K 8 mag 16 szál processzor garanciával hibátlan működéssel
- BESZÁMÍTÁS! ASUS H81M-PLUS H81 chipset alaplap garanciával hibátlan működéssel
- VÉGKIÁRUSÍTÁS - REFURBISHED - Lenovo ThinkPad 40A9 docking station
- BESZÁMÍTÁS! ASRock Z370 i5 8500 16GB DDR4 512GB SSD 2060 Super 8GB Zalman Z9 Plus Enermax 750W
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft
Város: Budapest
Cég: Promenade Publishing House Kft.
Város: Budapest