Databáze > Firebird a Interbase

TQuery - SP

(1/1)

Stanislav Hruška:
Existujú/máte nejaké všeobecné pravidlá, podľa ktorých sa rozhodnúť, čo ponechať na TQuery a čo na StoredProcedure? Pravidlá v helpe a pod. som čítal, ale mám na mysli niečo také:

Mám realtívne jednoduchý SQL (Select) výraz, ktorý vracia menšiu množinu dát. Vždy sú spúšťané užívateľom. Napr. výberom prvku zo zoznamu/stromu. Príklad mám zoznam objektov, ktoré si načítavam podľa dvoch podmienok

- je aktívny (to si môže užívateľ ľubovoľne meniť - určuje s ktorými chce pracovať)
- má "platnosť" pre daný rok

Tak či tak sa to vykoná na serveri. Ale

SP
- má viac možností, if apod.
- je optimalizovaná pre DB
- zmenšujem veľkosť klienta a zjednodušujem ho
- kto sa v nich vyzná, ak ich bude veľa

SQL
- SQL si v prípade potreby upravím na mieste, vidím ho
- pchať všetko na server mi akosi nevonia. Neviem povedať prečo
- môžem si nadefinovať spoločné časti. Konkrétne tak mám pre uvedený príklad string "Where", včítane parametrov. Je niečo také možné v SP?

Predpokladám, že z tohto pohľadu je jedno, či budem používať serverovú alebo embeded verziu FB.

To je otras, začnem písať a neviem svoje pocity/myšlienky dať na papier. Snáď ma pochopíte. Ďakujem.

pf1957:

--- Citace: Stanislav Hruška  17-10-2012, 13:37:10 ---Existujú/máte nejaké všeobecné pravidlá, podľa ktorých sa rozhodnúť, čo ponechať na TQuery a čo na StoredProcedure?

--- Konce citace ---
Ja myslim, ze pro tebe pripadaji v uvahu asi 2 prakticka kriteria:

* zivotni cyklus aplikace: v budoucnu muze vyvstat treba pozadavek na pristup pres internet obecne z nekolika ruznych klientu. Pokud nacpes zejmena business logiku na klienta, tak tvurce noveho klienta bude muset vse implementovat znovu, zatimco pokud to bude na strane serveru, jen pouzije jiz hotove.
* slozitost SQL: SQL jazyk je dost podivna zalezitost, kdy je nekdy docela zahul sestavit a odladit slozity SQL prikaz a to nemluvim o jeho udrzbe, kdyz se ti neco zmeni a ty musis takovy prikaz preformulovat. V takovem pripade je IMHO vhodne, nez se morit s SQL dotazem, je vhodnejsi pouzit SP, ktera ti umozni programovat proceduralne tj. rozbit vypocet na casti, pouzit pomocne promenne atd.Pokud nemas nejaky tool s podporou ladeni SP, tak to muze byt docela opruz. Da se udelat logovani do souboru (pres SP) a kdyz se ptaku ohnivaku povoli prava pro ExternalFileAccess, tak se da psat do textoveho souboru.

Jinak treba orientace pomoci IBE Experta bude vyrazne lepsi nez v Delphi kodu, protoze u kazdeho objektu v DB si muzes nechat zobrazit cross reference, tj. kdo ten objekt pouziva a jake jine objekty ten objekt pouziva. Samozrejme to predpoklada, ze pouzijes Descriptions a u triggeru a SP i komentare.

Stanislav Hruška:
Zaujal ma hlavne bod 2. IBE Expert-a mám. Takže sme dvaja experti   ;D

// Samozrejme to predpoklada, ze pouzijes Descriptions a u triggeru a SP i komentare.
Tomu nerozumiem, kde si o tom prečítam - kľúčové slová. Mám dva helpy.

- IBE Expert FireBird Guide
- IBE Book 2-2005

pf1957:

--- Citace: Stanislav Hruška  17-10-2012, 14:26:54 ---// Samozrejme to predpoklada, ze pouzijes Descriptions a u triggeru a SP i komentare.
Tomu nerozumiem, kde si o tom prečítam - kľúčové slová. Mám dva helpy.

--- Konce citace ---
Na to by ti mel stacit letmy pohled do GUI klientaIBE. Vse co definujes , pocinaje domainama a konce SP ma pole Description a kdyz ho zadavas, tak dole byva memo, kde je vhodne si popsat, co a k cemu je to dobry. Vedle toho triggery a SP predstavuji nejaky kod, takze je vhodne pouzit standardni SQL komentare /* .... */ a radkovy --.

Jinak cross reference objektu jsou na tabu Dependecies nahore, u jendotlivych poli v tabulce na tabu dole vedle Description. Ale plati to pro prof. edici IBE. Jak vypada standard nebo free nevim.

Stanislav Hruška:
Desktop Edition to má.
Na tie komentáre si budem musieť zvyknúť. Ak sa to rozbehne, tak tam toho bude dosť.

Navigace

[0] Seznam témat