WebPillangó főoldal
Oldalak: 1 [2]   Le
  Nyomtatás  
Szerző Téma: MySQL  (Megtekintve 16073 alkalommal)
Piszi
Új tag
*
Nem elérhető Nem elérhető

Hozzászólások: 10


« Válasz #20 Dátum: 2009. 12. 05. - 13:11:19 »

Nah megoldottam közben magam Mosolyog
Mégis csak a while volt a hiba ahogy először gondoltam. Az első while-t tesztelési céllal tettem be, hogy tudjam, biztos lekérdez e minden id-t amire szükség van és nem figyeltem aztán minden további kódot alá írtam be és így persze, hogy nem volt jó.
De most már minden ok.
Naplózva
Tupacko
WebPillangó

Adminisztrátor
Törzstag
*****
Nem elérhető Nem elérhető

Hozzászólások: 966


WWW
« Válasz #21 Dátum: 2009. 12. 09. - 11:00:55 »

Orulok, hogy sikerult megoldani a gondot Mosolyog Ha valamire magad jossz ra, akkor azt a hibat minimalis valoszinuseggel koveted el ujbol.
Naplózva
lowert
Tag
**
Nem elérhető Nem elérhető

Hozzászólások: 111


« Válasz #22 Dátum: 2010. 05. 14. - 22:06:54 »

Összességében ezt a problémát áthidaltam, azonban fúrja az oldalamat a kiváncsiság, hogy mi okozhatja. Van egy lap, benne egy form, karakterkódolás utf-8. Van egy mySQL adatbázis, karakterkódolás utf-8 (minden adatnak). Konkrét példa, mivel egy tartalomkezelő rendszert írtam, ezért ahhoz kell, hogy lehessen regisztrálni, tehát a regisztrált felhasználók megadják a nevüket. Máté megadja a nevét, azonban az adatbázisban nem Máté-ként jelenik meg, sokkal inkább Máté-ként. Csak az adatbázisban. Mikor bejelentkezik a felhasználó, lekérem a sorokat, beteszem $_SESSION['name']-be, hogy gyorsan elérjem, de ilyenkor már jól látszódik, hogy Máté. Azonban mikor kézzel insertelem be a táblába a Máté nevet, akkor ugyan phpMyAdmin-ban jól látom, hogy Máté van írva, azonban mégis rossz (vagyis utf-8-tól különböző, ilyen értelemben rossz) kódolást kapok, mikor a $_SESSION['name']-et kiíratom. Arra gyanakszom, hogy a szerveren futó phpMyAdmin-nak rossz a karakterkódolása, vagyis nem a valós kódolással látom az adatokat, hanem valami valami egyébbel. Létezik, hogy ennyire suta a phpMyAdmin?
Naplózva
Tupacko
WebPillangó

Adminisztrátor
Törzstag
*****
Nem elérhető Nem elérhető

Hozzászólások: 966


WWW
« Válasz #23 Dátum: 2010. 05. 15. - 01:17:47 »

A phpMyAdmin kezdooldalan irja az epp aktualis kapcsolat karakterkodolasat! Kicsitt nezd meg, nem tudom megmodani pontosan hol es milyen formaban irja, mert ez nyelv es verzio fuggo, de irja, hogy milyen a karakterkodolas, amit epp hasznal.
Naplózva
liptakrobi
Új tag
*
Nem elérhető Nem elérhető

Hozzászólások: 12


« Válasz #24 Dátum: 2012. 04. 24. - 23:27:38 »

Sziasztok

Én csak pár ötletet kérek, hogy lenne ésszerűbb megcsinálni egy adatbázist amiben sok mindenféle dolgot lehet majd keresni. Mint pl egy használt autós oldalnál.

Kérdés hogy csináljak külön táblát a keresésnek és külön az autós adatlapoknak vagy 1 táblát és ott legyen minden oszloponként?

így gondoltam a külön táblát:
Keresés táblában soronként felvinnék kulcsokat és értékeket és hozzá a kocsi ID ket vagyis autós adatlap táblában levő ID-ket
lenne pl
kulcs:ajtok-szama; ertek:5; ID:2,5,14,222,678
kulcs:uzemanyag; ertek:benzin; ID:2,8,19,222,555
kulcs:evjarat; ertek:2005; ID:2,25,78,222,555

