Query..Text - divné správanie, zázraky

[Stanislav Hruška]

Tá ducharina je dosť často spojená s mojim spôsobom práce/myslenia. Dostanem nápad a hneď ho realizujem. Samozrejme, že to nemôže dopadnúť dobre.
Mal by som o tom popremýšľať, urobiť si analýzu, nakresliť si to... Ak sa mi podarí absolvovať tieto kroky, tak robota ide sama od seba a zvyčajne bez zásadných chýb.
No niektoré si neviem vysvetliť. Toto je práve takýto príklad. Problém je v tom, že som urobil dva kroky naraz a preto neviem povedať kde to viazlo.

Proto bych zacal tim resetem a pokracovanim ze stavu nula. Dost velkou neplechu dokaze take napr. prehrivani pocitace (kdys naposled vyfoukal pocitac?), zacinaji porucha pameti nebo zdroje apod.

Ten reset budem musieť robiť častejšie. Veď to netrvá dlho. Počítač (HAL3000 EliteWork) som kúpil 8.8.2018. Záruka je podľa dodacieho listu. Ten nemám. Ja si pamätám 3 roky, takže doň nebabrem.

Tak kdyz jsem byl nucen delat znovu neco v Delphi, tak jsem to praseni SQL ve stringach uz nedokazal vydejchat a uchylil jsem se k technice, ze jsem si nadelal datamoduly s TFDCommand a do nich jsem ty SQL dotazy nastrkal a z nich si je bral napr. do query aj. Prenos mezi DB managerem a aplikaci pak bylo proste copy&paste v obou smerech.

Tiež by som to rád mal ináč. Aj sme o tom mali nejakú debatu. Lenže niektoré sa skladajú dynamicky až za behu programu - napr. voľby užívateľa.
Pri prenose do manažéra používam PSPad na odstránenie "prebytočných" znakov a nahradenie parametrov konštantami. Ide to celkom rýchlo.
Opačný prenos trvá dlhšie. Ten zvyknem robiť len na začiatku, keď ten SQL text dávam dokopy pomocou manažéra.

[pf1957]

Lenže niektoré sa skladajú dynamicky až za behu programu - napr. voľby užívateľa.

No to ja taky skladam, ale v podstate jen podminene pripojuju vyrazy ve where klauzuli podle nastaveni filtru a order by klauzuli, kteru mi vetsinou generuje nas grid.

[vandrovnik]

Tá ducharina je dosť často spojená s mojim spôsobom práce/myslenia. Dostanem nápad a hneď ho realizujem. Samozrejme, že to nemôže dopadnúť dobre.

Jen pro jistotu - když řešíš rychlost dotazu, je potřeba testy opakovat a dívat se především na nejlepší výsledek.

Typicky po restartu bude první spuštění dotazu a načtení všech jeho výsledků pomalejší, než když ten samý dotaz spustíš znovu, protože Firebird a/nebo Windows budou před dalším spuštěním už mít nějaká data v cache (tj. v RAM), takže mnohonásobně rychleji dostupná. S plotnovým diskem a velkou databází ten rozdíl bude veliký, s SSD to tak dramatické nebude (plotnový disk bude zvládat řádově 100-200 požadavků na čtení/zápis z jiné části disku, protože tam musí nejprve dojet hlavičkami a počkat, až se plotny příhodně pootočí, u SSD to bude řádově spíše v rozmezí 20.000 - 200.000 takových požadavků za sekundu).

Pokud zkompiluješ aplikaci a spustíš ji, probíhá nejspíš na pozadí ještě zápis .dcu, .exe a kdo ví čeho dalšího na disk. Opět to ovlivní rychlost, se kterou Firebird (nebo jakákoli jiná databáze) může z téhož disku načítat svoje data.

[Stanislav Hruška]

Ja som rýchlosť dopytov riešil len v extrémnych prípadoch. Jednalo sa o naozaj neprimerane dlhé časy. Pomohol si mi niektoré veci vyriešiť pomocou EXISTS. Vedel som o ňom, ale som si myslel, že to bude pomalé. Lebo sa volá ďalší dopyt   No výsledok mi vyrazil dych. Konečné výsledky boli o niekoľko rádov rýchlejšie.
O tých veciach viem. Vždy robím niekoľko porovnaní časov. Porovnávam si aj časy z DB manažéra a aplikácie.
Testoval som si to aj nad big dátami. Aj keď tu nebola dodržaná integrita údajov. Aké v aplikácii určite nebudú. Predpokladám, žeby som sa z tohto pohľadu nemal dočkať prekvapenia.