Vlákno názorů k článku PL/Perl, PostgreSQL (2) aneb jak na aplikační server od anonym - kdyz musim cist, jak dalece se podarilo vyrobcum...

Ale nespolkli:-) Myslim, ze zrovna v debatach na root.cz jsem psal o tom, ze je dobre davat si pozor na "vepsani" aplikace do DB. Ja bych to napriklad neudelal i kdyz je to tak jak to autor v clanku ukazal docela lakave.

Psani aplikaci do DB je proste jedna z cest a je zbytecne pred ni zavirat oci. Je to volba a je dobre, ze je zde moznost volby a ze o tom nekdo napise clanek.

Dobra neni aplikace, ktera sezrala vsechnu moudrost designeru software, ale ta ktera za unosnych nakladu funguje pro sve uzivatele. A jsou takove aplikace i napsane zpusobem popsanym v clanku.

p.Zak uz pravdepodobne tento aplikacni sever nedokonci protoze nema cas a uz jemu jasne, ze zacal moc zesiroka. Ale je jiste ze niceho nelituje. Dost se naucil a poucil :-)

Opakuji záleží co děláte. Zopakuji argumenty pro a proti (které mne napadnou):
+ čitelnost kódu, pro manipulaci s daty používám jazyk, který je k tomu určený
+ rychlost zpracování (a) předzprac. dotazy, b) neproháním kvanta dat mezi S a C
+ jednotný přístup k datům skrze ODBC, web klient, atd. Aplikační logika je v db
a nemusím se bát uvolnit db vrstvu uživatelům.
+ aplikace musí být minimálně dvouvrstvá
==========================================================================
- aplikace se stává závislou na platformě
- aplikace musí být minimálně dvouvrstvá

Ještě další negativa? Rád se je dozvím.

Ať děláte co děláte musíte se napřed pořádně zamyslet, jestli použití uložených procedur Vám ušetří práci, umožní napsat šikovnější kód nebo ne. Sic si dovolím tvrdit, že skorem vždycky se nějaká ta uložená procedura vyplatí napsat, ale nemusí to být pravidlo. Trochu puritánské je tvrzení, že uložené procedury nejsou potřeba nikdy a že pokaždé přinesou podstatné nevýhody. Důležité je myslet u práce a nebát se zkoušet něco nového. Výrobcům, autorům aplikací naslouchám dost pozorně. Už jsem se naučil, že určité aplikace lze znásilňovat ale sem tam se to nevyplatí. Stačila mi moje první zkušenost, kdy jsem v Excelu dělal soft, který měl být psán v Accessu, další rok jsem předělával do Accessu evidenční soft, který byl také původně v Excelu. Po dvou dnech práce se aktualizace zrychlila z 2hodin na 10 sekund. Jakési uložené procedury Access má, i když se píší ve Visual Basicu. Když Microsofti tvrdili, že MsSQL SP má, ale jsou v podstatě k ničemu, tak jsem je nepoužíval (ti co je používali mi potvrdili, že jsou problematické). Když pak v sedmičce opravili chyby a začali se zmiňovat, že už by se použít mohli, začal jsem je používat, a dost se mi to vyplatilo.

Nikdo za Vás nenapíše kód řešící daný problém. Ten budete muset napsat, tak jako tak, ať použijete MySQL a PHP (žádné uložené procedury) nebo PostgreSQL a PHP s uloženýma proc. Určité funkce se Vám ale dobře, možná, budou psát v SP.

K argumentům: Netuším proč by uživatel musel přijít o svá pracně namlácená data, pokud selže nějaká akce a požívá uložené procedury. Záleží na interface. Např. v PHPku není problém zobrazit chybovou hlášku a vrátit dříve zadaná data. Žádný problém. Záleží jak moc si chcete dát práce s aplikací. Loni jsem si hodně zjednodušil práci na jednom projektu (kontroly jsou skutečně jen na úrovni databáze), ale rozhodně uživatel o svá pracně zadaná data nepřijde, když ho kontroly pošlou někam. Navíc jsem si ušetřil fůru práce navíc, kdy jsem některé netypické operace neřešil. Nainstaloval jsem PhpPgAdmina, a pustil uživatele do db. Díky kontrolám mi tam nemůžou nadělat žádnou paseku. A paseku v datech si nemůžu udělat ani sám, kdybych na něco zapoměl.

Druhý argument: použití db uživatelů a aplikačních uživatelů versus dynamické zobrazení dat. Potřebuji zobrazit pouze určité informace, ostatní překrýt ****. Co se zobrazuje a kdy, záleží na obsahu tabulky a uživateli. Stačí mi 2 db uživatelé: první je vlastník tabulky, druhý bude sloužit pro všechny ostatní uživatele. Seznam aplikačních uživatelů a jejich práva mám v tabulce. Ty nepustím do originální tabulky, ale mohou spouštět SETOF RECORD funkci, která si zjistí práva, a profiltruje obsah. A mám vystaráno. Pro časté operace napíšu GUI, bych netrýznil uživatele vyplňováním univerzálních formulářů. Nemusím se ale bát uživatelům zpřístupnit databázi skrz ODBC, ať už si dělají vlastní formuláře nebo reporty v Accessu nebo plní tabulky v Excelu. Pokud bych nepoužíval uložené procedury všechno bych musel programovat sám, poněvadž nesmím uživatele pustit k databázi. Což na jednu stranu není až tak špatné (víc práce, lepší byznys), na druhou stranu to není nic pro mě. Radši si jdu rozvalit někam na louku s lahví vína :-)