Poslední příspěvky

Stran: 1 2 [3] 4 5 ... 10
21
Obecné / Re:Výkon - DISTINCT, JOIN
« Poslední příspěvek od Stanislav Hruška kdy 10-12-2017, 20:48:29 »
Citace
Pro Tvuj typ aplikace zvaz table partitioning (pokud Firebird umi).
Ty ma chceš priviesť do hrobu :D . No niečo v tom zmysle niečo vie. Minimálne to platí pre samotnú DB. Ale či aj pre tabuľky neviem. A neviem ani čo to vlastne znamená. Keď sa už dnes hrabem po internete tak pokračujem v tom ďalej.
22
Obecné / Re:VirtualStringTree - OnChange
« Poslední příspěvek od Stanislav Hruška kdy 10-12-2017, 20:44:50 »
Hm, ja tam mám test na Node = nil. Tak si to preverím či mi to za tým testom ide 2 x.
23
Obecné / Re:VirtualStringTree - OnChange
« Poslední příspěvek od Delfin kdy 10-12-2017, 20:38:12 »
Podľa mojich zistení sa táto udalosť vždy volá 2 x po sebe. To mi robí dosť problém, lebo mám tieto udalosti zreťazené. Keď mám napr. tri úrovne, tak VST3.OnChange sa vykoná 8 x. Keď uvážime, že tam hľadám záznam v DB pomocou Locate(), čo je ten lepší prípad a napĺňam iné VST + ktovie čo, tak to už je o držku.
Dá sa to nejako minimalizovať? Nemám na mysli samotné OnChange. To musí zbehnúť 2 x, lebo až pri druhom zbehnutí sú k dispozícii tie správne údaje, ale môj kód. Stačí ho spustiť pri druhom vykonávaní OnChange.

To je daň "zložený" formulár. Mám PageControl a na každej strane (aj 14) je pôvodne samostatný formulár, ktoré sú teraz väčšinou previazané. To znamená, že výber záznamu v jednom VST zmení obsah všetkých VST pod ním.

Pri vyberu jedne vetve je prvni udalost pro zruseni vyberu (ClearSelection), druha udalost pro aktivaci nove vybrane vetve. V prvnim pripade je parametr Node == nil, v pripade druhem jde a nove vybiranou vetev. Mohl bys tedy pouzit:

Kód: Delphi [Vybrat]
  1. procedure TForm1.VirtualStringTree1Change(Sender: TBaseVirtualTree; Node: PVirtualNode);
  2. begin
  3.   if Assigned(Node) then
  4.     ShowMessage('New node is being selected... [applies only for single node selection, not for node multiselection!]');
  5. end;
24
Obecné / Re:Výkon - DISTINCT, JOIN
« Poslední příspěvek od Delfin kdy 10-12-2017, 20:26:25 »
Pokiaľ viem, tak stačí ak sa časom pridá veľký objem dát a tým sa zmenia podmienky na použitie indexov. A už je iný plán. Aj preto chcem niektoré plány kontrolovať pri veľkom objeme testovacích údajov. Len tak skusmo som si nejaké nahodil, a hneď prvý formulár sa mi otvára 3 - 5 minút :(  Ale ešte nemám nič optimalizované. Napr. vytvorením indexov.

O tom nevim a Firebird znat nechci :) Pro Tvuj typ aplikace zvaz table partitioning (pokud Firebird umi).
25
Obecné / VirtualStringTree - OnChange
« Poslední příspěvek od Stanislav Hruška kdy 10-12-2017, 20:14:46 »
Podľa mojich zistení sa táto udalosť vždy volá 2 x po sebe. To mi robí dosť problém, lebo mám tieto udalosti zreťazené. Keď mám napr. tri úrovne, tak VST3.OnChange sa vykoná 8 x. Keď uvážime, že tam hľadám záznam v DB pomocou Locate(), čo je ten lepší prípad a napĺňam iné VST + ktovie čo, tak to už je o držku.
Dá sa to nejako minimalizovať? Nemám na mysli samotné OnChange. To musí zbehnúť 2 x, lebo až pri druhom zbehnutí sú k dispozícii tie správne údaje, ale môj kód. Stačí ho spustiť pri druhom vykonávaní OnChange.

