Forum Delphi.cz

Databáze => Obecné => Téma založeno: Stanislav Hruška 20-12-2017, 11:16:20

Název: Parametrizované príkazy
Přispěvatel: Stanislav Hruška 20-12-2017, 11:16:20
Tému zakladám na základe tejto diskusiehttp://forum.delphi.cz/index.php/topic,15942.msg98307.html#new{http://forum.delphi.cz/index.php/topic,15942.msg98307.html#new (http://forum.delphi.cz/index.php/topic,15942.msg98307.html#new{http://forum.delphi.cz/index.php/topic,15942.msg98307.html#new)
Je pre mňa zaujímavá a má mať vlastné vlákno. Mám tu zmätok, nedostatok vedomostí a pod.
Citace
Vždycky když někde vidím, jak má někdo v kódu SQL příkaz INSERT a kousek dál jiný kód s SQL UPDATE, a tam všude nastříkané parametry, tak se zarazím.
Ja si to bez parametrov predstaviť neviem. Mám k dispozícii dva varianty.
Kód: [Vybrat]
INSERT INTO MYTABLE
(FIELD1, ...)
VALUES(:PARAM1,...)
alebo
Kód: [Vybrat]
INSERT INTO MYTABLE
SELECT * FROM TABLE1
WHERE ...
Toto si bez časti WHERE neviem predstaviť. Pri UPDATE je to tak isto.
Citace
Až na vyjimky, kdy opravdu musím cpát data opravdu rychle, nebo kde je ve where řetezec, si nechávám generovat update a insert přes následníka TDataset (Firedac, ADO) ze sikovneho jednoducheho SQL přikazu a používám společný kód s FieldByName a Edit nebo Append a Post.
Už tu viackrát zaznelo, že mám mať nejaký generátor SQL textov. Žiaľ, doteraz sa mi nepodarilo vytvoriť si o ňom žiadnu predstavu. Sem tam sa mi niečo opakuje. V mnohých prípadoch o tom ani netuším. Lenže v princípe je každé SQL unikátne. A na tom končím :'( 
Ako sa to dá robiť pomocou potomka TDataset je pre mňa záhadou.
Rád by som už konečne vedel, ako sa to generovanie SQL textov dá generovať bez toho, aby som sa z toho zbláznil.

Ak si na to vytvorím triedu, tak jej musím poslať nejaký parameter. Tých parametrov budú stovky. To podľa mňa znamená "nekonečne" dlhý case/if. Či... ??
Název: Re:Parametrizované príkazy
Přispěvatel: raul 20-12-2017, 11:28:56
Pouzival jsem pred lety PostgresDAC. Rozdil rychlosti pouziti primo parametrizovanych dotazu a klasiky byl propastny - pro me. Samozrejme ne vzdy tomu tak je, ale rozhodne bych se k tomu nestavel jako Radek, ze zpozornim, kdyz to nekdo pouzije. Naopak mi to rekne, ze ten clovek dela kod sviznejsi - pokud ho teda jen nechce zobrazit na formu apod. GUI aplikace nedelam, spise serverove veci.

 Jemne podobnou diskusi jsme vedli pred lety s jednim kolegou - jeho nazor, ze nechape k cemu je dnes pointerova aritmetika - nechapu ja. Treba pri zpracovani obrazu - idealni a nejrychlejsi.

Obecne myslim, ze zalezi na tom, jak z vejsky na to clvoek kouka - chce-li rychle neco napsat, pak klido. Chce-li psat dele, ale mit kod rychlejsi, pak jednoznacne parametricky.

Generator se da napsat velmi jednoduchy - treba neco jako : genInsert(string tablename; fields : array of string) : string; - kterej udela INSERT INTO <tablename> (<field1>,<field2>) VALUES(:<field1>,:<field2>) - pripadne libovolne upravit s pridanim automatickych polozek apod.
Název: Re:Parametrizované príkazy
Přispěvatel: Delfin 20-12-2017, 12:19:52
Tady se, alespon jak jsem to pochopil, micha vice veci dohromady. Radek ma nejspis na mysli konstrukci podobnou teto - pisu z hlavy do web browseru a tuto konstrukci radu let nepouzivam (raul ji oznacil jako "klasiku"):

Kód: Delphi [Vybrat]
  1. Query.SQL.Text := 'SELECT ID, MyColumn FROM MyTable';
  2. Query.Open;
  3.  
  4. Query.Append;
  5. Query.FieldByName('MyColumn').AsInteger := 666;
  6. Query.Post;
  7.  
  8. Query.Locate('ID=1'); // tady by mela byt navic konstrukce s ulozenim a restore bookmark kurzoru
  9. Query.Edit;
  10. Query.FieldByName('MyColumn').AsInteger := 777;
  11. Query.Post;
  12.  

Zatimco parametrizovany ekvivalent by mohl byt nejak takto:

Kód: Delphi [Vybrat]
  1. Query.SQL.Text := 'SELECT MyColumn FROM MyTable';
  2. Query.Open;
  3.  
  4. Query.SQL.Text := 'INSERT INTO MyTable (MyColumn) VALUES (:MyColumn)';
  5. Query.ParamByName('MyColumn').AsInteger := 666;
  6. Query.ExecSQL;
  7.  
  8. Query.SQL.Text := 'UPDATE MyTable SET MyColumn = :MyColumn WHERE ID = :ID';
  9. Query.ParamByName('ID').AsInteger := 1;
  10. Query.ParamByName('MyColumn').AsInteger := 777;
  11. Query.ExecSQL;

Prvni blok kodu vygeneruje interne dotazy podobne tem co jsou v druhem bloku kodu. Mozna tim byl myslen ten generator. Tezko rict... Jinak souhlas s raulem, osobne bych spis zpozornil kdyby nekdo pouzil to co je k videni v prvnim bloku.
Název: Re:Parametrizované príkazy
Přispěvatel: Stanislav Hruška 20-12-2017, 13:08:00
viď raul
Citace
Generator se da napsat velmi jednoduchy - treba neco jako : genInsert(string tablename; fields : array of string) : string; - kterej udela INSERT INTO <tablename> (<field1>,<field2>) VALUES(:<field1>,:<field2>) - pripadne libovolne upravit s pridanim automatickych polozek apod.
Pre tieto typy SQL (INSERT s VALUES) to ide. Vďaka. To si prerobím.
A ako na ostatné?
viď Delfin: zásadne to robím podľa druhého bloku. Akonáhle mám WHERE, CASE či niečo iné, čo má dostať niečo zvonka, tak to robím jedine cez parameter. Okrem iného mi to kontroluje správnosť typov a zbavuje potreby používať CAST. A že som sa už neraz sekol :)
Název: Re:Parametrizované príkazy
Přispěvatel: Delfin 20-12-2017, 13:13:36
Citace
Generator se da napsat velmi jednoduchy - treba neco jako : genInsert(string tablename; fields : array of string) : string; - kterej udela INSERT INTO <tablename> (<field1>,<field2>) VALUES(:<field1>,:<field2>) - pripadne libovolne upravit s pridanim automatickych polozek apod.
Pre tieto typy SQL (INSERT s VALUES) to ide. Vďaka. To si prerobím.
A ako na ostatné?
Delfin: zásadne to robím podľa druhého bloku. Akonáhle mám WHERE, CASE či niečo iné, čo má dostať niečo zvonka, tak to robím jedine cez parameter. Okrem iného mi to kontroluje správnosť typov a zbavuje potreby používať CAST. A že som sa už neraz sekol :)

No, a chces stavet "entity framework"? Nebo pro co chces vyrabet generator SQL prikazu (FireDAC totiz v sobe jeden ma)?
Název: Re:Parametrizované príkazy
Přispěvatel: Stanislav Hruška 20-12-2017, 13:16:42
Citace
Nebo pro co chces vyrabet generator SQL prikazu (FireDAC ma jeden v sobe)?
Lebo tu každý do mňa hučí, že tak to je správne ;D Niečo pravdy na tom je. Viď opakované pasáže. A že formulár má byť hlúpy. A robiť inteligentnú jednotku pre každý formulár sa mi nezdá to pravé.
Název: Re:Parametrizované príkazy
Přispěvatel: raul 20-12-2017, 13:26:10
Ostatne podobne -
genUpdate(string tablename; fields : array of string; ID : boolean; native_where : string) : string;
kterej udela
pokud je ID true:
UPDATE <tablename> SET <field1>=:<field1>,<field2>=:<field2> WHERE ID=:ID
pokud je ID false:
UPDATE <tablename> SET <field1>=:<field1>,<field2>=:<field2> WHERE <native_WHERE>

