Forum Delphi.cz

Databáze => Obecné => Téma založeno: Stanislav Hruška 16-06-2018, 10:16:27

Název: Debbug - GTT voči RunTime persistent table
Přispěvatel: Stanislav Hruška 16-06-2018, 10:16:27
Mám v DB 31 tabuliek, ktoré chcem previesť na GTT.
Počas ladenia je dobré aby som ich mal k dispozícii ako persistent. Aby som videl ich obsah. A v Runtime ako GTT. Nebudú zbytočne nafukovať DB.
Ako sa to rieši? Dvoma samostatnými DB?
Název: Re:Debbug - GTT voči RunTime persistent table
Přispěvatel: Stanislav Hruška 16-06-2018, 15:06:40
Ďakujem, len si musím teraz vymyslieť spôsob povedať programu, s ktorými tabuľkami má pracovať.
Prvotný nástrel je, že pre GTT použijem rovnaké názvy ako pri persistent. Akurát s tým rozdielom, že vynechám v názve koncové "S". Alebo niečo podobné. Tak si tie názvy budem môcť získať priamo v kóde.
Alebo si jednoducho vytvorím ich zoznamy = dva zoznamy.
Název: Re:Debbug - GTT voči RunTime persistent table
Přispěvatel: Stanislav Hruška 16-06-2018, 15:20:46
Neviem či by mi toto prišlo na um ;D . Pribudne mi síce práca s udržovaním dvoch totožných DB, ale stojí to zato. Lebo ak sa bude v budúcnosti čosi meniť, tak nebudem mať problém.
Název: Re:Debbug - GTT voči RunTime persistent table
Přispěvatel: Stanislav Hruška 16-06-2018, 16:31:15
Vďaka za ponuku, ale ja si to urobím ručne. Nie je to zas tak strašné. Dosť často použijem vytvoriť kópiu tabuľky a len z nej vyhodím nejaké pole. Čas ma netlačí.
Citace
Tim bys vubec nemusel zasahovat do kodu.
Malý zásah tam musím urobiť. Tie trvalé tabuľky sa samé nevyprázdnia. Je to podmienka pre správny priebeh výpočtov.
Název: Re:Debbug - GTT voči RunTime persistent table
Přispěvatel: Stanislav Hruška 16-06-2018, 16:57:35
Až teraz som všimol, že mám ten nadpis zle. Má byť:
Debbug - persistent table voči RunTime GTT
Název: Re:Debbug - GTT voči RunTime persistent table
Přispěvatel: pf1957 16-06-2018, 17:36:44
Mám v DB 31 tabuliek, ktoré chcem previesť na GTT.
Počas ladenia je dobré aby som ich mal k dispozícii ako persistent. Aby som videl ich obsah. A v Runtime ako GTT. Nebudú zbytočne nafukovať DB.
Ako sa to rieši? Dvoma samostatnými DB?
Ja bych to vubec neresil.
Název: Re:Debbug - GTT voči RunTime persistent table
Přispěvatel: Stanislav Hruška 16-06-2018, 18:13:47
Pri momentálnom stave predpokladám nárast DB na dvojnásobok. Plus indexy a ich réžia. Mne to stojí zato. Je pravda, že môžem použiť persistent tabuľky a na začiatku/konci (podľa potreby) výpočtu ich vyprázdniť.
Väzby v nich môžem zrušiť a tým sa zbaviť indexov.
Název: Re:Debbug - GTT voči RunTime persistent table
Přispěvatel: pf1957 16-06-2018, 20:02:28
Pri momentálnom stave predpokladám nárast DB na dvojnásobok. Plus indexy a ich réžia. Mne to stojí zato. Je pravda, že môžem použiť persistent tabuľky a na začiatku/konci (podľa potreby) výpočtu ich vyprázdniť.
Väzby v nich môžem zrušiť a tým sa zbaviť indexov.
Ne ze bych GTT nepouzival, ale jenom tam, kde si potrebuju neco vytahat/predpocitat ze slozitych dat, tedy
a) nejde to udelat SQL dotazem, musi  se to udelat proceduralne v SP
b) potrebuju to udelat na serveru a data netahat na klienta.