To je daň "zložený" formulár. Mám PageControl a na každej strane (aj 14) je pôvodne samostatný formulár, ktoré sú teraz väčšinou previazané. To znamená, že výber záznamu v jednom VST zmení obsah všetkých VST pod ním.
26
Obecné / Re:Výkon - DISTINCT, JOIN
« Poslední příspěvek od Stanislav Hruška kdy 10-12-2017, 20:05:26 »
Pokiaľ viem, tak stačí ak sa časom pridá veľký objem dát a tým sa zmenia podmienky na použitie indexov. A už je iný plán. Aj preto chcem niektoré plány kontrolovať pri veľkom objeme testovacích údajov. Len tak skusmo som si nejaké nahodil, a hneď prvý formulár sa mi otvára 3 - 5 minút :(  Ale ešte nemám nič optimalizované. Napr. vytvorením indexov.
27
Obecné / Re:Výkon - DISTINCT, JOIN
« Poslední příspěvek od Delfin kdy 10-12-2017, 19:44:55 »
Firebird muze zmenit plan pro stejny SQL prikaz pokud zmenis schema dotcenych tabulek (napr. pridanim indexu). Neverim na nejakou jeho umelou inteligenci (ze by napr. dokazal pro konstantni schema pro stejny SQL prikaz sledovat jeho vyuziti a prikaz v jednu chvili zacal optimalizovat vhodnejsim planem, pripadne spustenim jineho prikazu).
Na to nepotřebuje umělou inteligenci, na to stačí sledovat statistiky jednotlivých indexů. A to dělá.

Takze po nejake dobe pro stejny prikaz beze zmeny schematu aplikuje jiny plan?
28
Obecné / Re:Výkon - DISTINCT, JOIN
« Poslední příspěvek od pepak kdy 10-12-2017, 19:39:32 »
Firebird muze zmenit plan pro stejny SQL prikaz pokud zmenis schema dotcenych tabulek (napr. pridanim indexu). Neverim na nejakou jeho umelou inteligenci (ze by napr. dokazal pro konstantni schema pro stejny SQL prikaz sledovat jeho vyuziti a prikaz v jednu chvili zacal optimalizovat vhodnejsim planem, pripadne spustenim jineho prikazu).
Na to nepotřebuje umělou inteligenci, na to stačí sledovat statistiky jednotlivých indexů. A to dělá.
29
Obecné / Re:Výkon - DISTINCT, JOIN
« Poslední příspěvek od Delfin kdy 10-12-2017, 19:20:05 »
Citace
Podivej se na execution plan. Ten Ti ukaze jak bude DBMS postupovat v pripade spousteni dotazu.
A po čase ho zmení :)  Viem o tom a to chcem použiť až pri ladení aplikácie.

Firebird muze zmenit plan pro stejny SQL prikaz pokud zmenis schema dotcenych tabulek (napr. pridanim indexu). Neverim na nejakou jeho umelou inteligenci (ze by napr. dokazal pro konstantni schema pro stejny SQL prikaz sledovat jeho vyuziti a prikaz v jednu chvili zacal optimalizovat vhodnejsim planem, pripadne spustenim jineho prikazu).

Jedna rada, pokud budes hledat tipy pro SQL, zkus najit specificke pro Firebird, trebas tady.
30
Obecné / Re:Avoid RIGHT OUTER JOINS
« Poslední příspěvek od pepak kdy 10-12-2017, 18:49:16 »
Abych řekl pravdu, ještě nikdy jsem nenarazil na situaci, kdy bych chtěl použít RIGHT OUTER JOIN. Ale nevidím žádný důvod se mu vědomě vyhýbat.
Stran: 1 2 [3] 4 5 ... 10