És a keresésnél lekérem, hogy ajtok-szama=5 és uzemanyag=benzin és evjarat=2005
és ugye lenne egy csomó ID-m amit php segítségével kiválogatnák, jelen esetben a 2 és a 222 lenne az eredmény.

Utána már csak le kéne kérnem az autos adatlap táblából a 2 és a 222 es ID vel rendelkező sort.
Az autós adatlapon lenne még sok más adat amiben nem kéne keresni is pl ABS, légszák, fűtött ülés, stb...


Talán a keresés táblámban még így is kevesebb sor lenne, noha pl. az évjáratnál lehet lenne 20 külön féle évjárat érték is.
Ha pl 10 ezer kocsiból kell is válogatni keresni a keresés táblám lehet csak 200 sor lenne, de pl az üzemanyag kulcsomnál meg ott lenne pl 5000 ID egymás után.

Vélemény?
Naplózva
spier
Tag
**
Nem elérhető Nem elérhető

Hozzászólások: 125


« Válasz #25 Dátum: 2012. 04. 30. - 12:56:51 »

Szia

Számomra nem teljesen világos a keresés tábla létrehozásának célja adott esetben. Meghatározott feltételekkel adott táblában keresel és adott helyen vagy adott paraméterek alapján választod ki, hogy hol keressen.

Az általad említett koncepciónál maradva egy külön kereső oldal vagy keresési résznél megadja/kiválasztja a kívánt adatokat és/vagy paramétereket. Mivel tudod, hogy ezzel a pl. form-al hol tud keresni (autók között), átadod a kapott paramétereket pl. egy php feldolgozónak. Ezt a php kódot tudatosan a beérkező adatok alapján készíted el (várja a form-ban meghatározott paramétereket stb.). Keresésnél a php feldolgozó megkeresi és visszaadja az adott feltételek alapján az általad meghatározott oldalon a kapott eredményeket. Ha nem talál semmit akkor meg a megfelelő szöveg vagy művelet amit ide gondolsz.

Többféle keresési lehetőséget pl. select-ben megvalósíthatsz. Az oldal tartalmi része vagy az autók között lehessen keresni. A megfelelő feldolgozóra irányítod a kapott paraméter alapján és a megfelelő sablont használod hozzá, hogy megjelenítse a találatot/találatokat.

Célszerű több táblát létrehozni magának az autóhoz kapcsolódó és meghatározott adatoknak. Egy táblában csak az autó id-je, neve, tipusa van stb. Egy másik táblában az ajtók lehetséges száma 4,5,6 stb. Egy másikban az üzemanyag lehetőségek benzin, gázolaj stb. Egy másikban az évjárat 1950,1951 stb. Ezeket összekapcsolni pl. JOIN-al, GROUP-al stb. lehet egy keresésnél vagy listázásnál pl a mindenhol meghatározott auto id alapján.

Ajánlom a Tanuljuk meg 24 óra alatt könyvek közül azt amelyik a mysql-el foglalkozik. Rövid és könnyen emészthető.
Nem csak boltban lehet beszerezni de ez nem ide tartozik. Mosolyog

Üdv
Naplózva
liptakrobi
Új tag
*
Nem elérhető Nem elérhető

Hozzászólások: 12


« Válasz #26 Dátum: 2012. 05. 06. - 20:32:09 »