mySQL tusim ma prikaz REPLACE, neco podobneho ma uz i snad pgSQL, kde pokud primarni klic neni nalezen, udela se insert. Jinak samozrejme je mozno udelat hafo dalsich, realne pouzivam slozitejsi konstrukce, ale ty jsou odvisle nad db schematem, ktere pouzivam leta. Tyto konstrukce pak zajisti i spravne generovani tabulek vcetne historie atd atd atd - moznosti je velmi. Pokud clovek delat ciste GUI klikatko, tak klido pouzit klasicke komponenty -  od dob BDE. Pokud vsak chce rychlost, pak je toto rychlejsi - cokoliv univerzalniho je proste pomale a mnbohdy zbytecne (Treba ziskavat barvu obrazku pres getPixel ci jak se to jmenuje (overuje abys nekoukal za roh atd - mozna uz to tam neni, ale kdysi kdysi snad bylo - mozna v delphi, mozna ve VB, bavim se obecne).

Pokud se bavime o slozitejsich insertech apod, pak zasadne pres SP, kterou proste jen zavolam - na coz mam i generator (opet navazany na ekosystem). Takze zavolani metody delphi je stejne jako metody na SQL vcetne typu. Jo, musim mit precompiler. A jo, je to rychle a elegantni.
Za ty leta jsem si proste napsal generator db, a pak tyhle drobotiny kolem, nekdy slozite, nekdy jen jednoduche byt praci ulehcujici.
Nejak jsem moc neprivyk tem internim vymysleninam - coz nebrat zle, jen proste vzdy tam bylo cosik - opakuji GUI skoro nepisu. Ono je prima, ze se to kolikrat da naklikat jednoduse, a pak k tomu pustej zhuverilce (kterej nevi, ze existuje index v db), kterej naklika takovou sracku, ze se z toho server pos... (Resil jsem optimalizaci import dat jedne automobilky - prichazeji denne, import trval 8-16h (jednak diky dodavateli dat, druhak kvuli kokotovi co to psal)).
Název: Re:Parametrizované príkazy
Přispěvatel: Stanislav Hruška 20-12-2017, 13:45:45
Pracujem s FB, ale je to obecná téma.
Ja som mal na mysli SELECT-y. INSERT A UPDATE sú dosť priamočiare, aj si to vysvetlil, ale SELECT...
SP nemám ani jednu. Z dôvodu, aby som neodkryl logiku programu. Dnes už viem, že to až tak veľa neprezradí.
Název: Re:Parametrizované príkazy
Přispěvatel: raul 20-12-2017, 13:53:47
Aha :) Selecty generuju primo ze schematu tim prekompilerem, takze tam me ted z patra nenapada nic. Ono to zalezi i na stavbe aplikace, jak se k datum pristupuje apod. Nicmene opet je to tak, ze jednoduche dotazy se mi vygeneruji primo - dle zadani prekompileru a slozitejsi zapouzdrim do view ci SP, kterou opet prozenu prekompilerem, takze pripravi patricne metody. Rucne bych to uz delat ani nechtel, prece jen mam to schema relativne slozite atd. V pripade, ze stavim cosik slozitejsiho, tak nad objektem SQL mam i adaptivni cache (jednak umoznuje ulozit vice variant dat, druhak neni zavisla na case, ale koeficientu pouziti s moznosti ji flushout automaticky pri insertu), proto me pak netrapi pustit dotaz x-krat treba atd.
Název: Re:Parametrizované príkazy
Přispěvatel: pf1957 20-12-2017, 14:01:55
Ja som mal na mysli SELECT-y. INSERT A UPDATE sú dosť priamočiare, aj si to vysvetlil, ale SELECT...
No vzdyt to chapes spravne: se SELECTem se moc podstatneho udelat neda, pokud se nejedna o flat tabulku nebo tahani vysledku vracenych SP nebo view...

I pri pouziti treba toho Entity Frameworku:
- kdyz vkladam do DB tak vytvarim instance objektu a ty propojuju, prirazuju jim hodnoty a nakonec udelam SaveChanges() a EF se mi postara o vlozeni do DB vcetne vygenerovani umely PK a vyreseni referenci
- kdyz menim strom objektu, tak ho nejakym dotazem natahnu, EF ho ma pripojeny k trackeru, ktery sleduje, co menim, prirazuju hodnoty objektum a dam SaveChanges() EF se postara o aktualizaci dat v DB

Ale u tech selectu, tam nezbyde nez napsat dotazy a jak pises, skoro kazdy je jiny - taha jina data, z jinak provazane sady entit atd. Takze jediny rozdil je, ze ja to pisu ve vyspelem jazyku LINQ pro SQL, ktery operuje s objekty a ma plnou podporu prekladace se silnou typovou kontrolou (zadna jmena sloupcu v uvozovkach jako text, zadne sestavovani SQL prikazu) a je zaclenen do jazyk C#, takze spoustu chyb zachyti pri psani/prekladani kodu a ty to musis zastarale matlat nekde ve stringach na urovni sr*ckoidniho SQL mimo kontrolu prekladace a na prvni chyby narazis az spi spusteni toho SQL, coz je zdlouhave, pracne a tudiz nakladne...
Název: Re:Parametrizované príkazy
Přispěvatel: Delfin 20-12-2017, 14:04:47
Citace
Nebo pro co chces vyrabet generator SQL prikazu (FireDAC ma jeden v sobe)?
Lebo tu každý do mňa hučí, že tak to je správne ;D Niečo pravdy na tom je. Viď opakované pasáže. A že formulár má byť hlúpy.

To jo, s tim urcite souhlas. Ja jen nevedel o jakem generatoru se bavime :) A porad to nejak nevim. Ty chces sestavit model z Delphi trid a vygenerovat pro nej schema databaze a vsechny potrebne dotazy? Nebo obracene? Nebo jakou mas predstavu?
Název: Re:Parametrizované príkazy
Přispěvatel: Radek Červinka 20-12-2017, 14:09:30

Kód: Delphi [Vybrat]
  1. Query.SQL.Text := 'SELECT ID, MyColumn FROM MyTable';
  2. if GenerateInsert then
  3.   Query.SQL.Add('WHERE 1 = 0')  // vrati prazdny zaznam, jen s fieldy
  4. else
  5.   Query.SQL.Add('WHERE ID = xxx'); // to je priklad, vrati prave jeden zaznam pro edit nebo delete
  6. // konec generatoru
  7. Query.Open;
  8.  
  9. if Query.isEmpty then
  10. begin
  11.    Query.Append;
  12.    // primarni ID
  13. end
  14. else
  15.    Query.Edit; // nebo delete podle toho co potrebuji
  16. Query.FieldByName('MyColumn').AsInteger := 666;
  17. Query.Post;
  18.  

Je to SILNE zjednoduseni, ale podle parametru mi to vygenruje na jednom miste prikaz pro SELECT, INSERT, UPDATE nebo DELETE. Pricemz pro SELECT mi to pripoji JOIN tabulky.

Interne pak DB komponenty vygeneruji parametrizovany INSERT nebo Update, nebo DELETE pro zmenene pole.  Takze nejen ze mam veskere zapisy na jednom miste, ale taky nemusim resit zda se nejake pole zmenilo atd.
Nevyhoda je, ze prvni Open je dotaz do DB navic (protoze to mam generovane vzdy dynamicky). Ale to mi za to stoji, hlavne z hlediska udrzitelnosti a prehlednosti kodu.

Update: ten generator je v samostatne tride (modulu), takze v celem programu ani v zadnem data modulu nejsou SQL prikazy.

Název: Re:Parametrizované príkazy
Přispěvatel: Radek Červinka 20-12-2017, 14:13:50
Nez mne zacnete lincovat :-), je to jen koncept toho co pouzivam.
Název: Re:Parametrizované príkazy
Přispěvatel: pf1957 20-12-2017, 14:18:19
Nez mne zacnete lincovat :-), je to jen koncept toho co pouzivam.
Me neni jasne, kdyz nedefinujes joiny, jak "neco" pozna, jak je spravne vytvorit, vzdyt muze jit o ruzne typy joinu, self-joiny provazane nekdy pres prosty FK, jindy pres vice poli atd...
Název: Re:Parametrizované príkazy
Přispěvatel: Radek Červinka 20-12-2017, 14:33:51
Nez mne zacnete lincovat :-), je to jen koncept toho co pouzivam.
Me neni jasne, kdyz nedefinujes joiny, jak "neco" pozna, jak je spravne vytvorit, vzdyt muze jit o ruzne typy joinu, self-joiny provazane nekdy pres prosty FK, jindy pres vice poli atd...


Generator je vzdy pro konkretni tabulku. Pro aktualizaci (resp. zapis) to vzdy vrati konkretni zaznam , tzn. ze pripadne joiny (ciselniky) jsou v transakci vytvareny predtim. Ale jelikoz si je uzivatel vetsinou vybere v GUI tak je jasne ze jsou v DB.

napr. jednoducha tabulka pro staty
Kód: [Vybrat]
procedure TSQLManagerTables.OpenQState(DataSet: TDataSet; eOperation: TEnum_OpenOperation;
  iID: Integer = 0; iCurrency: Integer = 0);
var
  bJoinTables: Boolean;
  sMainFilter, sSecondFilter: string;
begin
  with (DataSet as TBaseDataset) do
  begin
    if Active then
      Close;

// podle typu SQL vygeneruje hlavni where
    gPrepareMainFilter(eOperation, 's.idState', iID, bJoinTables, sMainFilter);

// filtry na strane serveru
    sSecondFilter := gsPrepareSecondFilter('s.flCurrency', iCurrency);

// prima cast
    SQL.Clear;
    SQL.Add('SELECT s.idState, s.dcName, s.dcCode, s.dcCodeISO, s.flCurrency, ');
    SQL.Add(' dcCodeIso3, dlNumeric, dcNameLocFull, ');
    SQL.Add(' dcNameLocCut, dcNameIntFull, dcNameIntCut ');

// bJoinTables je nastaven dle typu operace pri generovani hlavniho where
// pripoj sloupce z join tabulek, nebo ruzne pocitane sloupce
    if bJoinTables then
      SQL.Add(',c.dcName as dcCurrencyName');

    SQL.Add('FROM tCRM_State s');
// potrebujeme to pro zobrazeni, OK, joini co muzes
    if bJoinTables then
      SQL.Add('LEFT JOIN tCRM_Currency c ON s.flCurrency = c.idCurrency');

// inteligentne postpojuj pripadne fitry
    SQL.Add(WhereJoin(True, [sMainFilter, sSecondFilter]));

    if bJoinTables then
      SQL.Add(gsOrderBy('s.dcName'));
   end;
end;


Kdekoliv potrebuji v programu pracovat s patricnou tabulkou tak zavolam
SQLManager.OpenQState(ds, eoDelete, 100);
ds.Open;
ds.Delete;
ds.Close;
nebo

SQLManager.OpenQState(ds, eoSelect, 0, iCZK);
ds.Open;
a  zobraz

nebo proste co potrebuji.

Je to muj zpusob jak drzet sql na jednom miste a trsku modularne. Variantou je entity framework atd.

