ugrás a tartalomhoz

select + limit összes sor száma php -> adoDBben

Szekeres Gergő · 2007. Okt. 27. (Szo), 22.08
van egy mySQL lekérdezésem, amivel 50 "adagokban" listázom li a sorokat. Viszont a lapozáshoz szükségem lenne az összes sor számához. Mivel ez egy több nagy táblát érintő lekérdezés, ezért jó lenne, ha nem kellene egy új selectet írni, ami annyival különbözne, hogy lehagyom a limitet. Ez megoldható valahogy? Fontos lenne, hogy adoDBben működjön...

SELECT SQL_CALC_FOUND_ROWS * FROM tábla
LIMIT 10;
SELECT FOUND_ROWS();
ez működik konzolban, de phpval nem tudom ezt megoldani.

Valakinek valami 5let?
‹ Reguláris kifejezés illeszkedjen sortörésre is fájlfeltöltési probléma ›
 ■
1

COUNT?

TeeCee · 2007. Okt. 28. (V), 10.05
SELECT COUNT(id) FROM tábla
Ez nem jó az összes sor megadásához?
Amúgy nem értem, ha 50-esével listázod ki a sorokat, akkor miért LIMIT 10, de biztos bennem a hiba...
(Vagy a teljes kérdést nem értem?)

Az adoDB-ben nics valami lapozó? Én nem használtam, de a manualjában tuti van valami pager.
2

egy lekérdezésbe kellene

Szekeres Gergő · 2007. Okt. 28. (V), 10.18
Bocs, fél 11kor már a magyar sem ment teljesen:

Olyan megoldást szeretnék, hogy egyszerre egy darab lekérdezéssel kérek le x db sort a limit segítségével, ugyanakkor ez a lekérdezés visszatérne a limit nélkülis sorok számlával is. Pont azért kellene, hogy ne keljen még egy COUNT(*)-os lekérdezés, mivel több, nagy méretű táblából kérdezek.

Maga a lapozó már kész van, az adoDB ilyen téren nem érdekel.
3

mi nem működik?

Hodicska Gergely · 2007. Okt. 28. (V), 12.33
AdoDB-ben is csak selecteket adsz ki, szóval a fenti két seelectet kell kiadnod, és működni is fog. A második esetében érdemes lehet a GetOne() metódust használni.

A COUNT(*)-os querykkel MySQL/InnoDB páros esetén vigyázni kell, mert komoly teljesítmény csökkenést okozhat, ezért adott esetben érdemes segédtáblát használni a sorszámok tárolására.

Ezenkívül érdemes lehet tesztelni azt is, hogy ezzel a 2 query-s módszerrel jársz jobban, vagy a count(*)-gal, mert írtak az SQL_CALC_FOUND_ROWS-ról olyat, hogy néha nem túl hatékony, és volt amikor tényleg az jött ki, hogy a következő jellegű query nem volt lassabb:

SELECT 
    *, 
    (SELECT count(*) FROM foo WHERE bar) AS count 
FROM 
    foo 
WHERE 
    bar 
LIMIT 
    10
Üdv,
Felhő
4

majd kitesztelem

Szekeres Gergő · 2007. Okt. 28. (V), 13.02
Igazából én is ezt olvastam a SQL_CALC_FOUND_ROWS-ról, hogy nem a leggyorsabb megoldás. Az volt a problémám, hogy két queryt nem tudok egyszerre elküldeni phpban, viszont ha külön függvénnyel futtatom a SELECT FOUND_ROWS(); lekérdezést, akkor az 0 sort fog visszaadni.

Az általad írt megoldást fogom használni, aztán majd a teszteket kibukik, hogy mennyire hatékony...

Köszi szépen!
5

Miért ne tudnál?

janoszen · 2007. Okt. 28. (V), 13.45
Miért ne tudnál egyszerre két queryt elküldeni? Kapsz két result setet. Sőt, mondok jobbat, tárolt eljárás és mysqli.
8

sp nekem is eszembe jutott

Szekeres Gergő · 2007. Okt. 28. (V), 20.53
Gondolkoztam én is sp-n, de igazából nem is az a baj, hogy kétszer küldöm el a kérést, hanem hogy kétszer kell az sqlnek végigjárni a joinokat.. Így tárolt eljárás sem jelentene nagy teljesítménynövekedést. ugyanez a helyzet Felhő által beküldött megoldásban is(az a subquery megkétszerezi a lekérdezés idejét...). Arra gondoltam még, hogy mivel a táblák nagyok, de ugyanakkor az érkezési halmaz már jóval kisebb a feltételek miatt, így lehet jobban járnék phpvel limitelni... Körülbelül úgy számolok, hogy maximum 200 sort adna vissza egy lekérdezés, és 3 mező érintett(két szöveg egy szám), így nem lenne olyan vészesen sok adat.
9

cache

winston · 2007. Okt. 28. (V), 21.12
nem tudom, hogy mi a pontos applikáció, így legfeljebb csak közelíteni tudok valami relatíve ideális megoldásoz, de szösszenetként megemlítenék egy varázsszót: cache. értem ez alatt mondjuk a html kimenet cachelését, de ami most még aktuálisabb: a adodb képes "cachelt lekérést" csinálni, vagyis megadhatod neki, hogy X másodpercig eltárolja magában az eredmény result setet, és csak utána forduljon újra az adatbázishoz. megfelelő select-ekkel, tárolt eljárással és ezzel talán már nagyobb tábláknál is tűrhető a sebesség. ha nem, akkor szerintem nézd át a táblaszerkezetet, és próbáld kicsit optimalizálni azokra a lekérdezésekre, amik sűrűn fognak előfordulni.
6

nem count(*)...

TeeCee · 2007. Okt. 28. (V), 20.17
A COUNT(*)-os querykkel

Nem COUNT(*)-ot mondtam, hanem COUNT(id)-t ;-)

Úgy hiszem, hogy egy indexelt mezőre tuti gyors választ ad (normális esetben az id minimum UNIQUE, gyakrabban AUTOINCREMENT is). Nagyon tévednék?
7

hát ezt passzolom

Szekeres Gergő · 2007. Okt. 28. (V), 20.49
szerintem ilyen téren tökmindegy, hogy az indexelt vagy nem. Akkor lehet teljesítménynövekedés, ha a WHERE záradékban szereplő mezők indexeltek, mivel ott számít, hogy sorba van-e rendezve. De aztán lehet én tévedek nagyot, SQL téren mostanában sürün érnek meglepetések.. :)