2. Fórumok
  3. Szoftverfejlesztés
  4. SQL kérdések
  5. (kiemelt téma)
Keresés

Új hozzászólás Aktív témák

  • #4975 Taci addikt martonx #4971
    Új Válasz #4975
    Új hozzászólás
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    Taci

    addikt

    válasz martonx #4971 üzenetére

    Igen, igazatok van, nem rinyálok, nekiülök és megcsinálom. Köszönöm, hogy elolvastátok azt a hosszú bejegyzést, és köszönöm az iránymutatást.

    @nyunyu: Köszönöm szépen, hogy ilyen részletesen leírtad ezt a processzt. De nem akarom megtartani a táblák jelenlegi tartalmát, naponta töröltem eddig a tesztek miatt.

    majd még csak ezután fog kezdődni a kálváriád, amikor ki fog derülni, hogy MariaDB-t nem támogatnak

    Így gondolom, ez sem fontos, mert a (remélhetőleg) végleges adatbázist tartalommal majd ott kezdem el felépíteni és feltölteni.

  • #4966 Taci addikt Ispy #4965
    Új Válasz #4966
    Új hozzászólás
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    Taci

    addikt

    válasz Ispy #4965 üzenetére

    Ez egy korrekt válasz, köszönöm.

  • #4964 Taci addikt bambano #4956
    Új Válasz #4964
    Új hozzászólás
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    Taci

    addikt

    válasz bambano #4956 üzenetére

    Jelenleg egy lokál gépen futó DesktopServer nevű környeztet használok a fejlesztésre. Itt MariaDB van használatban.

    Ha van valakinek egy szabad 5 perce, csak akkor olvasson tovább. :B

    Ez egy "itthoni tanulós projekt", semmi több. Érdekelt a téma, így elkezdtem egy weblapot készíteni 6 hónappal ezelőtt. De ekkor kezdtem el csak az alap dolgokon felül használni mindent, ami kell hozzá: HTML, CSS, JS, PHP, SQL.

    Nagyon szépen haladtam mindennel, 6 hónapja minden szabadidőmet beleöltem, és most már úgy láttam, 2 héten belül készen vagyok, és költözhetek a kis projektemmel a szolgáltatóhoz: Versanus, velük van pozitív tapasztalatom korábbról. Nem tudom, hogy ott milyen adatbáziskezelő van.

    Na szóval örültem, hogy végre a kis projektemet a "nagyvilág elé tárhatom" (értsd: rokonok és kollégák :D), és a todo-listám egyik utolsó eleme volt, hogy utánakérdezzek, hogy a lekérdezéseim nem pazarólak-e.

    És mint kiderült, sajnos rossz logika mentén építettem fel az egész adatbázist. És az a baj, hogy 6 hónapja amióta csinálom, erre a logikára épül minden de minden. Tegnap átnéztem a kódjaimat, nyilván az új típusú (1 db) táblát könnyen létrehoztam, a tartalomfeltöltő php kódot is könnyen átírtam az ajánlás alapján, hogy a több tábla helyett egybe írjon csak, külön oszlopba pedig, hogy melyik forrásból származó bejegyzéseket tárolja.

    De aztán jöttek a JS-ek, plusz a lekérdezésért felelős PHP, és ott sajnos csak nagy nehézségek és időveszteséggel tudnám csak átírni az egy táblás módszerre, hogy szépen működjön. Sajnos nem erre a logikára építettem fel, így kvázi kezdhetném előröl, mert másképp csak a régi módszer kódjait tudom "megerőszakolni", és mivel arra építettem fel mindet, sosem lesz szép tiszta igazán, csak ha előröl kezdem.

    És őszintén, ez most nagyon elvette a kedvem. Tökre örültem, hogy végre 6 hónap fáradozása a számomra tök ismeretlen területen végre manifesztálódik, erre kiderült, hogy nagyjából kezdhetem előröl.

    Mielőtt tényleg így döntenék, kérlek, írjátok meg, tényleg akkora gond-e, ha külön táblákban vannak az adatok.

    Források szerint készítettem el őket, 1 forrás - 1 tábla. Nagyon max 15-20 forrásból fogok dolgozni. Forrásonként naponta kb. 100 bejegyzéssel.
    1 bejegyzéshez tartozik egy id, egy link, egy rövidebb és egy hosszabb szöveg (300 karakter max), illetve 2 kép linkje (csak link), plusz még 2 rövidebb tartalmú szöveg (50 karakter max). Ennyi.

    Most már én is látom, hogy sokkal jobb lett volna az 1 tábla, mert minden bejegyzés pontosan ugyan olyan felépítési, ugyanolyan oszlopok vannak minden táblában.

    Viszont a kódjaim most tökéletesen működnek, millió ellenőrzést és vizsgálatot tettem beléjük, próbáltam minden eshetőségre felkészíteni. És sajnos a sok táblás megvalósítás egyáltalán nem kompatibilis az 1 táblással, tényleg át kellene írnom mindent, JS-től kezdve PHP-kig mindent, még HTML-eket is.

    És ha nem szörnyen rossz, tarthatatlan, pocsék lassú a mostani felépítés (max 15-20 tábla, napi 100 bejegyzés / tábla, tehát 2000 bejegyzés / nap, 14e bejegyzés / hét, 728e bejegyzés / év), akkor nem kezdeném előröl.
    Az nagyon visszavetne, már így is elszállt a kedvem.

    Bocs, hogy hosszan taglaltam ezt, de kérlek, írjátok meg, valóban elengedhetetlenül szükséges-e előröl kezdenem az új szerkezettel. A rokoni/kollegális elérésekhez biztosan nem.
    De később, ha a fél ország ezt olvassa majd (best case scenario :DDD ), lehet valami hátulütője a több táblás felállásnak? Ha egyszerre 5 millióan nézik az oldalt, lapoznak, futnak a lekérdezések (LIMIT 4, szóval 1 lekérdezés csak max 4 találatot ad vissza mindig), milyen negatív következményei lehetnek, ha a több táblásnál maradok? Lelassul minden mindenkinek? Vagy a szolgáltató szól rám?

    Ezt összefoglalnátok nekem pár gondolatban, kérlek?

    Eléggé elkeseredtem most, de persze ha ez a több táblás módszer a fenti számolásokat alapul véve is tarthatatlan, és később csak problémám lenne belőle (belassulna az oldal a felhasználóknak), akkor egyelőre hagyom az egészet, és majd ha megint találok rá ennyi időt egyszer, átírom.
    De ha csak a tábla karbantartása miatt lenne jobb, ha egy lenne a több helyett, akkor az nem gond, mert mindent eleve a több táblásra készítettem el.

    Köszönöm, és elnézést az eszméletlen hosszú posztért, de 2 sorban ezt nem lehet (vagy csak én nem tudtam) rendesen elmagyarázni.

  • #4946 Taci addikt nyunyu #4942
    Új Válasz #4946
    Új hozzászólás
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    Taci

    addikt

    válasz nyunyu #4942 üzenetére

    Amire kell csak figyelni: összes a táblába szúró insertnél legyen kitöltve a forrásrendszer azonosító.

    Ez alatt ezt érted? (Egy korábbi válasz ugrott be a PHP-s topikból ( [link] ), abban láttam ezt először.)

    ENGINE=InnoDB

    Ez miért fontos amúgy? Itt amúgy CREATE-nél van. Hol kell/ajánlott ezt használni?

  • #4945 Taci addikt nyunyu #4944
    Új Válasz #4945
    Új hozzászólás
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    Taci

    addikt

    válasz nyunyu #4944 üzenetére

    Köszönöm szépen a sok tanácsot, lesz mit átnéznem/átírnom. :) De legalább remélhetőleg stabil kódom/adatbázisom lesz. :)

    Még erre a full-text search-ös dolgot kell majd ránéznem.

    Illetve PHP oldalról megnézni, hogy az új struktúrájú lekérdezésben hogyan tudnám hatékonyan használni a bind_param-ot. (Ha kell/lehet-e egyáltalán.)

  • #4941 Taci addikt sztanozs #4939
    Új Válasz #4941
    Új hozzászólás
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    Taci

    addikt

    válasz sztanozs #4939 üzenetére

    Ha jó keresési találatokat nézek, akkor ez az, ugye? (Soha nem hallottam még róla, és amikro azt kerestem anno, hogy tudok keresni szavakra, a LIKE-ot dobta a legtöbb oldal, ezért kezdtem el ezt használni.)

    WHERE CONTAINS ((title, description),'"szoveg1" AND "szoveg2" AND "szoveg3"')

    Ha ez így helyes, akkor ugye mindkét helyről (title, description) ad vissza találatokat, akár egyikben, akár másikban, akár mindkettőben van találat az összes keresett szóra?

    @bambano:
    Ez azt jelenti, hogy inkább egy táblám legyen csak?
    De amúgy tényleg érdekelne, hogy miben/mennyivel "rosszabb", ha több táblában vannak az adatok. Nyilván a sebesség az egyik válasz, ez biztos. De érdekelne, miben még.

    Úgy szeretném megcsinálni, hogy utána szerkezeti változás miatt ne kelljen már "soha" belenyúlni, ezért veszem a fáradságot és időt és átírom, ezzel nincs baj. Csak érteni is szeretném a miértjét.

    Köszi.

  • #4938 Taci addikt nyunyu #4936
    Új Válasz #4938
    Új hozzászólás
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    Taci

    addikt

    válasz nyunyu #4936 üzenetére

    Ha csak 'valami%'-ra alkalmazod a facebook filtert (vagyis ismert a string eleje), akkor legalább a keresendő oszlopra rakott indexből tud dolgozni.

    Kereséshez használom, így sajnos nem ismert a sztring eleje, mert a keresett szó bárhol lehet, sor elején, közepén, végén, így muszáj vagyok (jelen ismereteim szerint) így keresni:
    LIKE '%szoveg%'

  • #4937 Taci addikt nyunyu #4935
    Új Válasz #4937
    Új hozzászólás
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    Taci

    addikt

    válasz nyunyu #4935 üzenetére

    Ez így valóban jó ötlet. Csak sajnos már mindent a külön táblákra felépítve csináltam meg. De ha azt mondjátok, hogy nagyságrendekkel gyorsabb/hatékonyabb/(nem tudom, mit kellene még itt figyelni) lenne ezzel a szerkezettel, akkor rászánom az időt, és átírom az elejétől kezdve.
    Kezdjek neki, vagy azért nincs akkora hátránya az 5 táblából való adatszerzésnek a 1 táblával szemben? Főleg úgy, hogy tényleg csak 4 bejegyzést kérek el egyszerre. (Bár amúgy az 5 tábla a jelenlegi struktúrával fel fog szökni kb. 20 táblára.)

  • #4934 Taci addikt sztanozs #4932
    Új Válasz #4934
    Új hozzászólás
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    Taci

    addikt

    válasz sztanozs #4932 üzenetére

    Köszönöm, ezt nem (sem) tudtam. :)

    És akkor most látom, hogy amit az előbb írtam az úgy nem jó, mert kell a zárójel elé a SELECT * FROM.

  • #4933 Taci addikt nyunyu #4931
    Új Válasz #4933
    Új hozzászólás
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    Taci

    addikt

    válasz nyunyu #4931 üzenetére

    Az 5 táblában 5 különböző forrásból származó bejegyzések vannak, jellemzően több száz (idővel több ezer), ezért vannak már eleve külön táblákba mentve.
    És a bejegyzéseket jelenítem meg az oldalon időrendi sorrendben.
    Viszont mivel sokszor előfordult, hogy frissült az adatbázis, miközben lapozgattam a listázott bejegyzések között (egyszerre csak 4-et jelenít meg (LIMIT 4, csak azt nem másoltam be a kódrészletbe), aztán görgetés után a következő 4-et, és így tovább), ezért újra ugyanazt a bejegyzést jelenítette meg (mert megjelenítette a 4 legfrissebbet, aztán frissült a bejegyzés, frissebb bejegyzések kerültek előre, tovább görgettem, betöltötte a következő 4-et, de azok egyszer már meg lettek jelenítve a frissítés előtt, így kvázi duplán jelentek meg (nem egymás után, de ha visszagörgettem feljebb, akkor láttam)). Ezért csináltam meg így, hogy amit már egyszer megjelenített, újra nem fogja.

    Ha fontos az időben csökkenő rendezés, akkor én tennék egy select * from ( ) order by date desc-et az unionok köré.
    Itt nekem az a lényeg, hogy az 5 táblából a lapra a bejegyzések időrendi sorrendben kerüljenek. Tehát ha a legfrissebb a table2-ben van, akkor azt jelenítse meg először. Ha a második és harmadik legfrissebb a table4-ben, akkor utána azokat. Lehet, hogy a table1-ben lévő bejegyzések csak a sokadik 4-es csoportban jelennek majd meg, mert annyival régebbi bejegyzések.

    Logikus teljesen, amit írsz, csak át kell gondolnom, hogy nálam miért jeleníti meg pont úgy, ahogy én akartam - ellenőriztem milliószor az időbélyegzőket is.

    Köszi, hogy felhívtad rá a figyelmem, átnézem majd még egyszer.

    Tehát ha az első lekérdezést nézem (ahol még nincs kizárva egy ID sem), akkor egy zárójelpár hozzáadása a megoldás, igaz? Így:

    (SELECT * FROM table1 
    UNION ALL 
    SELECT * FROM table2
    UNION ALL 
    SELECT * FROM table3
    UNION ALL 
    SELECT * FROM table4
    UNION ALL 
    SELECT * FROM table5)
    ORDER BY date DESC
    LIMIT 4

    Legalábbis elvileg, lehet, ez így hibára fut, nem tudom, csak este/holnap tudom majd kipróbálni.

    Ez visszaadja a 4 legfrissebb bejegyzést, majd a következő lekérdezés már ennek a 4-nek az ID-jait kizárja, pl. így:

    (SELECT * FROM table1  
    UNION ALL 
    SELECT * FROM table2
    WHERE id NOT IN (1) 
    UNION ALL 
    SELECT * FROM table3
    UNION ALL 
    SELECT * FROM table4
    WHERE id NOT IN (1,2) 
    UNION ALL 
    SELECT * FROM table5
    WHERE id NOT IN (1))
    ORDER BY date DESC
    LIMIT 4

    Így lesz a jó?

    Köszi.

  • #4930 Taci addikt
    Új Válasz #4930
    Új hozzászólás
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    Taci

    addikt

    Sziasztok!

    Ránéznétek kérlek, hogy ezek a lekérdezések (példák, az értékek persze folyamatosan változnak) nem "pazarlóak"-e?
    Működnek tökéletesen, csak nem tudom, hogy lehet-e/kell-e optimalizálni őket.

    SELECT * FROM table1 
    WHERE id NOT IN (102,103)
    UNION ALL 
    SELECT * FROM table2
    WHERE id NOT IN (104,105,106,107,108,109,110,111,112)
    UNION ALL 
    SELECT * FROM table3
    WHERE id NOT IN (31,32,33,34,35,36,37)
    UNION ALL 
    SELECT * FROM table4
    WHERE id NOT IN (59,60,61,62,63)
    UNION ALL 
    SELECT * FROM table5
    WHERE id NOT IN (21)
    ORDER BY date DESC

    A másik pedig:

    SELECT * FROM table1 
    WHERE ((title LIKE '%szoveg%') OR (description LIKE '%szoveg%')) 
    UNION ALL 
    SELECT * FROM table2
    WHERE ((title LIKE '%szoveg%') OR (description LIKE '%szoveg%')) 
    UNION ALL 
    SELECT * FROM table3
    WHERE ((title LIKE '%szoveg%') OR (description LIKE '%szoveg%')) 
    UNION ALL 
    SELECT * FROM table4
    WHERE ((title LIKE '%szoveg%') OR (description LIKE '%szoveg%')) 
    UNION ALL 
    SELECT * FROM table5
    WHERE ((title LIKE '%szoveg%') OR (description LIKE '%szoveg%')) 
    ORDER BY date DESC

    Ha nem "életbevágó", nem nyúlnék hozzájuk, viszont ha jobb lenne optimalizálni (valahogy), akkor megköszönném az iránymutatást.

    Köszi.

  • #4879 Taci addikt Ispy #4878
    Új Válasz #4879
    Új hozzászólás
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    Taci

    addikt

    válasz Ispy #4878 üzenetére

    Ah, akkor ahhoz képest hogy mennyi adattal milyen művleteket végeztettem vele, még gyors is volt... :D
    Köszi a felvilágosítást! :)

    És igen, kell az ALL is, mert egy-egy dátumból több is előfordulhat, és nekem mindegyikre szükségem van.

    Köszönöm! :)

  • #4877 Taci addikt Taci #4876
    Új Válasz #4877
    Új hozzászólás
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    Taci

    addikt

    válasz Taci #4876 üzenetére

    Úgy látom, UNION (ALL) fog talán kelleni. Már nézem is.

    És igen, ez lett az:

    SELECT * FROM table_1 UNION ALL SELECT * FROM table_2 ORDER BY date DESC LIMIT 4 OFFSET 4

  • #4876 Taci addikt
    Új Válasz #4876
    Új hozzászólás
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    Taci

    addikt

    Sziasztok!

    A segítségeteket szeretném kérni:

    Adott több tábla, mindegyikben több rekord, minden rekordnak sok mezője. A táblákban a mezők ugyanolyan névvel, típussal vannak létrehozva és feltöltve.
    Ezek közül az egyik egy időbélyegző, hogy a rekord mikor került az adatbázisba.

    Ha csak az egyik táblából kérdezem le az adatokat, villámgyors minden:
    SELECT * FROM table_1 ORDER BY date DESC LIMIT 4 OFFSET 4

    Szeretném kettő vagy akár az összes többi táblából lekérni az adatokat, és ezeket dátum szerint rendezve megjeleníteni.
    Viszont ha kettő vagy több táblából kérem le ezeket az adatokat, egyrészt nagyon-nagyon lassú, másrészt nem a jó adatokat, vagy nem a jó sorrendben adja vissza.

    Ezzel a lekérdezéssel próbáltam:
    SELECT * FROM table_1, table_2 ORDER BY table_1.date DESC LIMIT 4 OFFSET 4

    Itt elsőre azzal próbáltam, hogy ORDER BY date, de azt mondta, ez nem helyes így, mert a date mező több táblában is megtalálható. Ezért próbálkoztam így aztán.

    Egészen biztosan nem ez a jó módja a lekérdezésnek.
    Hogyan kell ezt jól megcsinálni? Összesen egyszerre 4 rekordot kérek csak le, ennek villámgyorsnak kellene lennie, úgy, ahogy amúgy 1 táblánál az is.

    Köszönöm előre is a segítséget.

Új hozzászólás Aktív témák