Název: Re:Parametrizované príkazy
Přispěvatel: Radek Červinka 20-12-2017, 14:36:57
Pokud potrebuji soupat moc dat, tak pouzivam StoredProc.
Název: Re:Parametrizované príkazy
Přispěvatel: Miroslav Baláž 20-12-2017, 14:48:01
S parametrami vs bez parametrov - porovnanie rýchlosti:
FireBird EMBEDDED (najnovsia verzia)
V 5 000 cykloch sa pomocou SELECT vyhľadáva 7 slov v rámci tabuľky o 221 riadkoch
(original bol 50 000 cyklov - viac podrobnosti k testom v citacii na zaver)
FireBird s pouzitim parametrov:  854 ms
FireBird bez parametrov    : 7 448 ms
Rozdiel v čase takmer 10 - nasobok.
Kód: Delphi [Vybrat]
  1. // Vyhľadávanie s parametrom - znížený počet cyklov na 5000, pôvodne 50000
  2.   dm.qry.Params.Clear;
  3.   dm.qry.SQL.Text := 'select eCategSet, eFnFlagSet from sumar where wordItem = ?';
  4.   dm.qry.Params[ 0 ].DataType := ftString;
  5.   dm.qry.Params[ 0 ].IsCaseSensitive := true;
  6.   dm.qry.Prepare;
  7.   dm.qry.Active := true;
  8.   k      := 0;
  9.   with dm.qry do
  10.     for i := 1 to 5000 do
  11.       begin
  12.       Params[ 0 ].AsString := 'oxymoron';
  13.       Refresh;
  14.       if not eof then
  15.         Inc( k );
  16.       Params[ 0 ].AsString := 'query';
  17.       Refresh;
  18.       if not eof then
  19.         Inc( k );
  20. ..
Kód: Delphi [Vybrat]
  1. // Vyhľadávanie bez parametrov
  2.   stw.Start;
  3.   k      := 0;
  4.   with dm.qry do
  5.     for i := 1 to 5000 do
  6.       begin
  7.       SQL.Text := 'select eCategSet, eFnFlagSet from sumar where wordItem = ''oxymoron''';
  8.       Active := true;
  9.       if not eof then
  10.         Inc( k );
  11.       SQL.Text := 'select eCategSet, eFnFlagSet from sumar where wordItem = ''query''';
  12.       Active := true;
  13.       if not eof then
  14.         Inc( k );
  15. ..
Presne takéto vyhľadávania boli skúmané aj pre Dictionary, StringList, HashedStringList, SQLite a SQLite in-Memory.
Na úplný záver je v príspevku prehľadná tabuľka výsledkov.
"Benchmark: Dictionary vs StringList vs HashedStringList vs SQLite in Memory" Link:
Název: Re:Parametrizované príkazy
Přispěvatel: Stanislav Hruška 20-12-2017, 16:12:09
Citace
A porad to nejak nevim. Ty chces sestavit model z Delphi trid a vygenerovat pro nej schema databaze a vsechny potrebne dotazy? Nebo obracene? Nebo jakou mas predstavu?
Výraz "schéma databázy" mi nič nehovorí, okrem toho, že existuje ;)
Jednoducho mám kopu MyQuery.SQL.Text := SameString (INSERT INTO, UPDATE, DELETE A SELECT). A bolo by dobré v tom urobiť poriadok.
Priam so železnou pravidelnosťou sa mi pre rôzne typy SQL opakuje, čo sa dá určite nejako optimalizovať (skryť):
Kód: [Vybrat]
  Fqry_I.ParamByName('FKFOCS').AsInteger := oGlobalVar.IDFOC;  // Vždy pracujem len s jedným domom
  Fqry_I.ParamByName('YEARS').AsInteger := oGlobalVar.CurrentYear;  // a jedným rokom
Posledný Radkov príspevok mi toho dosť objasňuje.

Poznámka: neviem čo si mám predstaviť pod výrazom "entity framework".

PS: dovolím si poznámku k Radkovej ukážke. Bolo by dobré zbaviť sa niekoľko násobného použitia SQL.Add, lebo každé priradenie vyvolá v pozadí overovanie textu. Viď "// prima cast". Jednoznačne tu odporúčali SQL.Text :=
Název: Re:Parametrizované príkazy
Přispěvatel: Miroslav Baláž 20-12-2017, 16:23:25
Citace
PS: dovolím si poznámku k Radkovej ukážke. Bolo by dobré zbaviť sa niekoľko násobného použitia SQL.Add, lebo každé priradenie vyvolá v pozadí overovanie textu. Viď "// prima cast". Jednoznačne tu odporúčali SQL.Text :=
No niekedy je pridavanie nutne. Nie som si isty, keby si pridaval cez string ci to bude ovela rychlejsie
Kód: Delphi [Vybrat]
  1. if s= '' then
  2.   s:= 'nejaky text'
  3. else
  4.   s= s + #13#10 + 'nejaky text'
  5. qry.SQL.Text:=..
myslim, ze keby si pridal takto, malo by to na rychlost snad stacit.
Kód: Delphi [Vybrat]
  1. qry.SQL.BeginUpdate;
  2. qry.SQL.Add
  3. ..
  4. qry.SQL.EndUpdate;
  5.  
teda ak uz priamo to Add malo len zdrzovat
Název: Re:Parametrizované príkazy
Přispěvatel: Stanislav Hruška 20-12-2017, 16:25:46
Už som si ten "entity framework" vyhľadal. Nič pre mňa.
Název: Re:Parametrizované príkazy
Přispěvatel: Miroslav Baláž 20-12-2017, 16:31:15
Tak v prvom rade ak by sa dalo
Kód: HTML [Vybrat]
  1. .ParamByName( .. ).AsInteger
nahradit pomocou:
Kód: HTML [Vybrat]
  1. .Params[ .. ].AsInteger
Citace
Kód: [Vybrat]
  Fqry_I.ParamByName('FKFOCS').AsInteger := oGlobalVar.IDFOC;  // Vždy pracujem len s jedným domom
  Fqry_I.ParamByName('YEARS').AsInteger := oGlobalVar.CurrentYear;  // a jedným rokom
Posledný Radkov príspevok mi toho dosť objasňuje.

Veril by som, ze ked sa ti to opakuje, tak by sa dal vyspekulovat nejaky rozumny cyklus, ktory by ti ubral rutinnu pracu..
Název: Re:Parametrizované príkazy
Přispěvatel: pf1957 20-12-2017, 16:37:53
myslim, ze keby si pridal takto, malo by to na rychlost snad stacit.
Kód: Delphi [Vybrat]
  1. qry.SQL.BeginUpdate;
  2. qry.SQL.Add
  3. ..
  4. qry.SQL.EndUpdate;
  5.  
Takto by to slo, ale .Add opakovane pro nekolik radku bez uzamceni stringlistu je vylozene skodlive, protoze to po pridani kazdeho radku vola SQL parser, ktery samozreme na neuplnem SQL prikazu havaruje...

Je otazka, proc delat Begin/EndUpdate, kdyz muzu rovnou napsat Text := a ten text si pred tim slozit v nejakem StringBuilderu
Název: Re:Parametrizované príkazy
Přispěvatel: pf1957 20-12-2017, 16:41:16
Tak v prvom rade ak by sa dalo
Kód: HTML [Vybrat]
  1. .ParamByName( .. ).AsInteger
nahradit pomocou:
Kód: HTML [Vybrat]
  1. .Params[ .. ].AsInteger
Tak to bych silne nedoporucoval, urcite ne jako premature optimization, protoze si tim zhorsi udrzovatelnost kodu, protoze pri kazdem pridani cehokoli bude miset neustale zkoumat poradi parametru. K tomu bych se uchylil jedine, kdyz je to funkci, odladene a je treba to optimalizovat, jinak je to nebezpecna technika.
Název: Re:Parametrizované príkazy
Přispěvatel: pf1957 20-12-2017, 16:45:20
Priam so železnou pravidelnosťou sa mi pre rôzne typy SQL opakuje, čo sa dá určite nejako optimalizovať (skryť):
Kód: [Vybrat]
  Fqry_I.ParamByName('FKFOCS').AsInteger := oGlobalVar.IDFOC;  // Vždy pracujem len s jedným domom
  Fqry_I.ParamByName('YEARS').AsInteger := oGlobalVar.CurrentYear;  // a jedným rokom
Posledný Radkov príspevok mi toho dosť objasňuje.
[/code]
Je celkem normalni, ze kdyz clovek pracuje s DataSety, tak si postupne nadela celou sadu pomocnych funkci kterou vice ci mene postupne zobecnuje, takze prece neni zadny problem tohle vzit, dat do samotne subroutiny a tu nekde vhodne volat.

Název: Re:Parametrizované príkazy
Přispěvatel: pf1957 20-12-2017, 16:46:32
Už som si ten "entity framework" vyhľadal. Nič pre mňa.
Ani nič pre Delphistu ;-)
Název: Re:Parametrizované príkazy
Přispěvatel: Miroslav Baláž 20-12-2017, 16:52:32
Tak v prvom rade ak by sa dalo
Kód: HTML [Vybrat]
  1. .ParamByName( .. ).AsInteger
nahradit pomocou:
Kód: HTML [Vybrat]
  1. .Params[ .. ].AsInteger