Köszi, én végül is csak erre a részre lettem volna kíváncsi, hogy hogyan célszerűbb, kinek mi a véleménye, a többit értem.
Célszerű több táblát létrehozni magának az autóhoz kapcsolódó és meghatározott adatoknak. Egy táblában csak az autó id-je, neve, tipusa van stb. Egy másik táblában az ajtók lehetséges száma 4,5,6 stb. Egy másikban az üzemanyag lehetőségek benzin, gázolaj stb. Egy másikban az évjárat 1950,1951 stb. Ezeket összekapcsolni pl. JOIN-al, GROUP-al stb. lehet egy keresésnél vagy listázásnál pl a mindenhol meghatározott auto id alapján.
Bár ez se jó ha összekapcsolok majd 20 féle táblát, Vigyorog , mert kiátkoznak a hostról.
Ezért írtam egy olyan lehetőséget, hogy nem külön táblákat készítek hanem mindenhez csak 1-1 sor lesz pl üzemenyag = benzin, vagy üzemenyag = disel mintha csak kategóriák lennének, vagy nem is tudom minek nevezzem.
És ha kiakarom listázni a benzinest akkor csak 2 sor lesz ahol az üzemanyag van és abból kell 1 sort kiválasztani, hogy ez így csak gyorsabb mintha lenne 5000 sorom és abból kéne 2000 benzinest kiválasztanom.
Viszont nem egyesével kapom meg az ID-ket hanem egyszerre 2000-ret egy tömbben vagy veszővel elválasztva, és majd tömböt csinálok belőle.
Mert ha pl 20 féle dologra keresnek vagyis a szerint kell kilistázni a kocsikat, akkor elég csak 20 tömböt amikben ID-k szerepelnek.
pl ezt tudnám alkalmazni a tömbökre
array_intersect -- kiszámítja a tömbök metszetét
array array_intersect ( array array1, array array2 [, array ...])

A multkori példám szerint:
Kód:
$ajto = array(2,5,14,222,678);
$uzemanyag = array(2,8,19,222,555);
$evjarat = array(2,25,78,222,555);

$t = array_intersect($ajto,$uzemanyag,$evjarat);
print_r($t); // Array ( [0] => 2 [3] => 222 )
Ügye utána már csak: SELECT * FROM `autosadatlap` WHERE `id` IN (2,222)
Naplózva
spier
Tag
**
Nem elérhető Nem elérhető

Hozzászólások: 125


« Válasz #27 Dátum: 2012. 05. 07. - 16:27:21 »

Értem mire gondolsz, egyszer megpróbálkoztam hasonló megoldással. Ott is csak a képek id-jét - ami az adott termékhez tartozik és feltöltöttek - mentettem a termék tábla adott sorába. Szépen módszeresen úgy emlékszem implode-al betettem a vesszőket, mindig frissítve az adott sort ha új kép került fel. Kiolvasásnál pedig explode-al betettem tömbbe és kezeltem. Hát... hamar leszoktam erről.
A php topikban Tupacko-t is kérdeztem erről, volt róla szó.
A végeredmény az sql adta lehetőségek jobb és átfogóbb ismerete és azok kihasználása lett.
Nem véletlenül találták ki ezeket, mit menet közben tapasztaltam a fent említett kód karbantartása és felépítése során.
Elviselhetetlen terhet rótt a php feldolgozó részre és átláthatatlan lett. Sokszor nem tudtam hol a hiba továbbá a folyamatos frissítések/törlések/módosítások olyan bonyolult php kódot igényeltek amik nem voltak ésszerűek. A kilistázásnál is jóval bonyolultabb program jött létre és megannyi lehetőséget nem tudtam kihasználni vagy csak további táblák vagy kódsor létrehozásával. A bővíthetőség és minden egyéb lehetőség nehezedett vagy megoldhatatlan lett.

Nincs jelentősége pár ezer sornak egy táblában vagy pár tíz összekapcsolásnak, elenyésző erőforrást igényel ha az megfelelően van kódolva/lekérve.

Szerintem próbáld ki mind a két megoldást teljesen leprogramozva és továbbgondolva azt, így szembetűnőek lesznek felhasználás közben a különbségek.
Rosszul fogalmaztam előző post-ban, nem célszerűbb így csinálna, hanem elvileg így kell. De persze ez programozva már mindenkinek szubjektív Mosolyog.

Üdv
Naplózva
Tupacko
WebPillangó

Adminisztrátor
Törzstag
*****
Nem elérhető Nem elérhető

Hozzászólások: 966


WWW
« Válasz #28 Dátum: 2012. 05. 07. - 21:16:03 »

Sziasztok!

