Otázky začínajúceho 2

[Stanislav Hruška]

Vlastne len jedna. Ide o overovanie údajov posielaných do DB. Nateraz to robím v aplikácii týmto spôsobom

Kód: [Vybrat]

procedure TfrmLandlord.LandlordPost;
begin
  with frmLandlord  do
  begin
    with FlatTable do
    begin
      if FieldByName('RoomNumber').IsNull then
      begin
        Fault('Zadajte číslo bytu');
        dbedtRoomNumber.SetFocus;
        Exit;
      end;
      if FieldByName('Floor').IsNull then
....

Tie podmienky sú komplikovanejšie, ak overujem platnosť údaja. Mám to dať na stranu DB. V tom prípade potrebujem minimálne:

- zistiť chybu, aby som vypísal správny oznam
- zistiť komponent, ktorého sa to týka. O ňom DB nevie vôbec nič. Kvôli SetFocus. Samozrejme, s tým údajom môžu pracovať rôzne komponenty na rôznych formulároch.

Ide mi o postup ako na to. Čo a ako použiť, naštudovať.

[pf1957]

Ide mi o postup ako na to. Čo a ako použiť, naštudovať.

Ja jsem v nasem frameworku udelal u predka formularu abstraktni mechanismus validace, kde je cirkus kolem Disable/UpdateControls a na nej navazujici CheckValidity, ResetInvalidControls, nejakej error box apod. Na kazdem formulari pak jenom prekryjeme virtualni metody DoUpdateControls, DoCheckValidity atd. a ty kontroly vcetne operace save jsou by default napojeny na OnCloseQuery event, takze je-li vse OK, data se ulozi a formular se zavre. Pri neplatnych datech se save nedela, jen ze zobrazi neplatna pole a nekam se v pripade potreby jeste vypisi chyby.

[Stanislav Hruška]

Pri tomto riešení predpokladám, že prechádzaš  celý formulár a hľadáš TEdit, TDBEdit a spol.

//Ja jsem v nasem frameworku udelal u predka formularu abstraktni mechanismus validace,
To sú techniky, ktoré vlastne nepoužívam a tým ani neovládam. Ale už by som mohol začať pracovať na kategórii nestriekač.

//kde je cirkus kolem Disable/UpdateControls a na nej navazujici CheckValidity, ResetInvalidControls, nejakej error box apod
Zoberme konkrétne CheckValidity. Som presvedčený, že podmienky či už skôr priamo vyhodnotenie dostaneš z DB. A tu neviem ako to získať (mám na mysli druh chyby null, neplatná hodnota, prázdny string...) a kto to (ktorý edit) spôsobil.
Tie ostné veci si viem predstaviť.

[pf1957]

Zoberme konkrétne CheckValidity. Som presvedčený, že podmienky či už skôr priamo vyhodnotenie dostaneš z DB. A tu neviem ako to získať (mám na mysli druh chyby null, neplatná hodnota, prázdny string...) a kto to (ktorý edit) spôsobil.

No nevim... Sice nejsem zadny DB specialista, ani nejsem zamereny na psani klientskych DB aplikaci. Na druhou stranu jsem pracoval se vsemi moznymi i nemoznymi DB pres ruzne konektivity na ruznych platformach a nikde jsem se s necim tak detailnim nesetkal.
Kdyz vezmu konkretne Ptaka ohnivaka a FIB+ komponenty, tak z nich dostaneme akorat:

Kód: Delphi [Vybrat]

1.     property LastKindIBError:   TKindIBError read FLastKindIBError;
2.     property LastSQLCode:       integer read FLastSQLCode;
3.     property LastIBErrorCode:   integer read FLastIBErrorCode;
4.     property LastRaiserName:    string  read FLastRaiserName;
5.     property LastSQLMessage:    string  read FLastSQLMessage;
6.     property LastIBMessage:     string  read FLastIBMessage;
7.     property LastCustomMessage: string  read FLastCustomMessage;
8.     property LastMsg:           string  read FLastMsg;

a ten kind vypada takhle:

Kód: Delphi [Vybrat]

1. TKindIBError = (keNoError, keException, keForeignKey, keLostConnect,keSecurity, keCheck, keUniqueViolation, keOther);