Tak to bych silne nedoporucoval, urcite ne jako premature optimization, protoze si tim zhorsi udrzovatelnost kodu, protoze pri kazdem pridani cehokoli bude miset neustale zkoumat poradi parametru. K tomu bych se uchylil jedine, kdyz je to funkci, odladene a je treba to optimalizovat, jinak je to nebezpecna technika.
A co takto miesto ciselneho indexu pouzit enum, kde si mozes nadefinovat polozku lubovolneho znenia. A mozes to pouzivat v cykloch? (Na rozdiel od stringu..) Samozrejme tiez v mnozinovych operaciach.
Pripadny prevod enum, resp. set na Byte, Integer, Int64 je okamzity (tam aj spat).
Proste pohodlie a prehlad a ucinnost dohromady? Teda ak uz mam nieco oprimalizovat a automatizovat vo velkom?
Název: Re:Parametrizované príkazy
Přispěvatel: pf1957 20-12-2017, 16:59:16
A co takto miesto ciselneho indexu pouzit enum, kde si mozes nadefinovat polozku lubovolneho znenia. A mozes to pouzivat v cykloch? Samozrejme tiez v mnozinovych operaciach.
Pripadny prevod enum, resp. set na Byte, Integer, Int64 je okamzity (tam aj spat).
Proste pohodlie a prehlad a ucinnost dohromady? Teda ak uz mam nieco oprimalizovat a automatizovat vo velkom?
Co je na tom za pohodli pri zmene poradi parametru v SQL at uz pridanim nebo ubranim parametru  rucne prepisovat nekde enumy?

Ty ses tem optimalizacema nejakej posedlej... vetsinou nez to stacis vsechno zmerit, napsat otestovat (a v neposledni rade nastudovat), tak vyrobce zrychli HW 2x ;)

Název: Re:Parametrizované príkazy
Přispěvatel: Miroslav Baláž 20-12-2017, 17:39:06
OK,
Název: Re:Parametrizované príkazy
Přispěvatel: Miroslav Baláž 20-12-2017, 17:59:08
Takto by to slo, ale .Add opakovane pro nekolik radku bez uzamceni stringlistu je vylozene skodlive, protoze to po pridani kazdeho radku vola SQL parser, ktery samozreme na neuplnem SQL prikazu havaruje...
Da sa chapat, ze aj ked plati:
Kód: Delphi [Vybrat]
  1. Query.Active=False
neuplny SQL kod sa cez to vsetko kontroluje na vykonatelnost? To som nevedel.
Název: Re:Parametrizované príkazy
Přispěvatel: pf1957 20-12-2017, 18:31:12
Da sa chapat, ze aj ked plati:
Kód: Delphi [Vybrat]
  1. Query.Active=False
neuplny SQL kod sa cez to vsetko kontroluje na vykonatelnost? To som nevedel.
Nemusi to mit obecnou platnost tj. je to treba zkoumat pro konkretni komponenty, ale vetsinou jako SQL pouzivali TWideStringList a tomu nastaivil OnChange event. A ten string list nemel zadne povedomi, o nejakem Query.Active, proste kdyz se mu zmenil obsah, tak event odpalil...

Je treba se podivat na obsluhu te udalosti v QueryChanged u konkretni komponenty, ale vetsinou vede naopak ke shozeni Active na FALSE a pak dela neco takoveho:
Kód: Delphi [Vybrat]
  1. procedure TSQLQuery.QueryChanged(Sender: TObject);
  2. begin
  3.   if not (csReading in ComponentState) then
  4.   begin
  5.     Close;
  6.     SetPrepared(False);
  7.     if ParamCheck or (csDesigning in ComponentState) then
  8.     begin
  9.       FCommandText := SQL.Text;
  10.       FText := FCommandText;
  11.       SetParamsFromSQL(nil, False);
  12.     end
  13.     else
  14.       FText := SQL.Text;
  15. {$IF DEFINED(CLR)}
  16.     DataEvent(dePropertyChange, nil);
  17. {$ELSE}
  18.     DataEvent(dePropertyChange, 0);
  19. {$IFEND}
  20.   end
  21.   else
  22.     FText := FParams.ParseSQL(SQL.Text, False);
  23.   SetFCommandText(FText);
  24. end;
  25.  
Název: Re:Parametrizované príkazy
Přispěvatel: pf1957 20-12-2017, 18:45:11
Da sa chapat, ze aj ked plati:
Kód: Delphi [Vybrat]
  1. Query.Active=False
neuplny SQL kod sa cez to vsetko kontroluje na vykonatelnost? To som nevedel.
Tak jemu ani tak nejde o vykonavatelnost, ale o urceni prikazu, co ma pri open/exec delat a napr. take o vytahani seznamu parametru, abys nasledne mohl psat to tvoje Q.Params[ i ].xxx
Název: Re:Parametrizované príkazy
Přispěvatel: Miroslav Baláž 20-12-2017, 19:24:48
Da sa chapat, ze aj ked plati:
Kód: Delphi [Vybrat]
  1. Query.Active=False
neuplny SQL kod sa cez to vsetko kontroluje na vykonatelnost? To som nevedel.
Tak jemu ani tak nejde o vykonavatelnost, ale o urceni prikazu, co ma pri open/exec delat a napr. take o vytahani seznamu parametru, abys nasledne mohl psat to tvoje Q.Params[ i ].xxx
Práve nad tým špekulujem. Hľadal som vo FireDAC zdrojoch a tam sa .QueryChanged nevyskytuje. Iba Oracle má 'DoQueryChanged('.
Možno to trčí už niekde na úrovni DB.pas, či podobne.
Parametre?
Doteraz som veril, že sa zaktivujú až v druhom riadku tohoto príkazu:
Kód: MySQL [Vybrat]
  1.   dm.qry.SQL.Text := 'select eCategSet, eFnFlagSet from sumar where wordItem = ?';
  2.   dm.qry.Params[ 0 ].DataType := ftString;
Kontorloval som. Pravda je, že pred druhým riadkom tie parametre už pozná.

Zase k vyššie zmieneným veciam:
Query.SQL.Text := 'SELECT ..'
volá
procedure TStrings.SetTextStr(const Value: string);  // v System.Classes
a ten začína BeginUpdate;
takže sme u toho môjho
BeginUpdate; Add(

Název: Re:Parametrizované príkazy
Přispěvatel: pf1957 20-12-2017, 19:30:08
procedure TStrings.SetTextStr(const Value: string);  // v System.Classes
Pozor na to, ze TStrings  je abstraktni trida a SQL property byva nejaka konkretni napr. jak jsem psal TWideStringList u nekterych komponent a ta vubec nemusi volat inherited metodu.
Pokud to chces lustit, musis vychazet z neceho takoveho v constructoru Query:
Kód: Delphi [Vybrat]
  1.   ...
  2.   TWideStringList(SQL).OnChange := QueryChanged;
  3.   ...
  4.  
Název: Re:Parametrizované príkazy
Přispěvatel: pf1957 20-12-2017, 19:48:27
Kód: MySQL [Vybrat]
  1.   dm.qry.SQL.Text := 'select eCategSet, eFnFlagSet from sumar where wordItem = ?';
  2.  dm.qry.Params[ 0 ].DataType := ftString;
Kontorloval som. Pravda je, že pred druhým riadkom tie parametre už pozná.
Kdyby to tak nebylo, to by Params[ 0 ] skoncilo na OutOfRange exception nebo jak se to v Delphi jmenuje
Název: Re:Parametrizované príkazy
Přispěvatel: Miroslav Baláž 20-12-2017, 20:01:53
Jasne. To chapem. Myslel som, ze az prve volanie parametrov to bude aktualizovat. Ale mas pravdu. Je to ako pises.

Ale narazil som na iny problem.
Pre Query neviem zmenit pocet parametrov. Na zaciatku staci SELECT
Kód: Delphi [Vybrat]
  1.   dm.qry.SQL.Text := 'select eCategSet, eFnFlagSet from sumar where wordItem = ?';
Nastavim parametre, presnejsie jeden, spustim. Vsetko OK.
Ked to ukoncim a chcem zmenit SELECT, kde by bol iny pocet parametrov, tak sa najprv pokusim o toto:
dm.qry.SQL.Text :='';    alebo     dm.qry.SQL.Clear;
Ale to mi stavajuce parametre nezrusi.
Furt zostava :    dm.qry.Params.Count = 1
Ked pouzijem dm.qry.Params.Clear;  tak potom plati ocakavane dm.qry.Params.Count = 0
Ale uz mi ziadny SELECT, znovu nove parametre nevyrobi.
Nech robim co robim zostava: dm.qry.Params.Count = 0
Nasledny pokus o zapis do params[0] preto zhavaruje
PS:Pouzivam FireDAC.
Název: Re:Parametrizované príkazy
Přispěvatel: Stanislav Hruška 20-12-2017, 20:50:28
Kód: [Vybrat]
dm.qry.Close;
dm.qry.SQL.Text := 'SELECT ...';
dm.qry.Open;
Název: Re:Parametrizované príkazy
Přispěvatel: Radek Červinka 20-12-2017, 21:06:55
myslim, ze keby si pridal takto, malo by to na rychlost snad stacit.
Kód: Delphi [Vybrat]
  1. qry.SQL.BeginUpdate;
  2. qry.SQL.Add
  3. ..
  4. qry.SQL.EndUpdate;
  5.  
Takto by to slo, ale .Add opakovane pro nekolik radku bez uzamceni stringlistu je vylozene skodlive, protoze to po pridani kazdeho radku vola SQL parser, ktery samozreme na neuplnem SQL prikazu havaruje...

Je otazka, proc delat Begin/EndUpdate, kdyz muzu rovnou napsat Text := a ten text si pred tim slozit v nejakem StringBuilderu

Mas pravdu, samozrejme by to tak melo byt. Mimochodem ty OnChange udalosti jsou

procedure TFDCustomCommand.DoSQLChanging(ASender: TObject);
procedure TFDCustomCommand.DoSQLChange(ASender: TObject);

No ale jelikoz nasleduje dotaz do DB, ktery je 100x - 1000x narocnejsi, tak mne to az tak moc netrapi.
Volani pres Add je protoze tam mam casto ruzne podminky a je to pro mne citelnejsi po nejake dobe, coz ovsem ten stringbuilder resi. Presto si myslím, že kdybych to chtel upravovat tak bych sel pres BeginUpdate


Název: Re:Parametrizované príkazy
Přispěvatel: Radek Červinka 20-12-2017, 21:10:00
Už som si ten "entity framework" vyhľadal. Nič pre mňa.
Ani nič pre Delphistu ;-)

