Na subquery není nic špatného, je to univerzální a je to naprosto v pořádku. Navíc to, co popisujete vy, je to, že chcete získat jeden záznam a ID ze dvou okolních záznamů. Takže triviální implementace je získat tři záznamy a z těch dvou krajních použít jen ID. Nesnažte se optimalizovat databázové dotazy, když nevíte, zda v nich je nějaký problém.
Navíc jste pořád nepopsal, jaký konkrétní problém řešíte, tak těžko dostanete konkrétnější odpověď. A to, co jste zatím popsal, moc smysl nedává. Vypadá to, že máte nějaké master–detail zobrazení, tj. máte sadu záznamů a prohlížíte po jednom detaily záznamu. V takové situaci chce uživatel procházet fixní sadu záznamů – takže dotaz na výběr záznamů dle podmínek se udělá jen jednou, zapamatují se ID záznamů a uživatel pak prochází ten předem daný seznam ID. Podle vašeho dotazu to asi bude nějaká webová aplikace, když vás nenapadlo rovnou tu sadu výsledků si pamatovat. Ale když to má procházet uživatel po jednom, těch záznamů stejně budou maximálně desítky, při nejhorším stovky, takže není problém si to zapamatovat i ve webové aplikaci.
To, že se to dělá nad fixní sadou záznamů, je proto, že pro uživatele by to bylo matoucí, kdyby ten dotaz byl živý. Pak půjde uživatel na třetí stránku, bude tam mít záznam 4, přejde jinam, vrátí se na stranu tři a bude tam mít záznam 6. Nebo půjde na stranu čtyři, bude tam mít záznam 5, půjde na předchozí stranu a znovu tam bude mít záznam 5. To by pro uživatele bylo matoucí, proto se ta sada záznamů vybere jednou a pak se uživatel pohybuje v ní. Když jde na konkrétní záznam, stáhnou se aktuální data, může se tam zobrazit, že už záznam neodpovídá původním podmínkám, ale to je vše.
Dovedu si představit i případ, že by uživatel zpracovával výsledky živého dotazu, ale pak bude postupovat jen dopředu.
30 Odpovědí
29085 Zhlédnutí