Ale prednost bych dal temer cemukoli pred udrzbou 2 ruznych DB: kdysi jsem byl donucen udelat nad FB replikaci lokalnich a centralni DB a schema pro centralni jsem vyrabel scriptem, ktery ho vyrobil z lokalni DB. Ale co to bylo za onanii, kdyz pri kazde zmene schematu lokalni DB se muselo jeste sahnout do scriptu :-( Uz nikdy vice. 

Mezitim se nastesti vlastnosti infrastruktury zlepsily natolik, ze soucasna verze ten cirkus s replikaci DB nepouziva a vsechno jede proti jedine centralni DB.
Název: Re:Debbug - GTT voči RunTime persistent table
Přispěvatel: Stanislav Hruška 16-06-2018, 20:26:27
Citace
Ale prednost bych dal temer cemukoli pred udrzbou 2 ruznych DB
To už ste dvaja. Dám si povedať.
Citace
Pro perzistentni tabulku s konkurencnim pristupem by bylo treba jeste pridat sloupec ktery by zaznamy pro pristupujici rozlisil.
To nie je problém. Stačí sa vrátiť k stavu z dnešného rána ;D ;D ;D  A to som celkom tvrdo makal :o  Aj takým spôsobom sa človek učí.
Akurát sa zbavím indexov, prepojení tabuliek pomocou foreign key. Bude tam málo záznamov. Rádovo stovky, takže aj tak by sa neuplatnili.
Název: Re:Debbug - GTT voči RunTime persistent table
Přispěvatel: Stanislav Hruška 16-06-2018, 20:57:48
Jsem za 2 databaze. Ale s fixnimi sadami testovacich dat (jen pro vyvoj a testovani). Urcite bych se nesnazil delat klon produkcni jen proto abych mohl videt mezivysledky vypoctu.

Cile by se dalo s uvedenym objemem dosahnout nejspis i jinak. Nemam ted moc predstavu zda se tu bavime o DBMS procedurach nebo zda je kod v Delphi aplikaci, nicmene v obou pripadech by se dalo jit primo cestou GTT jen si bud pred koncem vypoctu (vyprazdnenim te GTT tabulky) volitelne vratit data jako (sadu) resultset(u) nebo naplnit perzistentni tabulku(y).
Čo sa týka testovania, tak 2 DB budem mať. Potrebujem v budúcnosti ladiť výkon a to sa s ostrými údajmi nedá. Kto by tam nahadzoval do jednej tabuľky niekoľko stotisíc záznamov. Pre zaistenie funkčnosti app. a správnosti výpočtov ich tam je len pár. A pre ladenie výkonu mi úplne postačia náhodné údaje.
Procedúry, view ani nič podobné nepoužívam. Všetko mám v Delphi. Jedine ak ma donúti situácia. Tie GTT by som zvládol, ale z diskusie vyplynulo, že by to bola zbytočná komplikácia.
Podľa mňa GTT majú ešte jednu výhodu. Ich údaje sú uložené len v pamäti a tak nerozbíjajú DB. To sa o trvalých tabuľkách tvrdiť nedá. Ak sa mýlim, tak ma opravte.
Název: Re:Debbug - GTT voči RunTime persistent table
Přispěvatel: Stanislav Hruška 16-06-2018, 21:09:43
Ja som k tým GTT pristúpil preto, aby som sa vyhol viacnásobnému použitiu subselect-ov. Poniektoré sú zložitejšie. Ja sa stále snažím šetriť systémové prostriedky. Aj keď sa tomu skoro každý čuduje. Ja som už taký skúpy od prírody.
Název: Re:Debbug - GTT voči RunTime persistent table
Přispěvatel: pf1957 16-06-2018, 21:22:35
Podľa mňa GTT majú ešte jednu výhodu. Ich údaje sú uložené len v pamäti a tak nerozbíjajú DB. To sa o trvalých tabuľkách tvrdiť nedá. Ak sa mýlim, tak ma opravte.
To nevim, jak jsi k tomu dospel. I kdyz FB je u nas pod tlakem zakazniku na ustupu, tak jsem se schvalne podival, co o tom pise Helen Borrie ve FireBird book, kdyz uz ho mam: "...GTT je alokovana ve vlastnich "soukromych" strankach, ktere maji shodny format jako bezne tabulky a ktere se po commitu uvolni...". Takze me z toho plyne:
a) neni pravda, ze jsou jen v pameti
b) jejich alokace muze zpusobovat fragmentaci stranek,
c) pravidelnou udrzbu DB bys mel provadet bud jak bud
Název: Re:Debbug - GTT voči RunTime persistent table
Přispěvatel: Stanislav Hruška 16-06-2018, 21:52:32
S pravidelnou údržbou DB do budúcnosti počítam.
Na základe diskusie dávam prednosť trvalým tabuľkám. Nie je problém ich udržať prázdne. DB som si už upravil. Ešte mám podlžnosti v kóde. Aj zajtra je deň.
Název: Re:Debbug - GTT voči RunTime persistent table
Přispěvatel: Stanislav Hruška 19-06-2018, 08:36:15
Nemôžem si pomôcť, ale mne to akosi nedá. To riešenie s trvalými tabuľkami považujem za nečisté.
Rozmýšľam nad takýmto riešením:
Pri GTT sa nemusím starať o filtrovanie údajov ani ich aktualizáciu.
Název: Re:Debbug - GTT voči RunTime persistent table
Přispěvatel: pf1957 19-06-2018, 09:11:25
Nemôžem si pomôcť, ale mne to akosi nedá. To riešenie s trvalými tabuľkami považujem za nečisté.
Rozmýšľam nad takýmto riešením:
  • Ja budem mať v DB GTT i persistent tables
  • Pre SQL budem mať dva druhy textov. Rozlišované podľa direktívy {$IFDEF DEBUG}. To je "drobnosť", ktorá podľa mňa stojí za to
  • Vytvorím si nejaký príznak, že to som ja alebo nie. To ešte netuším ako. Do budúcna to musí byť automatické
  • U zákazníka pomocou skriptu urobím zrušenie nepotrebných trvalých tabuliek (Drop Table). Tým pádom sa o DB "nemusím" starať