Takze se neco zjistit dat (jeste jsou tam nejake lexemy, ale temi jsem se nezabyval),  ale osobne si myslim,
ze by melo platit to, co u exceptions: ze se nemaji pouzivat k reseni logickych tj. predvidatelnych chyb, napr. deleni nulou tj. neosetrovat to ex post. Takze IMHO spravne je to vsechno otestovat a zobrazit BFU a pak teprve vykonat SQL command. Proto temer kazdy framework ma nejakou podporu pro validaci dat a data validuje predem.

Ale samozrejme nevidel jsem vsechno, ani jsem se o to nezajimal.

[Stanislav Hruška]

//Takze IMHO spravne je to vsechno otestovat a zobrazit BFU a pak teprve vykonat SQL command.
Veď to tak robím a vraj to mám zmeniť 
Pri kontrole dát na klientovi je knotrala v DB už len akousi poistkou. Bavím sa len o dátach.

[Mi.Chal.]

//Takze IMHO spravne je to vsechno otestovat a zobrazit BFU a pak teprve vykonat SQL command.
Veď to tak robím a vraj to mám zmeniť 
Pri kontrole dát na klientovi je knotrala v DB už len akousi poistkou. Bavím sa len o dátach.

bývá to na obou místech - v kódu ošetříš to, jestli ty data vůbec mají smysl (třeba jestli je něco vyplněno nebo abys do čísel nedával písmena). V db bývají různé kontroly a constrainty, aby data byla konzistentní (někdy se provádějí změny i jinak, než přímo z aplikace nebo do db může lézt nějaký další proces).

[pf1957]

//Takze IMHO spravne je to vsechno otestovat a zobrazit BFU a pak teprve vykonat SQL command.
Veď to tak robím a vraj to mám zmeniť 
Pri kontrole dát na klientovi je knotrala v DB už len akousi poistkou. Bavím sa len o dátach.

Nesleduju vsechny prispevky detailne, ale nezaregistroval jsem, ze by ti nekdo radil, ze nemas delat kontroly na strane klienta. Kontroly se do DB davaji proto, aby ti zadny klient nerozhazel data v DB a referencni integrida se pouziva proto, abys mel kontrolu nad vazbami mezi tabulkami tj. aby ti v DB nechybela/neprebyvala nejaka data. Ale takoveho klienta staci vyf*ckovat, at nedela v DB bordel.

Kontrola spravne zadanych parametru je uplne neco jineho - to souvisi s tim, aby byl klient user friendly. A cim vic ma byt friendly, tim vic toho na strane klienta musis udelat.  Jak pise Mi.chal, dela se oboje. Jedine, co pri paralelnim chodu vice klientu neotestujes dopredu jsou unique zalezitosti a zmeny hodnot z nekolika mist. Tam u SQL operace muze (a dochazi) ke kolizim, ktere se odchytavaji ex post a nejak se s BFU resi a dava se mu zpravidla sance operaci zopakovat.

[Stanislav Hruška]

Tak som to chápal od začiatku. Aspoň som si to opäť trocha premyslel.

//ale nezaregistroval jsem, ze by ti nekdo radil, ze nemas delat kontroly na strane klienta.
Nechce sa mi to hľadať, alebo bol tam príspevok ktorý tak minimálne vyznel. Ja som ho tak pochopil.

Mám dávať do DB úplnú kontrolu údajov? Mám na mysli kompletne zopakovať kontroly, ktoré vykonávam na klientovi. Predpokladám odpoveď ÁNO.

Chcem si upresniť. Commit sa používa len SP a spúšťach. Možno UDF? Príkazy Post, Delete, Insert a Update vykonávané z kleinta pomocou komponent to nevyžadujú.

[pf1957]

Mám dávať do DB úplnú kontrolu údajov? Mám na mysli kompletne zopakovať kontroly, ktoré vykonávam na klientovi. Predpokladám odpoveď ÁNO.

V podstate ano, ale nepristupoval bych k tomu jako k duplikovani (coz konotuje praci navic, praci zbytecnou apod.).

Spravne je nejdriv navrhnout databazovy model a vytvorit databazi. A volit kontroly a opatreni tak, aby strikaci, co k te databazi budou delat pozdeji ksichty, ji nemohli moc ublizit a zajistit, aby byla stale v logicky konzistentnim stavu.