Semmi keppen nem ajanlom, hogy egy lekerest ugy oldj meg, hogy beerkezik a lekeres PHP-hoz, az leker egy reszt az adatbazistol, szurest vegez rajta es egyeb atalakitasokat (amit megoldhatsz SQL-bol is), majd egy ujab lekerdezes az adatbazison es ismet csak PHP, ami vegulis HTML-t general. Nem a 20 join miatt atkoznak ki (azert is), hanem a szerverterheles miatt Mosolyog

A tablaszerkezetek megvalasztasa abszolut attol fugg, hogy mekkora adatmennyisegre torekszel. Tovabba az is fontos kerdes, hogy foleg keresni fognak az adatbazisban vagy sokszor szerkeszteni. En azt javasolnam, hogy elso korben normalizald annyira a tablakat, amennyire csak lehet. Ez egy tiszta kiindulasi alap es az esetek tobbsegeben jo megoldas. Ha idovel tul sok join lesz, lelassulnak a dolgok (par millio sorrol beszelunk itt mar), akkor lehet "esszeruen" denormalizalni, olyan oszlopokat osszevonni kulon tablakbol egy uj tablaba, amikre egytt van szukseg es altalaban egyszerre kell adatkiszolgalast vegezniuk. Ezaltal kevesebb join lesz es az adatok is kozel lesznek.

Egy nehany szazezer soros nagysagu adatbazissal en arra torekednek, hogy legyen normalizalt es logikusan lebontott. A mai SQL teljesitmennyel siman elboldogul az ajtok szamanak csoportositasaval az adatbazis motor, csupan egy indexet kell tenni az oszlopra es o majd megoldja, hogy gyors legyen az adott oszlopon levo kereses.

Figyelmedbe ajanlom meglevo nyilt forraskodu rendszerek adatbazisanak es mukodesenek tanulmanyozasat is. Rengeteget lehet tanulni beloluk!

Udv,
Tupacko
Naplózva
liptakrobi
Új tag
*
Nem elérhető Nem elérhető

Hozzászólások: 12


« Válasz #29 Dátum: 2012. 05. 08. - 18:39:40 »

Köszi

Csak jártam már úgy a left join nal régi e107 el hogy a news részen volt 3 hír, de spam robotok írtak vagy 500-500 kommentet mindhez, és a lekérésnél úgy volt, hogy vagy 3 táblát fűzött össze joinal és baromira belassult az egész vsp mire a kommenteket kilistázta.
Mondjuk én a join-ot nem igazán szoktam használni.
Én ezt tanultam meg:
SELECT * FROM `termek`,`csoport` WHERE `termek`.`cs_id` = `csoport`.`id`

Úgy emlékszem, hogy valami joomlás sobi plugin így oldotta meg ahogy én is kigondoltam, de nem biztos, most nem találom meg, hogy ott hogy volt.

Akkor valahogy így csináljam?
Lényeg hogy lehessen admin felületről új kategóriákat bevinni mint pl.:ajtók száma, üzemanyag, évjárat, stb...

1. tábla lesz a `csoport` ide viszem fel a kategóriákat ha pl újat hozunk létre
valahogy így néz ki: ID; name; value;
sorok pl:
1; üzemanyag; benzin;
2; üzemanyag; diesel;
3; ajtók; 2;
4; ajtók; 3;
5; ajtók; 4;
6; ajtók; 5;
...
125; évjárat; 2005;
126; évjárat; 2006;

2. táblába lesz a `kategoria` ide viszem be az első tábla id-t és a hozzá tartózó termék adatlap id-t
valahogy így néz ki: ID; cs_id; a_id;
Lényegébe ha van egy benzines, 5 ajtós, 2005 évjáratú, kocsi, akkor a csoport táblám 1,6,125 -ös idjeit kell bevinnem
sorok pl:
10; 1; 55;
11; 6; 55;
12; 125; 55;
ha más hasonló kocsi is lesz akkor még a többi sor:
13; 1; 33;
14; 6; 33;
15; 126; 33;

3. tábla lesz az `autosadatlap`
és pl a fent említett benzines, 5 ajtós, 2005 évjáratú kocsi, id-je lesz az 55-ös
valahogy így néz ki: ID; title; kategoriak; leiras;
sorok pl: 55; opel astra eladó; 10,11,12; Megkímélt állapotban...