Pri GTT sa nemusím starať o filtrovanie údajov ani ich aktualizáciu.
Nevim, co je na tabulkach necisteho: predstav si, ze by zadne GTT neexistovaly.
Ale pak bych se vratil k myslence pro ucely ladeni si udelat "vizualizaci" tech dat v GTT, treba triggerem, ktery je prekopiruje do presistentni tabulky. Pak u produkcni DB dropnes jen ty triggery a tabulky. A before insert triggerem si zjistis, jestli je GTT prazdna a jestli ano, tak smazes data z te kopie.
Název: Re:Debbug - GTT voči RunTime persistent table
Přispěvatel: Stanislav Hruška 19-06-2018, 09:24:28
Citace
Nevim, co je na tabulkach necisteho
Na samotných tabuľkách nič. Len pri ich použití mám/PC prácu navyše. Pri trvalých tabuľkách automaticky definujem Foreign key. Bez nich si to nedovolím - určil som si také pravidlo. A už vďaka tomu nabieha navyše práca s indexmi + veľkosť DB. Prosím nekomentovať veľkosť DB :)
Citace
Ale pak bych se vratil k myslence pro ucely ladeni si udelat "vizualizaci" tech dat v GTT, treba triggerem, ktery je prekopiruje do presistentni tabulky. Pak u produkcni DB dropnes jen ty triggery a tabulky. A before insert triggerem si zjistis, jestli je GTT prazdna a jestli ano, tak smazes data z te kopie.
To mi akosi nesedí. Nevidím na to dôvod. Pri ladení budem používať len GTT. Možno to je myslené ako ochrana proti zaneseniu chýb do program. V takom prípade by som o tom mal uvažovať.
Název: Re:Debbug - GTT voči RunTime persistent table
Přispěvatel: pf1957 19-06-2018, 09:26:57
To mi akosi nesedí. Nevidím na to dôvod.
A ja mel za to, ze cely cirkus s GTT vymyslis kvuli ladeni, aby videl na data i po skonceni transakce. Pokud ne, tak bych to uz vubec neresil.
Název: Re:Debbug - GTT voči RunTime persistent table
Přispěvatel: Stanislav Hruška 19-06-2018, 09:30:42
Citace
A ja mel za to, ze cely cirkus s GTT vymyslis kvuli ladeni, aby videl na data i po skonceni transakce.
Presne tak!!!
Název: Re:Debbug - GTT voči RunTime persistent table
Přispěvatel: pf1957 19-06-2018, 09:34:57
Citace
A ja mel za to, ze cely cirkus s GTT vymyslis kvuli ladeni, aby videl na data i po skonceni transakce.
Presne tak!!!
No a tak bych si je z GTT kopiroval triggerem do nejake presistentni tabulky se stejnou strukturou, kde bych se na data mohl divat. A pak bych to odstranil. A kod aplikace by o tom vubec nevedel, jen by to zralo nejaky cas na ty kopie.
Název: Re:Debbug - GTT voči RunTime persistent table
Přispěvatel: Stanislav Hruška 19-06-2018, 09:39:25
Už mi to došlo ;D , len si ma predbehol v napísaní reakcie. Myslím si, že už je rozhodnuté. Len si premyslieť aplikovanie. Trochu ma mätie ten triggert, ale to si doštudujem. Asi máš na mysli niečo ako "After Insert". Aplikácia o tom bude vedieť. Veď sa musí rozhodnúť, či mazať, alebo nemazať tie údaje.
Ďakujem.
Název: Re:Debbug - GTT voči RunTime persistent table
Přispěvatel: Stanislav Hruška 19-06-2018, 09:51:05
Mne by sa viac páčilo, keby sa triggert nespustil, keď neexistuje trvalá tabuľka. Presnejšie, spustil by sa, ale po vyhodnotení podmienky aj hneď ukončil. Ja viem, je to pre DB práca navyše = nie je to čisté :D
Název: Re:Debbug - GTT voči RunTime persistent table
Přispěvatel: pf1957 19-06-2018, 10:09:17
Mne by sa viac páčilo, keby sa triggert nespustil, keď neexistuje trvalá tabuľka. Presnejšie, spustil by sa, ale po vyhodnotení podmienky aj hneď ukončil. Ja viem, je to pre DB práca navyše = nie je to čisté :D
Proc bys to delal? Kdyz neexistuje trvala tabulka, tak bud neexistuje trigger nebo ja zablokovany a vice versa, kdyz se vytvori trvala tabulka, tak se vytvori i replikacni trigger nebo se enabluje.