Chcem si upresniť. Commit sa používa len SP a spúšťach. Možno UDF? Príkazy Post, Delete, Insert a Update vykonávané z kleinta pomocou komponent to nevyžadujú.

Ne. Commit je potvrzeni transakce a strikaci zhusta pouzivaji rezim s implicitnim rizenim transakci tzv. AutoCommit, kde se o to nestaraji, transakce se sami zahajuji a ukoncuji. Ale to je pristup: "neotravuj me s transakcema, stejne nevim k cemu jsou dobry". Jejich programy pak nikdy spravne nepracuji v paralelnim prostredi atd. IMHO by sis mel o transakcich neco precist a mel bys je explicitne ridit tj. zvolit typ transakce, jeji izolace, tu nastartovat, potvrdit a osetrit ji pomoci try-except s vhodnou zotavovaci akci. Smyslem transakce je zajistit, aby se nekolik SQL prikazu/operaci provedlo jako jedina tj. neprerusitelna akce, ktera se bud povede cela, nebo se cela zrusi.

SP a triggery pracuji v ramci (uvnitr) nejake transakce jako kterykoli jiny SQL prikaz. UDF = User Defined Function tj. neni to SQL prikaz ale jen funkce, kterou si napises v nejakem normalnim jazyku podle presnych pravidel a SQL server ti ji umozni ve tvych SQL prikazech pouzivat.

[Stanislav Hruška]

Vďaka! Len na to čítanie mám toho veľmi veľa. Takže postupne. Čítam veľmi pomaly.

//aby strikaci, co k te databazi budou delat pozdeji ksichty, ji nemohli moc ublizit a zajistit
Toto ma nenapadlo, aj keď to u mňa nehrozí. Zatiaľ.

[pf1957]

Vďaka! Len na to čítanie mám toho veľmi veľa. Takže postupne. Čítam veľmi pomaly.

Jak říkal klasik: životem se člověk musí pročíst 

IMHO pro ziskani zakladniho prehledu je nejvhodnejsi Wikipedie - napr. chci vedet, co jsou transakce zac, prectu si to tam a hned tam mam hafo odkazu na dalsi detaily, kdyz me zajimaji. A v te wikipedii je zhruba to, co se dneska studenti uci na VS, takze v IT skoro vsechno. Ma to svoje nedostatky, protoze treba puvodni pojem serializace ve smyslu synchronizace tj. razeni procesu v case za sebou uplne vymizel a dnes tak rikaji jen prevedeni dat do/z vysilatelne formy apod., ale i tak je to nejlepsi zdroj, jaky mame.

[Mi.Chal.]

Ne. Commit je potvrzeni transakce a strikaci zhusta pouzivaji rezim s implicitnim rizenim transakci tzv. AutoCommit, kde se o to nestaraji, transakce se sami zahajuji a ukoncuji. Ale to je pristup: "neotravuj me s transakcema, stejne nevim k cemu jsou dobry". Jejich programy pak nikdy spravne nepracuji v paralelnim prostredi atd.

to záleží na tom, co děláš - každý dotaz se pouští v automatické transakci. Pokud změny děláš jenom jedním updatem/deletem/insertem, tak je zbytečné to explicitně obalovat další transakcí.

[pf1957]

to záleží na tom, co děláš - každý dotaz se pouští v automatické transakci. Pokud změny děláš jenom jedním updatem/deletem/insertem, tak je zbytečné to explicitně obalovat další transakcí.

Souhlasim. Ale ja davam prednost, aby se v cele aplikaci delali stejne operace stejnym zpusobem a ne aby kazdy formular pracoval treba s DB jinym, v tomto pripade mene obecnym, zjednodusenym zpusobem. Pak kazda zmena pri udrzbe softu, pouzivajici takova zjednodusena reseni vede k rozsahlejsim zmenam, v tomto pripade zabudovani explicitniho rizeni transakce.  Takze takovy soft se o trochu rychleji nastrika, ale dost blbe se udrzuje.

Ale jsem si vedom, ze stoupenci YAGNI pristupu se mnou budou hrube nesouhlasit Ale jak pises, zalezi na tom, co kdo dela, jestli potrebuje honem neco nastrikat, pustit mezi lidi a kdyz to neni ono, tak honem strikat neco jineho, nebo jestli delas soft, ktery bude zit cele roky a bude na nem delat cela rada lidi a je u nej dulezita spolehlivost.