Tohle je celkem slušné https://www.devart.com/entitydac/ (https://www.devart.com/entitydac/).
Název: Re:Parametrizované príkazy
Přispěvatel: Delfin 20-12-2017, 22:10:17
[/list]Priam so železnou pravidelnosťou sa mi pre rôzne typy SQL opakuje, čo sa dá určite nejako optimalizovať (skryť):
Kód: [Vybrat]
  Fqry_I.ParamByName('FKFOCS').AsInteger := oGlobalVar.IDFOC;  // Vždy pracujem len s jedným domom
  Fqry_I.ParamByName('YEARS').AsInteger := oGlobalVar.CurrentYear;  // a jedným rokom
Posledný Radkov príspevok mi toho dosť objasňuje.

Zkus se na to schema podivat pohledem dedicnosti objektu. Spolecny predek trid prece muze delat stejnou vec, stejne jako muze obsahovat spolecna pole ;)
Název: Re:Parametrizované príkazy
Přispěvatel: Miroslav Baláž 20-12-2017, 22:12:13
Kód: [Vybrat]
dm.qry.Close;
dm.qry.SQL.Text := 'SELECT ...';
dm.qry.Open;
Z potreby qry.Open ovsem vyplyva, ze parametre nie su riesene v stadiu zadania kodu do qry.SQL.Text, ako bol naznacene vyssie?
Ešte dopľňam: Sa mi len zdá, že pri prvom použití Query, v runtime, keď je prázdne, tak sa parametre predsa len upgradujú hneď po zadaní SQL.Text := xy ?
Veru nezdá. Toto funguje, aj za predpokladu, že je na začiatku Query prázdne.
Kód: Delphi [Vybrat]
  1.   dm.qrySQLite.Params.Clear;
  2.   dm.qrySQLite.SQL.Clear;
  3. k := dm.qrySQLite.Params.Count;  // k = 0
  4.   dm.qrySQLite.SQL.Text := 'select eCategSet, eFnFlagSet from sumar where wordItem = ?';
  5. k := dm.qrySQLite.Params.Count;  // k = 1 !!!
  6.   dm.qrySQLite.Params[ 0 ].DataType := ftString;
Název: Re:Parametrizované príkazy
Přispěvatel: Delfin 20-12-2017, 22:30:36
Kód: [Vybrat]
dm.qry.Close;
dm.qry.SQL.Text := 'SELECT ...';
dm.qry.Open;
Z potreby qry.Open ovsem vyplyva, ze parametre nie su riesene v stadiu zadania kodu do qry.SQL.Text, ako bol naznacene vyssie?
Ešte dopľňam: Sa mi len zdá, že pri prvom použití Query, v runtime, keď je prázdne, tak sa parametre predsa len upgradujú hneď po zadaní SQL.Text := xy ?
Veru nezdá. Toto funguje, aj za predpokladu, že je na začiatku Query prázdne.
Kód: Delphi [Vybrat]
  1.   dm.qrySQLite.Params.Clear;
  2.   dm.qrySQLite.SQL.Clear;
  3. k := dm.qrySQLite.Params.Count;  // k = 0
  4.   dm.qrySQLite.SQL.Text := 'select eCategSet, eFnFlagSet from sumar where wordItem = ?';
  5. k := dm.qrySQLite.Params.Count;  // k = 1 !!!
  6.   dm.qrySQLite.Params[ 0 ].DataType := ftString;

Ano, protoze by default, s prirazenim (nebo jakoukoli zmenou) textu prikazu se prikaz parsuje a to proto, aby se pro nej daly ze zastupnych symbolu vytvorit placeholdery pro kolekci parametru a maker. S vychozim nastavenim jde o:

Kód: Delphi [Vybrat]
  1. Query.SQL.Text := 'SELECT !MyMacro FROM MyTable WHERE MyColumn = :MyParam'; // "by default" pripravi kolekci parametru a maker
  2. Query.MacroByName('MyMacro').AsIdentifier := 'MyColumn'; // existuje diky nastaveni ResourceOptions.MacroCreate a parsovani prikazu
  3. Query.ParamByName('MyParam').AsInteger := 666; // existuje diky ResourceOptions.ParamCreate a parsovani prikazu
  4. Query.Open;
Název: Re:Parametrizované príkazy
Přispěvatel: Miroslav Baláž 20-12-2017, 23:21:29
Dobre. Takto to funguje pri prvom spusteni Query.
Lenze ked to chcem vsetko s tym istym query spustiti druhy raz (napr select s inym poctom parametrov), tak uz neplatia tie iste pravidla ako pri povodnom cistom Query.
Uz nestaci priradenie textu. Vyssie som uviedol priklad. Je to dokumentovane na Params.Count.
Ziadne SQL.Text:= nepomoze, tak ako pomohlo na zaciatku
A zase naopak, ked dam nestastny Params.Clear, co jedine ozaj pomoze, tak neviem co dalej. A ak Clear nedam, tak sa starych paremetrov viac nezbavim. Ako ale potom znovu ozivit parametre?

Ked vuzijem Params.Clear, tak potom musim spravit qry.Open? ako niekde vyssie odporuca Stano?
Ale to uz je neskoro, aby sa obcerstvovali parametre. Nie?..
Keby to fungovalo ocakavane, tak aj v opätovnom pripade využitia query postupujem rovnako ako na začiatku. Lenže to u mňa s istotou nefunguje. Vie niekto ponúknuť funkčnú vzorku druhého naplnenia SELECT do toho istého query, tak aby sa poctivo zmenili parametre podla noveho prikazu?
Název: Re:Parametrizované príkazy
Přispěvatel: Delfin 20-12-2017, 23:34:43
Dobre. Takto to funguje pri prvom spusteni Query.

Ne, tak to funguje porad. To nema se spustenim co delat. Zmenis text SQL prikazu, preprocesor ho rozparsuje (bez kooperace s DBMS) a v pripade povoleneho nastaveni (ResourceOptions.ParamCreate a ResourceOptions.MacroCreate) se vytvori placeholdery kolekce parametru a maker.

Lenze ked to chcem vsetko s tym istym query spustiti druhy raz (napr select s inym poctom parametrov).

Ta veta je mutualne exkluzivni. Pokud mas stejny SQL prikaz, nemuze mit "jiny pocet parametru". To uz je pak jiny SQL prikaz.



Jinak pokud je dotaz smerovan k tomu, proc je kolekce parametru zachovana i po uzavreni kurzoru (napr. metodou Close), je to jednoduse proto, ze muzes kurzor znovu otevrit beze zmeny SQL prikazu. Prikaz se tak nemusi znova zpracovavat preprocesorem pro sestaveni stejnych kolekci.
Název: Re:Parametrizované príkazy
Přispěvatel: Delfin 21-12-2017, 00:35:44
Jinak pokud je dotaz smerovan k tomu, proc je kolekce parametru zachovana i po uzavreni kurzoru (napr. metodou Close), je to jednoduse proto, ze muzes kurzor znovu otevrit beze zmeny SQL prikazu. Prikaz se tak nemusi znova zpracovavat preprocesorem pro sestaveni stejnych kolekci.

Napr.:

Kód: Delphi [Vybrat]
  1. Query.SQL.Text := 'SELECT !MyMacro FROM MyTable WHERE MyColumn = :MyParam'; // "by default" pripravi kolekci parametru a maker
  2. Query.MacroByName('MyMacro').AsIdentifier := 'MyColumn'; // existuje diky nastaveni ResourceOptions.MacroCreate a parsovani prikazu
  3. Query.ParamByName('MyParam').AsInteger := 666; // existuje diky ResourceOptions.ParamCreate a parsovani prikazu
  4. Query.Open; // otevre se kurzor
  5.  
  6. Query.Close; // kurzor se zavre avsak kolekce Macros a Params zustavaji beze zmen protoze nedoslo ke zmene SQL prikazu
  7. Query.Open; // otevre se kurzor a prikaz se spusti se stejnymi definicemi parametru a maker jako pri prvnim otevreni kurzoru

Jinak pro ty co veri ze ma v pripade pripravy kolekce parametru prsty DBMS (s vychozim nastavenim FireDAC), necht spusti:

Kód: Delphi [Vybrat]
  1. Query.SQL.Text := '?????';
  2. ShowMessage(Format('Parameter placeholder count: %d', [Query.ParamCount]));

K cemuz dodam, ze se tady nejedna o chybu, ale pridanou vlastnost. Preprocesor FireDAC neresi syntaxi SQL jako takoveho (ta je jen na DBMS). Jen si z textu prikazu vyparsuje znacky a nazvy parametru, maker, nahradi zastupky a pripravi pro vse kolekce - ale to je jen dalsi podana ruka. Vyvojar totiz musi znat nazvy a datove typy jednotlivych parametru, coz mu nijak nebrani v tom si takove kolekce vyrobit manualne (po vypnuti prislusnych nastaveni). Takze preventivne uvedu, ze v pripade vyse zmineneho prikladu 5 otazniku nereste ze FireDAC vytvori 5 placeholderu pro parametry namisto vyhozeni vyjimky o nesmyslnem SQL prikazu - na to prijde DBMS s pripravou prikazu ke spusteni a je na vyvojari zajistit korektni plneni parametru prikazu ktery uvedl.
Název: Re:Parametrizované príkazy
Přispěvatel: Stanislav Hruška 21-12-2017, 08:44:08
Citace
Tohle je celkem slušné https://www.devart.com/entitydac/. (https://www.devart.com/entitydac/.)
Je to zaujímavé. Ale musel by som byť profesionál a hlavne na vývoji zarábať. Čo sa nedeje. 250 € je už pre mňa veľký peniaz. Neviem odhadnúť, čo by mi to prinieslo vzhľadom na skutočnosť, že nepoužívam žiadne vizuálne DB komponenty. Všetko je TSM.
Citace
Zkus se na to schema podivat pohledem dedicnosti objektu. Spolecny predek trid prece muze delat stejnou vec, stejne jako muze obsahovat spolecna pole
K tomu som sa ešte nedostal. Veď ma čaká:

Název: Re:Parametrizované príkazy
Přispěvatel: egroups 21-12-2017, 09:04:26
Mrkni na Spring4D a Marshmallow.To je taky ORM framework a je zdarma.
Název: Re:Parametrizované príkazy
Přispěvatel: Stanislav Hruška 21-12-2017, 09:16:33
Radšej najprv dokončím jadro aplikácie >:(  a potom môžem špekulovať 8) . Za informáciu ďakujem.
Název: Re:Parametrizované príkazy
Přispěvatel: pf1957 21-12-2017, 09:27:24
Neviem odhadnúť, čo by mi to prinieslo vzhľadom na skutočnosť, že nepoužívam žiadne vizuálne DB komponenty. Všetko je TSM.
Je nesmysl predelavat  rozdelany/nedokonceny projekt na ORM, jedine ze bycs to chtel vsechnu zahodit a zacit znovu :-) Je to uplne jine paradigma, myslet se musi v kategorii objektu a ne nejakych DB tabulek.

A hlavne: nejdriv je treba zjistit a radne otestovat, jak to maji s evoluci schematu, protoze vytvorit prazdnou DB z nejakych metadat je sranda, ale evoluovat metadata a DB scheme u DB naplnene daty, aby to zustalo konzistentni, to je IMHO pro prakticke nasazeni zasadni. Pokud to technologie nema, nema smysl IMHO o ORM vubec uvazovat.

Citace
Veď ma čaká:

Viz vyse, snad jenom poznamka k tem exception: v jazykach, ktere nemaji kontrolu na exceptions (jako ma treba Java), uz je jejich dodatecne montovani a osetrovani problematicke a nikdy nevede k dobrym vysledkum ani u vlastniho kodu, kdyz se do toho saha s odstupem, protoze system osetrovani ti vytvari jiny strom zavislosti, nez ten, ktery odpovida hierarchii volani subroutin, takze casto pak dochazi k situacim, ze sice nejak exception osetris, ale z logu pak nejsi schopen urcit, co, kde a proc se presne stalo. Samozrejme cim slozitejsi aplikace, tim hur. V tom jsou ty interaktivni UI zblitky jeste dobre
Název: Re:Parametrizované príkazy
Přispěvatel: Delfin 21-12-2017, 14:56:19
Neviem odhadnúť, čo by mi to prinieslo vzhľadom na skutočnosť, že nepoužívam žiadne vizuálne DB komponenty. Všetko je TSM.
Je nesmysl predelavat  rozdelany/nedokonceny projekt na ORM, jedine ze bycs to chtel vsechnu zahodit a zacit znovu :-) Je to uplne jine paradigma, myslet se musi v kategorii objektu a ne nejakych DB tabulek.

A nejen to. I pro predelani toho projektu. Co by prinesl "entity framework" do jeho aplikace krome skryti databazove vrstvy? Zase by skoncil se sadou objektu pro ktere bude vytvaret pohledy. Potrebuje ale ty objekty? Potrebuje ze schematu vytvorit sadu trid kterou bude v aplikaci pomoci kodu zase sjednocovat do unifikovanych zobrazovacu? Podle me ne.

Jinak ohledne "automatizace" generovani skriptu nebo plneni parametru, kdyz uz mas jednou ty tridy deklarovane, tak staci rozsirene RTTI abys popsal jakykoli objekt a je snadne iterovat jeho polemi, zkontrolovat pripadne atributy a sbirat si bud jejich datove typy nebo hodnoty (instanci) pro vytvoreni skriptu nebo naplneni kolekce parametru. To vse se da vycist uz ted napr. z JSON serializace (kdo nevi jak) kterou ma Delphi v sobe, jen misto skladani JSON budes psat bud CREATE skripty tabulek nebo plnit parametry dataset objektu (migrace na urovni nebude zrovna jednoducha). No a ty objekty samozrejme s dedicnosti, tzn. ze superobjekt bude mit vse co maji entity spolecne.

Jen bych se spis do budoucna zamyslel, jestli vubec potrebuje ty objekty - to totiz zase zavani psanim spousty kodu. Popis entit v podobe datasetu IMHO pro jeho typ aplikace staci.
Název: Re:Parametrizované príkazy
Přispěvatel: pf1957 21-12-2017, 15:24:53
Potrebuje ale ty objekty? Potrebuje ze schematu vytvorit sadu trid kterou bude v aplikaci pomoci kodu zase sjednocovat do unifikovanych zobrazovacu? Podle me ne.
Nevim, co potrebuje on, ale ja bych objekty na urovni ViewModelu potreboval resp. si ne,dovedu predstsavit, ze bych je nemel, abych mohl hodnoty anotovat a tim mj. zajistit I18N, definovat validatory pro prevzeti hodnot z ksichtu, definovat formaty zobrazeni atd. tj. deklarativne ridit ksicht z jendoho mista co nejvic to jde. A ten view uz je pak jenom nejaky intepretr tech anotaci + trocha layout, stylovani etc...

Alre samozrejme ho k tomu nenabadam, kdyz k tomu sam nedospel.
Název: Re:Parametrizované príkazy
Přispěvatel: Delfin 21-12-2017, 15:55:23
Potrebuje ale ty objekty? Potrebuje ze schematu vytvorit sadu trid kterou bude v aplikaci pomoci kodu zase sjednocovat do unifikovanych zobrazovacu? Podle me ne.
Nevim, co potrebuje on, ale ja bych objekty na urovni ViewModelu potreboval resp. si ne,dovedu predstsavit, ze bych je nemel, abych mohl hodnoty anotovat a tim mj. zajistit I18N, definovat validatory pro prevzeti hodnot z ksichtu, definovat formaty zobrazeni atd. tj. deklarativne ridit ksicht z jendoho mista co nejvic to jde. A ten view uz je pak jenom nejaky intepretr tech anotaci + trocha layout, stylovani etc...

Co popisujes uz maji vicemene napr. TField potomci. Kdyz ta nastaveni vystrcis ven do editoru, nemusis psat ani carku aplikacniho kodu a (znaly, opravneny) uzivatel si muze vse "naklikat" v runtime. Porad totiz chapu spravu domu jako editor tabulek s agregacnimi vypocty (a sadu reportu). Jiste, tvorba takoveho "framework" mozna zabere cas, ale je treba brat v potaz kolik casu se da nasledne usetrit - nehlede na pouzitelnost v dalsich podobnych aplikacich (a kdyz na to prijde, fakturovat zakaznikovi pak muzes ne za psani opakovaneho kodu a build aplikace, ale jen "klikani" ve vlastnim editoru pohledu).
Název: Re:Parametrizované príkazy
Přispěvatel: pf1957 21-12-2017, 16:24:17
Co popisujes uz maji vicemene napr. TField potomci.
No v omezenem rozsahu ano, ale me to prijde jako cesta zpatky do minuleho stoleti. Pouziti anotovanych ViewModelu a introspekce pri praci s daty je daleko obecnejsi.

Kdyz to vezmu za sebe, tak uz na prelomu stoleti jsme zacali pouzivali VTV s in-place editovanim v gridech/stromech nad jednoduchym vlastnim ORM a za poslednich rekneme ~16 let jsem s DB zastaralym spusobem pres SQL delal asi tak 3 roky, jinak ORM z Djanga, Hibernate, EF... Zkratka, ja kdyz to neni opravdu, ale opravdu nezbytne nutne, tak ten sr*ckoidni SQL obejdu obloukem :-)
Název: Re:Parametrizované príkazy
Přispěvatel: Miroslav Baláž 21-12-2017, 16:51:22
No. SQL by som celkom nezatracoval. ORM moze pomahat. Ale nie vsade.
S nakladakom, sa nezmestim vzdy nutne tam, kde prejde skuter..
A nie vsetky skutre su sr*ck-y
Název: Re:Parametrizované príkazy
Přispěvatel: pf1957 21-12-2017, 17:01:17
No. SQL by som celkom nezatracoval.
Ja ho taky celkem nezatracuju, jen u me ma mezi "neprateli lidu" pomerne cestne misto hned za komunisty, neomarxisty, pravdolaskari a VB/PHP strikaci ;-)
Název: Re:Parametrizované príkazy
Přispěvatel: Miroslav Baláž 21-12-2017, 17:19:05
Ja tiez nejazdim na motorkach :)
Název: Re:Parametrizované príkazy
Přispěvatel: Delfin 21-12-2017, 18:56:27
Co popisujes uz maji vicemene napr. TField potomci.
No v omezenem rozsahu ano, ale me to prijde jako cesta zpatky do minuleho stoleti. Pouziti anotovanych ViewModelu a introspekce pri praci s daty je daleko obecnejsi.

To ano. Ani jsem tim nechtel radit k pouziti tech hnusnych DB aware komponent, tezkopadne smykat kurzorem objektem datasetu pro ziskani jednotlivych zaznamu, nebo dokonce pouzivat Dead Binding. Myslel jsem na vlastni framework ktery vsak nebude pracovat s tridami entit, ale abstraktnejsim data storage (ala dataset).
Název: Re:Parametrizované príkazy
Přispěvatel: pf1957 22-12-2017, 14:19:35
Myslel jsem na vlastni framework ktery vsak nebude pracovat s tridami entit, ale abstraktnejsim data storage (ala dataset).
Mozna, ze i s tou myslenkou by se dalo udelat neco pokrokoveho  ;)
Design-Time editor datasetu vytahava odkazy na pole z datasetu do formu nebo DM, aby se obesla nutnost je vyhledavat v run-time at uz pomoci FieldByName nebo Fields[ i ] (ty hnusny zavorky kolem [ a ] tam davam protoze tomu softu neumim rict, aby to neintepretoval jako tagy):
Kód: Delphi [Vybrat]
  1. TDataModuleXyz = class(TDataModule)
  2.     cdsXyz: TClientDataSet;
  3.     cdsXyzId: TIntegerField;
  4.     cdsXyzIdent: TStringField;
  5.     ...
  6. end;
  7.  

