Problém je hlavně v tom, že abych znal název předchozího a příštího článku musel bych provést ten dotaz už při výpisu aktuálního článku. Snažím se šetřit nároky na železo tím, že se dotaz provádí až, když je potřeba. Nemyslím, že je tento dotaz příliš složitý, ale v dalším díle už je to něco jiného.

další díl tohoto problému je trochu složitější, co když dotaz má 10 joinů, zkus někde popsat ten fígl a dej sem odkaz, nebo ho napiš já ti ho tady zveřejním

určitě zanedbatelný, první je nastavení uživatelské proměnné (nemá vliv na rychlost), poslední je vypsání obsahu uživatelské proměnné (nemá vliv na rychlost)

předpokládám, že na jedné stránce nebude 5× stránkování nebo prostě výpis 5× nějakého seznamu, kde by byl vhodný přechod na další záznam nebo ano? pokud ano určitě bych to rozdělil na více stránek

očíslování řádku bohužel nelze použít na různé filtry, výhodou tohoto je možnost použít i přeskakování na další a předchozí články dle parametrů vyhledávání! běžně to používám v systémech, kde je až 20 parametrů vyhledávání a více než 100 000 položek, zatím to jede svižně :), každopádně třeba uvedu příklad, kde si to jinak nedokážu představit: články jsou filtrovány podle kategorie, osoby která vložila články, a textu který obsahují, přesto výsledek tvoří např. 1000 článků, a nyní potřebujeme jejich překlady, tlumočník, jen píše překlad a kliká na další článek, žádné zdržování s přecházením na seznam článků apod.,

RSS – je ve spodu stránky, jestli myslíš RSS diskusí, tak ano brzy bude, stejně tak odesílání nových příspěvků na mail

jinak co se týče odkazu zkus formulovat více svůj zájem, jsem autorem www.nhlpro.cz z této problematiky mám několikaleté zkušenosti, v rámci časových možností by mohlo něco více přibývat :)

no co se tyce nhlpro, je tam 10k navstev denne v sezone, ale zklamu tě, přesto že mám plán co kešovat a jak postupovat s projektem dále, jsem jen programátor, o těchto věcech rozhoduje manažer, v sezóně jsme měli hodně problémy, co se týče návštěvnosti, byla tak vysoká, že to server nedokázal obsloužit a díky tomu zbytečně server přicházel o návštěvnost, v současné době už dlouhodobě jednáme o možných změnách, takže nebudu prozrazovat více ze zákulisí, každopádně když položíš konkrétní dotazy jsem ochoten zpracovat v rámci možností článek s odpověďmi

Co takhle si napsat kokrétní věci co by tě zajímali, nevím jestli by takový seriál krom tebe někoho zajímal?

Třeba nadpisy článků a tak? Zajímá tě programování nebo počítání statistik? Krom toho si myslím, že půjde o hokej jiné sporty jiné výpočty.

napiš prosím, tedy ten jednoduchý dotaz s tímto zadáním:

Kolikátý je hráč v pořadí podle počtu vstřelených gólů?

Hm zajimavé, ale asi sis nepřečetl o čem je článek. Netuším co tohle vrátí, ale řekni mi jak z tohohle selectu zjistit kolikátý je Jágr v žebříčku počtu vstřelených branek v roce 2008?

přiznám se, že sem dlouho hledal řešení, tohle vypadá jednoduše, proto je mi divné, že bych na to nepřišel, zkusím v rámci času přes týden projít, proč jsem to neřešil takhle, dej sem odkaz na nějaký tvůj blog nebo něco pokud máš

jinak proč nesmyslně? rozhodně to funguje

tak už tuším proč jsem to nepoužil:

1. goly se v tabulce pocitaji za zapasy, takže je nutné použít sum() a taky group by IDhrace, pak by count(*) neměl smysl, protože by počítal jen výskyty toho hráče
2. zjednodušením vznikl tento článek, každopádně mne teď nenapadá problém proč nepoužít to co píšeš, snad jen, že je nutný druhý subselect, což v mém případě není nutné
3. otázka je co nabízí více možností, např. příští článek a předchozí článek? jak třeba pomocí metody „Kajman“ vypsat článek v pořadí 351?
4. vařím z vody není moc čas, tak doufám, že mé závěry jsou správně, ale třeba se mýlím, každopádně proč zavrhovat mou metodu? její nevýhodu vidím v tom, že musí projít cyklem úplně všechny řádky, což by mohl být problém! ale jinak, šlo o to jak pomocí uživatelských proměnných počítat pořadí řádku a pak s ním manipulovat, Kajman metoda šikovně obchází smysl

metoda kajman pracovní označení :), neřekl jsem, že je to blbost, proč ne, jsou to dva složené dotazy to při mém řešení není nutné přece?

proč hned odsuzuješ použití uživatelských proměnných?co je na tom složitého? myslíš, že je nastavení uživatelské proměnné nějak náročné?nebo dotaz na získání uživatelské proměnné?

článek je obecné řešení, vaše řešení funguje pouze v konkrétním případu, představte si nějaký obecný datagrid, kde si uživatel podmínky vyhledávání, řazení atd. nakliká sám, pak je vaše řešení nepoužitelné