Kurzory jsou rozumnou volbou pro stránkování v menších intranetových aplikacích, které pracují s velkými datovými sadami, ale musíte být připraveni je po uplynutí časového limitu zahodit. Uživatelé se rádi zatoulají, jdou na oběd, jedou na dva týdny na dovolenou atd. a nechají své aplikace spuštěné. Pokud se jedná o webovou aplikaci, existuje dokonce otázka, co je to „běh“ a jak zjistit, zda je uživatel stále nablízku.
Nejsou vhodné pro rozsáhlé aplikace s vysokým počtem klientů a klienty, kteří přicházejí a odcházejí téměř náhodně jako ve webových aplikacích nebo webových rozhraních API. Nedoporučoval bych ve vaší aplikaci používat kurzory, pokud nemáte poměrně malý počet klientů a velmi vysokou míru požadavků ... v takovém případě bude odesílání malých dávek řádků velmi neefektivní a měli byste místo toho přemýšlet o povolení požadavků na rozsah atd.
Kurzory mají několik nákladů. Pokud kurzor není WITH HOLD musíte nechat transakci otevřenou. Otevřená transakce může zabránit tomu, aby autovakuum správně fungovalo, což způsobí nadýmání stolu a další problémy. Pokud je kurzor deklarován WITH HOLD a transakce není držena otevřená, musíte zaplatit náklady na zhmotnění a uložení potenciálně velké sady výsledků - alespoň si myslím, že tak fungují kurzory typu hold. Alternativa je stejně špatná, nechává transakci implicitně otevřenou, dokud není kurzor zničen, a zabraňuje vyčištění řádků.
Navíc, pokud používáte kurzory, nemůžete vrátit připojení zpět do fondu připojení. Budete potřebovat jedno připojení na klienta. To znamená, že se používá více backendových zdrojů pouze pro udržování stavu relace a nastavuje velmi reálnou horní hranici počtu klientů, se kterými můžete pracovat s přístupem založeným na kurzoru.
Je zde také složitost a režie správy stavového nastavení založeného na kurzoru ve srovnání s bezstavovým přístupem sdružování připojení s limitem a offsetem. Potřebujete, aby vaše aplikace vypršela platnost kurzorů po uplynutí časového limitu, nebo se potýkáte s potenciálně neomezeným využíváním zdrojů na serveru a musíte sledovat, která připojení mají jaké kurzory pro které sady výsledků pro které uživatele....
Obecně, navzdory skutečnosti, že to může být docela neefektivní, LIMIT a OFFSET může být tím lepším řešením. Často může být lepší hledat primární klíč než používat OFFSET , ačkoli.
Mimochodem, díval jste se na dokumentaci pro kurzory v PL/pgSQL. Pro tuto úlohu chcete normální kurzory na úrovni SQL.
Vyžadují kurzory, aby bylo připojení k databázi ponecháno otevřené?
Ano.
Probíhají kurzory uvnitř transakce a zamykají zdroje, dokud nejsou "zavřeny"?
Ano, pokud nejsou WITH HOLD , v takovém případě spotřebovávají další databázové zdroje.
Existují nějaké další „problémy“, o kterých nevím?
Ano, jak by mělo být vysvětleno výše.