Takze mozna by se z toho dal udelat anotovany ViewModel (nemam to rozmysleno, jen napad):
Kód: Delphi [Vybrat]
  1. [ ViewModel ... ]
  2. TDataModuleXyz = class(TDataModule)
  3.     cdsXyz: TClientDataSet;
  4.  
  5.     cdsXyzId: TIntegerField;
  6.  
  7.     [ Display(Name = "View_Orders_XyzIdentLabel", Prompt = "View_Orders_XyzIdentPrompt", Hint="View_Orders_XyzIdentPromptHint" ResourceType = typeof(WebGui)) ]
  8.     [ RegularExpression('^[ A-Z ]\d+$',
  9.       ErrorMessageResourceType = typeof(WebMsg), ErrorMessageResourceName = "ModelErr_Xxx_InvalidXyzIdent") ]
  10.     cdsXyzIdent: TStringField;
  11.     ...
  12.     [ Display(Name = "View_Orders_EventFromLabel", Prompt = "View_Orders_EventFromPrompt", Prompt = "View_Orders_EventFromHint", ResourceType = typeof(WebGui)) ]
  13.     [ Format(typeof(WebGui), nil, nil, ClientFormat = "d") ]
  14.     [ DateRange(DynamicMinimum = "minEventFromRange", DynamicMaximum = "maxEventFromRange") ]
  15.     cdsXyzEventFrom: TDateField;
  16.  
  17.     [ NotMapped ]
  18.     minEventFromRange: TDateTime;
  19.     [ NotMapped ]
  20.     maxEventFromRange: TDateTime;
  21.  
  22. end;
  23.  
To by sice trpelo neduhem, ze se neco musi naklikat a neco napsat v kodu, takze se samozrejme nabizi pridani dalsi anotace s vlastni definicí pole a vyrazeni debilniho klikani:
Kód: Delphi [Vybrat]
  1. [ ViewModel ... ]
  2. TDataModuleXyz = class(TDataModule)
  3.     cdsXyz: TClientDataSet;
  4.  
  5.     [ FieldDef(Name=Id, Type=tfInteger,  Nullable=False) ]
  6.     cdsXyzId: TIntegerField;
  7.  
  8.     [ FieldDef(Name=(Ident, Type=tfString, Size=64, Nullable=False) ]
  9.     [ Display(Name = "View_Orders_XyzIdentLabel", Prompt = "View_Orders_XyzIdentPrompt", Hint="View_Orders_XyzIdentPromptHint" ResourceType = typeof(WebGui)) ]
  10.     [ RegularExpression('^[ A-Z ]\d+$',
  11.       ErrorMessageResourceType = typeof(WebMsg), ErrorMessageResourceName = "ModelErr_Xxx_InvalidXyzIdent") ]
  12.     cdsXyzIdent: TStringField;
  13.     ...
  14.     [ FieldDef(Name=(EventFrom, Type=ftDate, Nullable=True) ]
  15.     [ Display(Name = "View_Orders_EventFromLabel", Prompt = "View_Orders_EventFromPrompt", Prompt = "View_Orders_EventFromHint", ResourceType = typeof(WebGui)) ]
  16.     [ Format(typeof(WebGui), nil, nil, ClientFormat = "d") ]
  17.     [ DateRange(DynamicMinimum = "minEventFromRange", DynamicMaximum = "maxEventFromRange") ]
  18.     cdsXyzEventFrom: TDateField;
  19.     ...
  20. end;
  21.  
No a kdyz uz jsme to dotahli sem, tak je otazka, jestli jeste stale na neco potrebujeme TFields nebo mame pokracovat v navrhu a nebo se na to vybodnout a pouzivat nejaky existujici ORM :-)

Název: Re:Parametrizované príkazy
Přispěvatel: Delfin 22-12-2017, 15:20:16
No a kdyz uz jsme to dotahli sem, tak je otazka, jestli jeste stale na neco potrebujeme TFields nebo mame pokracovat v navrhu a nebo se na to vybodnout a pouzivat nejaky existujici ORM :-)

K te ukazce; ja myslel jeste na jeste abstraktnejsi reseni :)

Co uvadis jsou definice poli entity v kodu, byt u nich uz odpadla nutnost tvorit pohled (coz by se specifickymi tridami entit obecne slo leda pomoci RTTI) - byly by soucasti dataset objektu ktery je zobrazitelny a daji se pro nej vytvorit agregacni vypocty ba dokonce reporty. Nicmene, i ten dataset se da popsat pomoci nejake konfiguracni sablony (napr. v souboru) vcetne formatu poli etc. a vytvorit v runtime. Stejne jako definice pohledu na nej (vcetne pravidel pro stylovani podle hodnot). Samozrejme pro specialni pripady by byla stale moznost si takovou entitu vytvorit a pracovat s ni v kodu. Pro jednoduche editory tabulek bys ale nemusel napsat ani carku kodu, natoz aplikaci znovu buildovat - namisto toho bys jen nejakym runtime editorem naklikal co chces zobrazit a jak.

ORM pro Delphi jsem nezkoumal a nevim jestli je nektery natolik abstraktni. IMHO se budou drzet samotne definice ORM, a to je konverze dat do objektu, tedy definic trid znamych pri prekladu a psani kodu s nimi.
Název: Re:Parametrizované príkazy
Přispěvatel: pf1957 22-12-2017, 18:11:22
...
Stejne jako definice pohledu na nej (vcetne pravidel pro stylovani podle hodnot). Samozrejme pro specialni pripady by byla stale moznost si takovou entitu vytvorit a pracovat s ni v kodu. Pro jednoduche editory tabulek bys ale nemusel napsat ani carku kodu, natoz aplikaci znovu buildovat - namisto toho bys jen nejakym runtime editorem naklikal co chces zobrazit a jak.
Neni mi jasne, k cemu by to melo byt dobre:
Nejak my smysl takoveho zameru unika...

Citace
IMHO se budou drzet samotne definice ORM, a to je konverze dat do objektu, tedy definic trid znamych pri prekladu a psani kodu s nimi.
Ano, ORM neni nic jineho nez ten relacni svet dostat do objektoveho a zpatky. Ale v tom objektovem svete muzes anotovat, pouzivat introspekci a vsechno co ti moderni jazyky a prostredi nabizeji a pokud se toho ucastni prekladac, tak zkontrolovat radu veci v dobe prekladu a ne az pri ladeni
Název: Re:Parametrizované príkazy
Přispěvatel: Delfin 22-12-2017, 19:55:25
...
Stejne jako definice pohledu na nej (vcetne pravidel pro stylovani podle hodnot). Samozrejme pro specialni pripady by byla stale moznost si takovou entitu vytvorit a pracovat s ni v kodu. Pro jednoduche editory tabulek bys ale nemusel napsat ani carku kodu, natoz aplikaci znovu buildovat - namisto toho bys jen nejakym runtime editorem naklikal co chces zobrazit a jak.
Neni mi jasne, k cemu by to melo byt dobre:
  • Uz pred Delphi existovaly zanikle VisualObjects, ktere umely automaticky z DB dat vytvorit CRUD editor s nejakym default layoutem, i kdyz kompilovanym

Asi neco takoveho. Jen bez nutnosti kompilace, vlastnorucne napsane (a tudiz upravitelne i pro pripad tvorby extra funkcionality, kde je treba psat extra Delphi kod s buildem aplikace); vzdyt muzu potrebne vytvorit "nazivo" v runtime s okamzitym pohledem na vysledek - a navrhovat by slo i oboustranne - ze schematu nabidnout modely tabulek pro tvorbu pohledu, nebo z "naklikaneho" modelu tabulky ji vytvorit v DBMS pomoci vygenerovaneho CREATE prikazu.

Me totiz porad unika proc pro "jednoduchy editor" tabulek a reportovac psat a buildovat dokola aplikaci pro kazdou z nich :P Nebo deklarovat v Delphi kodu kazdou entitu kdyz by pak byly de-facto nevyuzite v pripade spolecne funkcionality.
Název: Re:Parametrizované príkazy
Přispěvatel: pf1957 22-12-2017, 21:14:50
Me totiz porad unika proc pro "jednoduchy editor" tabulek a reportovac psat a buildovat dokola aplikaci pro kazdou z nich :P Nebo deklarovat v Delphi kodu kazdou entitu kdyz by pak byly de-facto nevyuzite v pripade spolecne funkcionality.
No ja nevim, nikdy jsem nepsal bezne DB aplikace, ale jednoduche tabulky, to jsou akorat nejake ciselniky a tech nebyva moc - ostatne kdyz je to web, tak VS je spolu s pouzivanym frameworkem schopen schopen vyprasit z ViewModelu nejakou default HTML stranku pro CRUD.

Nebo deklarovat v Delphi kodu kazdou entitu kdyz by pak byly de-facto nevyuzite v pripade spolecne funkcionality.
Tomu nerozumim. Ja v DB zadne nevyuzite entity nemam
Název: Re:Parametrizované príkazy
Přispěvatel: Delfin 23-12-2017, 03:13:29
Nebo deklarovat v Delphi kodu kazdou entitu kdyz by pak byly de-facto nevyuzite v pripade spolecne funkcionality.
Tomu nerozumim. Ja v DB zadne nevyuzite entity nemam