És a keresésnél pedig ha rákeresnek a benzines, 5 ajtós, 2005 évjáratú autóra akkor én egyből 1,6,125-ös id-ket kapom meg, ha persze az option selectem úgy van megcsinálva pl Évjárat:<select name"evjarat"><option value="125">2005</option>...

Lényegében annyit változott hogy nem 1 táblában vannak az id-k felsorolva hanem erre lesz a 2 es tábla.
viszont akkor a 2 es táblám akár 20x több sort is tartalmazhat mint az autós adatlapom mert elég sok féle dolgot kell egy kocsinál lementeni, és ez ezer autónál akár 20 ezer soros 2 es táblát jelent.

Ha pedig szűkíteni kell a keresésemet, hogy van e benne ABS vagy központi zár (bár ilyenekre ritkábban kell) de akkor csinálok neki egy hasonló táblát még+ ba mint az 1 és a 2 es..


És akkor most jöhet hogy SELECT * FROM `autosadatlap`,`kategoria` WHERE `kategoria`.`a_id` = `autosadatlap`.`id`  AND`kategoria`.`cs_id` IN (1,6,125)

Csak ez így nem jó! mert ezt az 5 sort választja ki:
10; 1; 55;
11; 6; 55;
12; 125; 55;
13; 1; 33;
14; 6; 33;
De itt a 33 as `autosadatlap`.`id` nem kell, mert ott a nincs 125-ös id viszont össze tudja majd kapcsolni, mert az 1 és 6 os van.
Mert ha van 20 féle keresési feltétel nekem olyan kel ahol mind a 20 megfelelő és nem elég hogy csak 1 megegyezik, ezért akartam volna szűrni egymásban a tömböket.

Bár nem tudom, hogy mi van ha csoportosítom a `kategoria`.`cs_id` alapján vagy `kategoria`.`cs_id`, `autosadatlap`.`id`
Naplózva
liptakrobi
Új tag
*
Nem elérhető Nem elérhető

Hozzászólások: 12


« Válasz #30 Dátum: 2012. 05. 08. - 19:04:11 »

Így talán jó.
SELECT DISTINCT(`autosadatlap`.`id`),`autosadatlap`.* FROM `autosadatlap`,`kategoria` WHERE `kategoria`.`a_id` = `autosadatlap`.`id`  AND`kategoria`.`cs_id` IN (1,6,125) GROUP BY `kategoria`.`cs_id`
Naplózva
Tupacko
WebPillangó

Adminisztrátor
Törzstag
*****
Nem elérhető Nem elérhető

Hozzászólások: 966


WWW
« Válasz #31 Dátum: 2012. 05. 09. - 18:20:53 »

Egyreszt a spam vedelem mas tema. Masreszt a

Kód:
SELECT * FROM `termek`,`csoport` WHERE `termek`.`cs_id` = `csoport`.`id`

az is join, csak nem irod ki explicit. Ez annyi mint egy full inner join.

Ha dinamikusan akarsz kategoriakat is hozzaadni, akkor sokkal lassabb lesz, mint ha a tabla szerkezete elore ki lenne gondolva. Ez azert tortenik, mert a lekerdezeshez meg kell talalni azt is, hogy mi alapjan tortenik majd a lekerdezes. A flexibilitas es a gyorsasag egy egyenes ket kulonbozo pontjan helyezkednek el. Az alkalmazasod lehet nagyon flexibilis, de kevessbe kepes kiszolgani nagy terheles, vagy szuper gyors de nehany megkotessel.

Idézet
ez ezer autónál akár 20 ezer soros 2 es táblát jelent

20 ezer sor semmi manapsag, ebbol ne csinalj gondot. Inkabb az a gond, ha 1000 auto utan van 20 ezer sorod. Ott valami elkepzelheto, hogy egyszerusitheto meg.
« Utoljára szerkesztve: 2012. 05. 09. - 21:40:28 írta Tupacko » Naplózva
liptakrobi
Új tag
*
Nem elérhető Nem elérhető

Hozzászólások: 12


« Válasz #32 Dátum: 2012. 05. 11. - 00:30:57 »

Hmm... köszi.
Naplózva
Oldalak: 1 [2]   Fel
  Nyomtatás  
 
Ugrás: