- Milyen okostelefont vegyek?
- Samsung Galaxy S25 Ultra - titán keret, acélos teljesítmény
- Apple iPhone 16 Pro - rutinvizsga
- Samsung Galaxy A54 - türelemjáték
- Xiaomi 15 - kicsi telefon nagy energiával
- Keretmentesít a Galaxy S25 FE
- Motorola Edge 50 Fusion - jó fogás
- Eltűnhet a Dinamikus Sziget
- Google Pixel topik
- Redmi Note 13 Pro 5G - nem százas, kétszázas!
Új hozzászólás Aktív témák
-
#678
cucka
addikt
Fire/SOUL/CD
#677
cucka
addikt
válasz
Fire/SOUL/CD
#677
üzenetére
A programod jó eséllyel akkor is működni fog, ha kihagyod az sql script-ből azt a sort, ahol a hibát dobja.
A normális megoldás az adatbázis szerver frissítése, a 4.0.24 az egy ősrégi verzió, valószínűleg befoltozatlan biztonsági lyukak tucatjaival. -
cucka
addikt
Toad for Mysql-ben egy kattintás és sql fájlban elmenti a komplett adatbázisomat. Ezt szoktam svn-ezni, sőt ezt szoktam futtatni az éles hoszting phpmyadmin-jában is.
Ez fasza, csak ha az éles adatbázisban ott vannak az éles adatok, akkor sokat nem érsz azzal, hogy a dev. adatbázisból csinálsz egy dumpot. Ha nagy az adatbázis, akkor megint csak szívsz ezzel az elgondolással.Nem azt állítom, hogy nem lehet így fejleszteni, csak szerintem sok lehetséges szívástól kíméled meg magad, ha az alkalmazáslogika nagy részét nem az adatbázisban tárolod. (Arról nem beszélve, hogy így függetleníteni tudod magad az adatbázis szerver nyűgjeitől, gyakorlatilag az alkalmazást nem fogja érdekelni, hogy milyen típusú adatbázisból dolgozik)
A tesztelés is nehézkesebb??? Ezt hogy érted? Lehet sok PHP hívőt megsértek vele, de a PHP-t eleve nem egyszerű (mondhatni rémálom) tesztelni, debugolni.
PHP-hez vannak szép automatizált eszközök unit tesztekhez, nem tudom, tárolt eljárásoknál ez hogy van. (Elvileg nyilván megoldható, gyakorlatilag meg még nem próbáltam) -
cucka
addikt
Szeretem amennyire csak lehet adatbázishoz közel tartani a logikát. Aztán az már, hogy az adott tárolt eljárást mysql-lel vagy mysqli-vel hívom meg számomra kb. mindegy.
Szerintem ezzel az esetek többségében csak lábon lövöd magad.
Például ha használsz valamilyen verziókövető rendszert, akkor az hogy működik együtt az adatbázis tárolt eljárásaival? A tesztelés is nehézkesebb, mint ahogy release esetén is több meló van, több hibalehetőséggel.A phpmyadmin pedig valóban nem a legjobb eszköz, mert ugye nem valami natív szoftver, hanem egy weboldal. Ettől függetlenül az esetek többségében a tudása megfelelő, és nem kell megoldani azt, hogy kívülről csatlakozz az adatbázis szerverhez. (Mert ugye általában nem lehet, marad a tunnel vagy a vpn, futhatod a köröket a rendszergazdával, stb.)
-
#569
cucka
addikt
Sk8erPeter
#567
cucka
addikt
válasz
Sk8erPeter
#567
üzenetére
Válasz a php kérdések topikban, mert ennek semmi köze a mysql-hez.
-
#566
cucka
addikt
Sk8erPeter
#565
cucka
addikt
válasz
Sk8erPeter
#565
üzenetére
while ($result)
Ebben a sorban a feltétel mindig igazra értékelődik ki, ezért kerül végtelen ciklusba.
-
-
cucka
addikt
válasz
VladimirR
#556
üzenetére
Ha csak annyit kell eldönteni, hogy kell-e frissíteni, akkor miért nem számolod meg egyszerűen a topikokat és a hozzászólásokat mindkét szerveren?
Gondolom mindent kell szinkronizálni, tehát ha a hozzászólások száma különbözik, id szerint meg fogod tudni mondani, mely sorokat kell áthozni.. -
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.
-
#510
cucka
addikt
Louloudaki
#509
cucka
addikt
válasz
Louloudaki
#509
üzenetére
Igen, ez pontosan így van.
-
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) -
cucka
addikt
válasz
drShaman
#475
üzenetére
Első tipp: a like alapból nem veszi figyelembe a kis és nagybetűk közötti különbséget, de ez csak az angol ábécé betűire igaz.
Második tipp: karakterkódolások ugye be vannak rendesen állítva?
Harmadik tipp: valójában nem is kéne megtalálja, félrenéztedEsetleg valami konkrét példa?
-
cucka
addikt
-
#428
cucka
addikt
Louloudaki
#426
cucka
addikt
válasz
Louloudaki
#426
üzenetére
igen, egyszerű select, insert, update, delete ugyanúgy működik 4-es és 5-ös alatt is.
-
#413
cucka
addikt
Louloudaki
#412
cucka
addikt
válasz
Louloudaki
#412
üzenetére
a) igen, limit-el elvileg gyorsabb.
b) ha az id primary key, akkor automatikusan készül rá index is, ami kb. egy keresőfához hasonlít. (pontosan nem tudom, hogyan van megoldva, de valami hasonló lehet). ez azért jó, mert a keresés műveletigénye nem lineáris hanem logaritmikus, tehát nem pörög végig semmi. -
cucka
addikt
az mindegy, hogy milyen kódolású a php file-od. ami számít:
- az adatok, amiket beviszel, milyen kódolásúak
- a mysql adatbázis kapcsolat milyen kódolású (set names parancsot ki kell adni a mysql-nek kapcsolódás után)
- maga az adatbázis (illetve a táblák) milyen karakterkódolásúak.ezeket kéne lecsekkolni.
-
cucka
addikt
válasz
Protezis
#393
üzenetére
a kapcsolótáblában eltárolhatod, hogy pl. berakta-e a kukába a levelet a júzer. amikor véglegesen törlődik, akkor meg törölheted azt a sort a kapcsolótáblából. ezen kívül törlésnél célszerű ellenőrizni, hogy az éppen törölt levélre hivatkozik-e még valamelyik sor a kapcsoló táblából, mert ha nem, akkor törölhető az is.
-
cucka
addikt
válasz
Protezis
#390
üzenetére
első változat nem jó, mert nagyon sok fölösleges adatot tárolsz.
második nem jó, mert kizárod a lehetőségét az esetleges több címzettes levélnek
szerintem a harmadik, középutas megoldás a jó:
van egy kapcsoló táblád a levél, a küldő és a fogadó között, amiben a köv mezők vannak:
kuldo_id, fogado_id, level_id, megnezett, torolt.
első három külső kulcs és a megfelelő táblában mutat egy sorra, utolsó kettő flag.
ehhez kell egy levél tábla, ahol a levelek szövege/tárgya/stb. található, mindegyik levél egyszer. ez a legrugalmasabb megoldás, mert támogatja a sok címzettes üzenetküldést, mindenkinek tudsz készíteni sok funkcióval rendelkező postaládát a kapcsoló tábla bővítésével (pl. ilyeneket hogy mikor nézte meg a levelet, kukába rakta-e vagy törölte, stb.) ugyanakkor minimálisra csökkenti a redundanciát. -
cucka
addikt
az első sorban elírtad a változó nevét ($parnacs) :)
egyébként szerintem ez jónak tűnik (leszámítva persze azt, hogy nincs levédve az, amit az adatbázisba insert-elsz). ha mégsem működik, első körben irasd ki az sql query-det, onnan látni fogod, mi a gond.
esetleg az okozhat még gondot, ha mondjuk a tábládban az id oszlop not null-ra van állítva és nem auto increment-es, akkor elvileg mysql hibát kell kapjál. ennek kiderítésére (és úgy általában az sql hibák feltárására a következő módon érdemes query-ket futtatni:
mysql_query($parancs) or die (mysql_error()); -
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.. -
cucka
addikt
leírás [link]
md5-öt egyszerű használni, simán csak md5('szoveg'), visszatérési értéke pedig egy pontosan 32 betűt tartalmazó kódolt string, mondjuk a fenti példára ezt fogod kapni: f8048b424496a23885767471f23731af
ha maga az algoritmus érdekel, azt megtalálod wikipedián. egyébként az md5-öt sikerült ''feltörni'', de ezzel együtt elég nehéz kulcsütközést generálni benne, szóval arra bőven elég biztonságos, hogy adatbázisban tárolt jelszavakat lekódold.
ha mégsem bízol benne, akkor ott az sha1 függvény, ugyanúgy használható, mint az md5, csak ez pontosan 40 karakter hosszú string-el tér vissza. -
cucka
addikt
azt nem tudom, hogy hol található ez a függvény, de nem beépített mysql cucc. ajánlott inkább valamelyik beépített függvényt használni, mondjuk sha vagy md5. ezek garantáltan alfanumerikus output-ot eredményeznek, vagyis nem lesz gond a spec. karakterekkel.
(vigyázat, vannak olyan beépített kódoló függvények is, amelyek bináris output-ot eredményeznek, pl. aes_encrypt. használat előtt érdemes kipróbálni)
[Szerkesztve] -
cucka
addikt
nincs azzal semmi baj, ha 160 oszlopa van egy táblának, csak okosan kell megírni a lekérdezéseket, a (vélhetően) nagy adatmennyiség miatt.
csoportosítani lekérdezésnél fogsz tudni, ajánlott kicsit utánaolvasni az sql-nek.
mod: egyébként meg többféleképpen lehet csökkenteni a mezők számát, csak feladattól függ, hogy érdemes-e.
[Szerkesztve]
Új hozzászólás Aktív témák
Hirdetés
- Autós topik
- exHWSW - Értünk mindenhez IS
- Milyen okostelefont vegyek?
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- Formula-1
- Nintendo Switch 2
- Teljes verziós játékok letöltése ingyen
- Mielőbb díjat rakatnának a görögök az olcsó csomagokra az EU-ban
- Samsung Galaxy S25 Ultra - titán keret, acélos teljesítmény
- Kínai és egyéb olcsó órák topikja
- További aktív témák...
- Ryzen 9 7900X /// Bontatlan // Üzletből, számlával és Garanciával!
- Ryzen 9 7900 /// Bontatlan // Üzletből, számlával és Garanciával!
- Ryzen 7 5700X3D /// Bontatlan // Üzletből, számlával és Garanciával!
- Ryzen 7 8700G /// Bontatlan // Üzletből, számlával és Garanciával!
- Ryzen 5 9600X /// Bontatlan // Üzletből, számlával és Garanciával!
- BESZÁMÍTÁS! Intel Core i7 4790 4 mag 8 szál processzor garanciával hibátlan működéssel
- ÁRGARANCIA!Épített KomPhone i5 12400F 16/32/64GB RAM RTX 4060 Ti 8GB GAMER PC termékbeszámítással
- ÁRGARANCIA!Épített KomPhone i3 10105F 8/16/32GB RAM RX 6500 XT 4GB GAMER PC termékbeszámítással
- Beszámítás! Sony PlayStation 5 825GB SSD digital konzol garanciával, hibátlan működéssel
- BESZÁMÍTÁS! MSI B550 R9 5900X 32GB DDR4 512GB SSD RX 6700 XT 12GB Rampage SHIVA Enermax 750W
Állásajánlatok
Cég: PC Trade Systems Kft.
Város: Szeged
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest