nosacījums limit?

grūti saprast tavu sāpi! :)

sāpi saprati pareizi:) es šito biju aizmirsis, bet nu jau lasu manuāli, tā ka būs ok:)

vienīgi ir viens jautājiens - sanāk taisīt divus kverijus katru reizi - noskaidrot kopējo count(*) un tikai pēc tam prasīt reālos datus, citādi var sanākt kaut kāds nekorekts range...

droshi vien!
tik gudrs jau neesmu, lai bez 2 selektiem!! :))

sūnaini. turklāt izlasīju, ka LIMIT laika taupīšanas nolūkos nepilnīgi ievēro ORDER BY, kas manuprāt dod iespēju parādīt datus nepareizā secībā vai arī kaut kādus datus izjaukt:/

peec kaa sorteesi datus?
peec id?

pēc kolonnas, kas ir UNIQUE un veido tabulas KEY kopā ar vēl vienu kolonnu, bet PRIMARY ir autoincrement integer

jebkuraa gadiijumaa, ja tu gibi vispirms nolasiit range ar vienu selektu, tad no LIMIT nav nekaadas jeegas.
nolasi kaadas ir veertiibas, saanalizee kaadas veertiibas gribi (gan jau gribi cipariskas), un tad njem
SELECT ... WHERE id>10 and id<30

viss. buus tev arii ordering.

man ir vājība uz optimizāciju, tādēļ gribās smuki ar vienu kveriju un limit visu selektēt. un vienīgais mīnuss pašlaik, ka nevar pateikt, cik vēl lapu uz priekšu ir un vai vajag vēl likt next vai nevajag.
ja nedomā par optimizāciju, tad jau elementāri noselektējam visus datus un izbliež masīva elemntus. nu laikam tas, ko tu rakstīji, bet tas nav cool:))

tu te man domaat visu dikti sarezhgjii.
1mais kverijs tak var buut piemeeram
Select count(id) from tableX

No shii cipara taksh var visu sareekjinaat, ne?
Un tiek sanjemt tikai 1 cipars, nav nekaada masiiva.
A potom atlasi tikai intereseejoshaas rindinjas.

nu jā - bet sanāk divas konekcijas uz db reāli vienam pieprasījumam. un jā - es visu parasti šitā sarežģīju tās optimizācijas slimības dēļ:)

shitaas fignjas var panaakt nopietnaakaas datu baazees rakstot datu baazhu funkcijas.

drošvien, bet tagad laikam būs vien jātaisa divi kveriji, jo tas varētu būt tomēr labāk, nekā vienmēr ar vienu kveriju, toties vienmēr vilkt visus datus...

nu bet protams!
divi mazi kveeriji ir daudz aatraaki, nekaa piemeeram masiivs ar 10k ierrakstiem! :))

ir proveets! :))

nu re. tad izlemts:)

WHERE id BETWEEN 10 AND 30 ;)

vaardiskam indexam vari njemt LIKE,
tikai tad selects nebuus paaraak efektiivs..

nu cik esmu gramstījies ar LIMITu, tad ORDER BY ievēro kā mīļais.
un Tu nevari iemānīt kaut kādu viltīgo COUNTu LIMITā? neesmu to pat mēģinājis, bet varētu kaut kādu mānīgo LIMIT (MIN(COUNT(*) - 10, 200), 10 provēt ;)

un priecājies, ka MySQL. MS SQL LIMITa kā tāda nav, ir tikai TOP un lai selektētu 5-10 ierakstu, sanāk selektēt TOP 5 DESC no TOP 10 DESC.
vot. ceru, ka izpalīdzēju :)

ne īpaši godīgi sakot:) btw mums vēlreiz Interreg jāraksta piedāvājums, tikai šoreiz latviski. tb tas pats, kas angliski, bet šoreiz latviski. nav gan garantijas, ka tas kaut ko dod, bet laikam jau labāk uztaisīt

uhbļe. davai rīt vakarā?

bet ieprovē to limitu un countu apvienot - man interesē, vai tā var ;)

es jau provēju - bļauj maita

nu labi. tad rītvakar to dranķību rakstam?
un teica, ka latviski arī vajagot?

nu tieši latviski jau arī vajag. tikai es nesaprotu, ko tas nozīmē - vai tas ir tikai ķeksītis un reāli uzvarētājs jau tāpat ir skaidrs (kas ir visticamākais) vai arī kaut kādas izredzes...

es domāju, ka ja nebūtu izredzes, tad vienkārši izsvītrotu un pieliktu piezīmi, ka pieteikums neatbilda konkursa prasībām.
vai arī uzvarētājs ir skaidrs, bet vajadzētu, lai uzvarētājs iesniedz arī latviski ;)))

man atkal liekās, ka varētu būt tā - konkurss ir noticies. uzvarētājs godīgā vai negodīgā kārtā ir noskaidrot, bet tagad ķeksīša dēļ (lai atbilstu likuma prasībām par konkursiem) vajag no visiem latviski.

nu bet to uzzinās enīvei tikai tad, ja aizsūtīs arī latviski ;)

patiesībā jau neuzzinās nekad, bet šitā ir cerība

piekrītu.
šis ir jau brīdis, kad pasaka, kurš uzvarējis.

tb tad tu domā, ka šitais jau ir tikai ķekša pasāciens un kāds cits jau zin, ka ir uzvarējis?

jeap.
definately.

demit

abet zini, dziesma laba.

viss Scrubs soundtrack ir baismi labs