Hlavní navigace

Názor k článku
Správa uživatelů a databázových objektů v PostgreSQL

Franta Kučera aura:80
20. 11. 2008 10:53 Nový

Re: co na to aplikacni server?

celé vlákno
1) „delegovat spravu prav az co nejdale, namisto pristupu 'resim si to sam'.“
To je pravda: nagrantování práv v SŘBD se dá věřit víc než vlastnímu řešení téhož v aplikační vrstvě.
ALE: ne vždy to jde (jeden koncový uživatel = jedno spojení do DB, což si často nemůžeme dovolit) a také je často tlustý klient jen zástěrkou, která „jako“ funguje, ale kdyby se uživatel připojil k DB přímo nějakým SQL klientem, ukáže se, že je tam bezpečnost velmi mizerná.

2) bezpečnost není jediné kritérium: více vrstev znamená větší flexibilitu, ve dvouvrstvé architektuře spojuješ část aplikační logiky a prezentační logiku do jednoho tlustého klienta → pokud budeš chtít vytvořit jinou prezentační logiku (např. Web, nebo veřejné API), budeš toho muset přepsat mnohem víc, kód se ti duplikuje…

Pokud budeš chtít nacpat veškerou aplikační logiku do databáze, děláš z toho vlastně zase třívrstvou architekturu: tabulky – procedury – tlustý klient. Akorát k psaní aplikační logiky používáš jiný jazyk než ve skutečném aplikačním serveru, což může a nemusí být dobré (IMHO to obecně moc dobré není*) a hlavně SŘBD není navrhován jako náhrada aplikačního serveru, tudíž nenabízí stejné služby jako AS → musíš si toho dost napsat sám, nebo to nějak zbastlit.

*) do DB bych dal jen část logiky, ne všechnu.