Takze pri vyvoji vytvoris trvalou tabulku a replikacni trigger, v produkci je smazes. A pri vyvoji, kdyz nebudes chtit replikovat, tak ten trigger zakazes a on bude existovat, ale nebude se pouzivat.
Název: Re:Debbug - GTT voči RunTime persistent table
Přispěvatel: pf1957 19-06-2018, 10:29:09
máš na mysli niečo ako "After Insert". Aplikácia o tom bude vedieť. Veď sa musí rozhodnúť, či mazať, alebo nemazať tie údaje.
To muze delat treba i ten trigger nezavisle na aplikaci - ta to oznami commitnutim transakce a vyprazdnenim GTT. Takze kdyz v BeforeInsert triggeru bude GTT prazdna, tak to znamena, ze se spustilo nove zpracovani v nove transakci a muze vyprazdnit nejdriv trvalou tabulku. Totez muze udelat i s AfterInsert, kdy zjisti, jestli prave vlozeny zaznam je jediny v GTT nebo muzes mit triggery dva: before na hlidani noveho zpracovani a after na replikaci dat.
Název: Re:Debbug - GTT voči RunTime persistent table
Přispěvatel: Stanislav Hruška 19-06-2018, 10:36:19
Citace
Takze kdyz v BeforeInsert triggeru bude GTT prazdna, tak to znamena, ze se spustilo nove zpracovani v nove transakci a muze vyprazdnit nejdriv trvalou tabulku.
Výborne, to sa mi páči.
S triggert-om som pracoval kedysi dávno a tak o ich možnostiach nemám predstavu.
Název: Re:Debbug - GTT voči RunTime persistent table
Přispěvatel: Stanislav Hruška 19-06-2018, 20:48:24

Citace
Muzes i pred smazanim te tabulky (tj. pred ukonceni transakce nebo spojeni) ziskat jeji obsah ze sve aplikace (jednoduse SELECTtem
To viem. Veď bez toho by mi boli nanič.
Riešenie pomocou spúští sa mi veľmi páči. Nebudem zasahovať do zdrojáku. A v DB tie spúšte budem kopírovať a len zmením  názvy tabuliek. Krása :D