Názory k článku PL/Perl, PostgreSQL (2) aneb jak na aplikační server

Neni to vytrzeno z relity. To existuje (napadaji mne dve takove Oracle aplikace), a rekl bych ze tak casem dopadne i kazda dvouvrstva aplikace, ktera se trosku rozroste a autori podlehnou kouzlu schopnosti DB:-) Dulezite je davat si pozor, protoze hranice prorustani logiky a ulozeni dat je pro radu autoru software dost ruzna.

Ostatne negativa jsou v clanku naznacena.

Muzete mi poslat link, nebo nejake blizsi informace

Zaleží co potřebujete dělat. Pokud je Vaše aplikace data centrická, tak pak tak úplně mimo není. To, že mohu použít libovolný jazyk uložených procedur je těžká výhoda. Kód je kratší, přehlednější. Alespoň pro mne. Už jsem se dostal do stavu, kdy externí jazyky používám snad jen pro spuštění uložené procedury a prezentaci výsledků. Nemohu si pomoct, kód v PL/pgSQL je podstatně čtivější. Víc mi šlo ale o prezentaci filozofie, že na každou vrstvu lze chápat ne jako sadu procedur, ale jako sadu aplikací. Je to trošinku něco jiného

Proc ne. Je to taky jeden z trendu. Priznam se, ze nerozumim, proc by preneseni casti logiky do databaze bylo dlouhodobe neudrzitelne. Zatim jsem neslysel jediny argument! Cim se lisi kod procedury v PL nebo v Jave? V PL nemam objekty, ale zas mam integrovane SQL. Pokud pisi aplikacni logiku v Jave, nebo v MTS, tak fakt nejsem zavisly na RDBMS. Potrebuji jedine, rychle serializovat a deserializovat objekty. Nic vic. Jenomze: stanu se zavislym na Jave, MTS, atd; pristup k datum mam o jednu uroven vys. Zavislost na Jave nebo zavislost na PostgreSQL nebo MsSQL, Oracle neni argument. Technologicka zavislost proste existuje u vsech aplikaci. To, ze musim do DB skrz dalsi vrstvu uz argument je. Mozna mam jen par negativnich zkusenosti s nekolika projekty, kdy bylo prakticky nemozne se dostat k vlastnim datum v databazi: protoze dodavatel zakazal jakykoliv primy pristup do db, protoza data byla ulozena v nestandardnim formatu v databazi. Jakykoliv import, export dat byl vylouceny, pokud si uzivatel nazaplatil za zvlastni importni, exportni programy. Mozna optimalni je kompromis: silna db vrstva, silna aplikacni, a to i za cenu rizika, ze nektere casti budu programovat dvakrat (ackoliv to je klasicka technika, jak bezpecny sw).

Ve starém Rootu jsem si musel v diskusích několikrát stěžovat na trend zkracování. U jednoho z článků (myslím že to bylo "Základy programování pro všechny 358" :) ) jsem dokonce napočítal bez příkládečků něco přez 400b.

Pokud by root(autoři) začal s novým designem produkovat zároveň články tohohle typu (a mohla by se i zhoršit kvantita, nic by se nestalo), byla by to ta nejlepší změna.

Myslím, že mluvím za víc lidí, když říkám "jen tak dál Roote (a autore)"

Pekny clanek. Je take pekne jak se novy design dokaze poprat s priklady ktere jiz nemrsi omezenou sirkou. Pomalu se mi ten design zacina libit:-) [no flame!]

Díky za kvalitní článek. Moje otázka však zní, jestli má některý z čtenářů článku zkušenosti s PL/Java. Koncem ledna vyšla finální verze 1.0.0 a prozatím jsem nenašel příliš dokumentace.

Bohužel ne. Sice nemám na notebooku verzi 8.0.0, ale jeden z realease candidate, chování je však velmi podobné 7.4. Osobně to řeším vlastní funkcí upper, kterou jsem si napsal pro vybrané kódování.

Release Notes -- Release 8.0:

Fix upper/lower/initcap() functions to work with multibyte encodings (Tom)

Pro jistotu jsem to ještě vyzkoušel na 8.0.0 (FreeBSD) a výsledek je stejný. Upper nefunguje správně.

ono to funguje pouze tehdy pokud mate UTF8 locales

Dnes se v konferenci objevil path

Hi list,


Attached for your perusal, unicode versions of upper/lower, that work
independent of locale except for the following languages:

Turkish, Azeri, and Lithuanian.
There are 15 locale specific cases in total not covered.

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 :-)

Docela zajímavý článek (jakkoli souhlasím, že trochu diskutabilní námětem). Ale neodpustím si: nevím, co je to konfort či bussines. ;-) [No dobře, už se jdu ohodnotit 1 bodem.]