Ja myslel v Delphi kodu. Viz napr. posledni navrh, proc bych v pripade entit s nimiz by se pracovalo naprosto stejnym zpusobem potreboval jejich definice kdyz bych na ne (v tom kodu) nikde ani nesahl (tim jsem myslel ze by byly [tedy z pohledu kodu] nevyuzite). Nebo zkracene, proc vubec deklarovat napr. takoveto 2 datasety kdyz budou ve finale fungovat uplne stejne a muzu si jejich definici ziskat ze sablony:

Kód: Delphi [Vybrat]
  1. type
  2.   TDataModuleXyz = class(TDataModule)
  3.     ...
  4.     cdsAbc: TClientDataSet;
  5.     cdsAbcId: TIntegerField;
  6.     cdsAbcSomething: TStringField;
  7.     cdsAbcSomethingElse: TStringField;
  8.     ...
  9.     cdsXyz: TClientDataSet;
  10.     cdsXyzId: TIntegerField;
  11.     cdsXyzIdent: TStringField;
  12.     ...
  13. end;

A kdybych v tom navrhovanem framework pro nektery dataset dopsat extra funkcionalitu v kodu, mohl bych si fixni definici datasetu ulozit do stejne konfiguracni sablony (ktera by se jinak naklikala v runtime aplikace) napr. do resources aplikace a vytvorit instanci daneho datasetu a pracovat s nim v kodu. Ano, ztraci se tim typovost v kodu, nicmene porad myslim jen na "jednoduchy editor tabulek" se spolecnou funkcionalitou jez znacne prevazuje psani specifickeho kodu.

Navic, i s tou deklaraci dataset objektu v design-time ses uz typovosti dobrovolne vzdal; napr. proti tomuto by kompilator nemel co rict:

Kód: Delphi [Vybrat]
  1. var
  2.   TheMoment: TDateTime;
  3. begin
  4.   TheMoment := cdsAbcSomething.AsDateTime; // jde o string field
  5. end;

Takze kdybych napsal se svym teoretickym framework pro dataset objekt vytvoreny v runtime za pomoci kodu (definovany napr. sablonou ulozenou v resources aplikace) neco takoveho, nebude v tom pro kopilator zadny rozdil (jen MyRuntimeOnlyDataset by tady byl deklarovany jako TClientDataSet jehoz plny popis [jako napr. zdrojova entita, jake ma vazby, atd.] pochazi z "fixne" ulozene sablony, ne z design-time deklarace):

Kód: Delphi [Vybrat]
  1. var
  2.   TheMoment: TDateTime;
  3. begin
  4.   TheMoment := MyRuntimeOnlyDataset.FieldByName('Something').AsDateTime; // jde o string field
  5. end;
Název: Re:Parametrizované príkazy
Přispěvatel: pf1957 23-12-2017, 08:21:24
Ja myslel v Delphi kodu. Viz napr. posledni navrh, proc bych v pripade entit s nimiz by se pracovalo naprosto stejnym zpusobem potreboval jejich definice kdyz bych na ne (v tom kodu) nikde ani nesahl
No to je to, cemu nerozumim: vezmi napr. kalendar svatku v dane zemi - ten prece v aplikaci nemam kvuli tomu, abych ho prohlizel a editoval v CRUD, ale proto, ze zbytek aplikace potrebuje s temi svatky pracovat napr. kdyz zkouma chovani trhu v ruzne dny v tydnu, planuje objednavky jen na pracovni dny, velikost objednavky zalezi na tom, jake dny nasleduji atd.

Ale uznavam, nejsem datar a muj pohledem na svet DB je prioritne objektovy, takze ja entitu nenavrhuju *jen* kvuli CRUD, ale predevsim kvuli zbytku aplikace. To, ze na ciselnik potrebuju CRUD, je uz jenom podruzna zalezitost. A v takove aplikaci nejaky automatismus na CRUD moc nevyresi, tech ciselniku nebyva velke mnozstvi, jednoduche "tabulky" k editovani se jinak moc nevyskytuji - jsou naopak dost slozite a treba s verzovanim dat a slozitost/pracnost vlastni aplikace je radove jinde nez CRUD pro par desitek ciselniku.

Jeste detail k tomu prikladu: tam jsem predokladal ze 1 entita = 1 DM = 1 CDS. S tou namitkou s typovosti mas pravdu, ale proto preferuju ty ORM vsude, kde je to jen trochu mozne.
Název: Re:Parametrizované príkazy
Přispěvatel: Delfin 23-12-2017, 10:24:30
Ja myslel v Delphi kodu. Viz napr. posledni navrh, proc bych v pripade entit s nimiz by se pracovalo naprosto stejnym zpusobem potreboval jejich definice kdyz bych na ne (v tom kodu) nikde ani nesahl
No to je to, cemu nerozumim: vezmi napr. kalendar svatku v dane zemi - ten prece v aplikaci nemam kvuli tomu, abych ho prohlizel a editoval v CRUD, ale proto, ze zbytek aplikace potrebuje s temi svatky pracovat napr. kdyz zkouma chovani trhu v ruzne dny v tydnu, planuje objednavky jen na pracovni dny, velikost objednavky zalezi na tom, jake dny nasleduji atd.

U aplikace planujici objednavky toho moc nesjednotis treba s ovladanim vyroby. Holt musis napsat funkcionalitu separatne, protoze neni co sjednocovat. Pointou k zamysleni v tomto pripade je, jaka extra logika je treba pro aplikaci spravy domu (coz je pro me z majoritni casti "jen" editor tabulek plus nejake agregaty a reporty), ne jak se da co nejrychleji sestavit ze skladovych zasob dodavatelu raketoplan ;D Chci rict, ze mam za to ze ta aplikace bude mit spoustu shodneho a ze by se mohla casova investice do vlastniho maleho frameworku vyplatit.
Název: Re:Parametrizované príkazy
Přispěvatel: Stanislav Hruška 23-12-2017, 11:13:25
Citace
Pointou k zamysleni v tomto pripade je, jaka extra logika je treba pro aplikaci spravy domu (coz je pro me z majoritni casti "jen" editor tabulek plus nejake agregaty a reporty)
Ten editor tabuliek sa uplatní hlavne pri zakladní SVB. Tých tabuliek je zhruba 16. Okrem podružných - s občasným editovaním. Potom už len občas podľa zmien.
Hlavná činnosť spočíva
Vzhľadom na skutočnosť, že tabuľka záloh je riadková, tak pre s ňou sa nedá použiť editor tabuliek. Komplikuje to aj získavanie údajov z nej, ale nie je to problematické.
Neviem čo máš na mysli pod agregátmi. Predpokladám, že spracovanie samotného vyúčtovania. To je kapitola sama o sebe.
Potom už naozaj nasledujú rôzne zostavy: samotné vyúčtovanie, prehľady číselníkov a registrov (zoznamy vytvorené užívateľom - byty, vlastníci...) a všelijaké štatistiky a prehľady podľa požiadaviek praxe.
Název: Re:Parametrizované príkazy
Přispěvatel: Stanislav Hruška 23-12-2017, 13:04:24
Poznámka: pre tvorbu SQL príkazov užívateľom plánujem použiť jedine FastCube. Tomu by užívatelia mohli rozumieť. Prípadní užívatelia budú totálni analfabeti v IT s rôznym stupňom vzdelania a IQ.
Název: Re:Parametrizované príkazy
Přispěvatel: Delfin 23-12-2017, 15:05:00
Poznámka: pre tvorbu SQL príkazov užívateľom plánujem použiť jedine FastCube. Tomu by užívatelia mohli rozumieť. Prípadní užívatelia budú totálni analfabeti v IT s rôznym stupňom vzdelania a IQ.

Vsak tim "uzivatelem" muzes byt Ty. Jen budes fakturovat za "slozitou" upravu aplikace ;) Dlouze jsem se diky podobnemu reseni "houpal na zidli" :)
Název: Re:Parametrizované príkazy
Přispěvatel: Miroslav Baláž 23-12-2017, 15:48:41
Poznámka: pre tvorbu SQL príkazov užívateľom plánujem použiť jedine FastCube. Tomu by užívatelia mohli rozumieť. Prípadní užívatelia budú totálni analfabeti v IT s rôznym stupňom vzdelania a IQ.
Pozrel som FastCube. Vyzera slusne. Si s tym spokojny? Ako dlho s tym pracujes?
Název: Re:Parametrizované príkazy
Přispěvatel: Stanislav Hruška 23-12-2017, 16:16:59
Citace
Ako dlho s tym pracujes?
0 sekúnd 8)  Sú tu ľudia, ktorí to majú nasadené ostro. Chvália si to.
Název: Re:Parametrizované príkazy
Přispěvatel: pf1957 23-12-2017, 19:33:53
ne jak se da co nejrychleji sestavit ze skladovych zasob dodavatelu raketoplan ;D
No tuhle cast resi asynchronne pracujici nevizualni service, nicmene BFU musi mit moznost rucne do vygenerovanych objednavek zasahovat + objednavky potvrzovat :)

Citace
Chci rict, ze mam za to ze ta aplikace bude mit spoustu shodneho a ze by se mohla casova investice do vlastniho maleho frameworku vyplatit.
Ja mel dojem, ze se zabyvas obecnejsim frameworkem, ktery mj. by sel pouzit na ten management bydleni...
Název: Re:Parametrizované príkazy
Přispěvatel: Delfin 24-12-2017, 10:38:29
Citace
Chci rict, ze mam za to ze ta aplikace bude mit spoustu shodneho a ze by se mohla casova investice do vlastniho maleho frameworku vyplatit.
Ja mel dojem, ze se zabyvas obecnejsim frameworkem, ktery mj. by sel pouzit na ten management bydleni...

To ano. Jen se ted snazim lobbovat za nepotrebnost deklarace entit v kodu. Samozrejme v pripade nutnosti bys je nadeklarovat v kodu mohl - napr. uplne stejne jako ted programatori deklaruji tridy entit a tvori jejich instance z radku objektu datasetu. A pohledy na takovou entitu samozrejme nejsou podminkou :)