Starší komentáře ke článku: Stránkování v ovládacím prvku DataGrid inteligentněji
Zpět na článek | Úvodní stránka Interval.cz
Datum vložení: 8.4.2004 8:31:52
Dobry den, zdravim vas a mel bych dve poznamky:
1. Prvni se tyka jmennych konvenci u sp, je durazne doporuceno nepouzivat sp_ prefixu u uzivatelskych sp, protoze pri vykonani se tyto nejprve hledaji v master db a az nakonec v aktualni, coz znamena pokles vykonu(viz <a href='http://msdn.microsoft.com/library/default.asp?url=/library/en-us/createdb/cm_8_des_07_7yw5.asp)' target='_blank'>http://msdn.microsoft.com/library/default.asp?url=/library/en-us/createdb/cm_8_des_07_7yw5.asp)</a>
2. Nejsem si jisty pouzitelnosti docasne tabulky v sp. Takovato aplikace(rekneme se 100k clanky) nebude urcite pouzitelna pri soucasnem pristupu nekolika ctenaru. Pro kazdeho dotaz se vzdy presypou vsechna data do docasne tabulky, a pak se zase zahodi, toto urcite neni optimalni postup. Daleko rychlejsi by bylo mit nacteno vsechno v pameti, dokonce je mozno mit i predpripraveny vsechny radici varianty.
Hezky den,
Radim Hampel
Datum vložení: 8.4.2004 8:50:39
add 1
mate pravdu.... neni k tomu co dodat
add 2
Ono však není bezpodmínečně nutné do dočasné tabulky kopirovat všechna data, ale pouze sloupec s identitou (pote tabulky spojite a máte výsledek).
Udělat vše na SQL serveru je v mnoha pripadech lepsi, predstavte si situaci, která je zcela normální a to sice, ze web server a SQL server jsou dva fyzicky oddelene stroje, a ono je pak sakra rozdíl, kdyz je nutné po síti přetáhnout 10k dat nebo treba 10M dat.
Datum vložení: 8.4.2004 9:12:48
add2
Vytvorenie temp tabulky do ktorej sa ulozi len identity a PK z tabulky, ktoru chceme strankovat sa mi tiez zda ako dobre riesenie.
add2B
a tiez suhlasim s politikou: 'z SQL tahat LEN to co je naozaj nutne'
Datum vložení: 8.4.2004 9:27:26
- bohuzel je to nejlepsi reseni kdyz dana databaze neumi limit nebo neco podobnyho.
- davat to do temp tabulky neni tak pomaly jak se muze zdat, uz pri nekolika tisicich zaznamu v tabulce je citelne poznat rozdil mezi presunem do temp tabulky a potom joinem a druhym resenim kde si z resultsetu vyberu zaznamy az ve skriptu (aps/php)
Datum vložení: 8.4.2004 9:56:59
Souhlas. Uprime me se ale nelibi vubec vytvaret nejakou temp tabulku, protoze se tim zpomali proces vyberu dat. Pouzil bych to az jako krajni reseni. Napred bych uvazoval o vyuziti SELECT TOP vyberu. Tj. Omezit maximalni pocet vybranych zaznamu (napr na 50 nebo 100 zaznamu pomoci parametru ulozenem napr. ve web.config) a donutit uzivatele, aby zadal takova vyberova kriteria, aby pocet vybranych zaznamu byl mensi. Samozrejme pokud to jde. Dalsi moznost je pouzit kombinaci temp tabulky a tehle metody a az jako posledni pouzit samotnou temp tabulku.
Datum vložení: 8.4.2004 12:25:42
Zdravim
temp tabulky jsou opravdu vykonostne neprijemne. Proc Vam pro strankovani nevyhovuje vnoreny TOP?
SELECT TOP X FROM (SELECT TOP Y FROM TAB1 ORDER BY Sloupec1
asc) t ORDER BY Sloupec1 DESC
Rene Stein
Datum vložení: 8.4.2004 12:27:10
Vidim ze problem s odeslanim jsem nemel jenom ja :)
Datum vložení: 8.4.2004 12:44:46
Nejde o problem s odesíláním příspěvků a už vůbec ne o problém na straně Interval.cz. Jde o problém se zobrazováním stránek, který je zaviněn tím geniálním bannerem Oracle ;-)
Datum vložení: 8.4.2004 12:59:08
To bych si samozrejme tvrdit nedovolil :) U me to byl problem na mem prijimaci, respektive u nextry...
Datum vložení: 8.4.2004 12:25:06
Do tabulky by musel pribyt krome identity jeste puvodni klic, a pak to spojeni(index?) by nebylo z nejrychlejsich. Jiste urychleni by mohlo znamenat pracovat misto t. tabulky s tabulkovou promennou, ktera v tomto pripade muze byt pouzita.
Samozrejme souhlasim s principem pracovat vzdy s co nejmensim objemem dat. Ovsem presunuti cele tabulky myslim toto nedodrzuje. Technicky problem strankovani je samozrejme klasicky orisek bez jednoznacne spravne odpovedi. V tomto pripade bych dal vetsi duraz na kesovani(kesovat, kesovat a zase kesovat). Staci data natahnout jednou(pripadne ve vicero serazenych variantach?) a pracovat s nimi primo v pameti, vzdyt co je nekolik (desitek) mb.
RH
Datum vložení: 8.4.2004 9:47:09
ad1) Zajimalo by me jak velke je to zpomaleni, kdyz nejprve hleda v master db. Je to vubec patrne? Pak se taky doporucuje volat procedury celym jmenem, to je vcetne uzivatele, napr. dbo.usp_procedura.
Datum vložení: 8.4.2004 11:15:01
sice jsme tohle konkretne nikdy nezkousel, ale urcite to bude poznat. Jednou sme napriklad podstatne zrychlili aplikaci tim, ze jsme uctu pod kterym se aplikace prihlasovala k db nastavili spravnou defaultni db.
Datum vložení: 8.4.2004 12:10:47
Cetl jsem v nejake diskuzi prispevek cloveka, ktery videl system se stovkami sp_ procedur a podle jeho slov to nebylo nikterak velke zpomaleni, nejake vsak ano. Zalezi samozrejme na typu applikace.
Pravdou ale zustava, ze tato praktika je spatna a nemela by byt nikdy vyuzita.
Datum vložení: 12.4.2004 21:39:22
Neviete niekto, ci bude novy MS SQL server (tusim sa bude volat YUKON, ale neviem ci si to teraz nepletiem s VS ;-) ) obsahovat aj LIMIT N, M alebo nejaku obdobu ? Je to podla mna jedna s 'najchybajucejsich' veci.
Datum vložení: 13.4.2004 7:45:59
Tusim, ze LIMIT neni ve standardu SQL, ale nevim to jiste, takze mne prosim nekdo opravte.
Datum vložení: 13.4.2004 11:05:32
Ono je viac veci ktore v standarde nie je a v MS SQL je - ale toto by sa fakt hodilo. ( Aj ked inac som skor za dodrzovanie standardov ako vytvaranie 'MS-kwazi-standardov' )
Datum vložení: 7.8.2004 16:15:55
po úpravě, kdy se do temp tabulky uloží pouze ident a pak oid z pernament tabulky a následně se tato tmp table joine k pernament tabulce s omezením vět není režie sql serveru výrazná. jestli má tab 1 nebo 100000 záznamů je při zobrazení v dg zanedbatelné, určité rozdíly jsou patrné v profileru.