Newsgroup: it.comp.java
Titolo: 2 o 3 tier ?

Proprio questa mattina discutevo con il mio capo sulla validità di
realizzare un prodotto 2-tier (presentation e application)+(data base),
anzichè un più diffuso 3 tier.
Il prodotto in questione rappresenta un sistema informativo con n.#
client, che operano su un DB secondo regole definite in una business
login realizzata in java.
Il mio capo, su un libro (direi un ottimo libro) della Oracle, ha letto
che non sempre un approccio 3-tier risulta essere migliore di un 2-tier.
Questo libro, senza indicarne le motivazione tecniche (la
superficialità), sostiene che in funzione del numero e della dimensione
delle query una soluzione è migliore dell'altra.
In pratica:
- molte piccole query sql offrono migliori performance se l'architettura
impiegata è di tipo 3 tier;
- poche grandi query sql offrono migliori performance se l'architettura
impiegata è di tipo 2 tier;
Per quanto mi riguarda credo che sia una errato(posso sempre sbagliare)
e che sia sempre auspicabile una soluzione 3-tier con un numero minore
di query possibile (anche se a discapito della dimensione delle
istruzioni sql)
Secondo voi ho ragione o torto e perchè?
Ciao, CC
-- 
Posted via Mailgate.ORG Server - 
http://www.Mailgate.ORG

 Secondo voi ho ragione o torto e perchč?
In generale, non esiste nulla che sia "sempre auspicabile". :) Specie in 
architetture software. A parita' di buon design, la differenza teorica 
principale tra c/s e 3t e' il fatto che in 3t il layer di presentazione 
puo' esser staccato piu' facilmente e quindi piu' facilmente rendere 
l'applicazione disponibile su rete WAN. Applicazioni per cui questo tipo di 
disaccoppiamento non sia richiesto, o per cui l'uso della potenza di 
calcolo del client e' particolarmente rilevante, si fanno benissimo a 
tutt'oggi in c/s. 
-- 
Fighting for peace is like fucking for virginity
ObjectZone - 
http://space.tin.it/computer/csadun

Correggo una grossa imprecisazione.
Nel libro il 2-tier era indicato:
1 leyer = presentation
2 leyer = application + DB
Quindi riassumendo, il libro sosteneva che esistono casi in cui le
prestazioni generali aumentano se il DB si trova sulla stessa macchina
dell'application.
I casi menzionati, ideali per il 2-tier, sono tutti quelli in cui ci
sono molte interrogazioni sul DB tramite piccole istruzioni SQL.


 wrote in message
news:744819b9a2e7519f697...@mygate.mailgate.org...


 sufficiente a garantire buone prestazioni generali.
Parliamo di 90 postazioni client che erogano mediamente 53.3 transazioni
al minuto per 8 ore al giorno :-)
Quindi la rete non č proprio di piccole dimensioni.
Il vero problema perň non č tanto sceglire una architettura piuttosto
che un altra, quanto motivare tecnicamente la scelta che si intende
fare.
Se il prezzo č un fattore importante, in contesti di questo tipo le
performance lo sono ancora di piů.
Io propendo per un 3-tier a prescindere dalla tipologia di sql perchč
permette di:
1) verticalizzare le competenze dei vari elementi che compongono il
prodotto, favorendo cosě l'ottimizzazione di questi ultimi.
2) aumentare la coesione e diminuire l'accoppiamento dei vari tier
Credo che avere 2 processori (2 server) verticalizzati: uno sul db e uno
sull'application sia una scelta migliore che non avere un unico
processore su un unico server.
Anche se probabilmente si raggiungerebbero le stesse performance
computazionali su un unico sistema multi processore.
Insomma, qualche idea c'č l'ho sulla scelta da fare ma non mi sento
ancora in grado di difenderla a spada tratta.
Ciao CC


> Quindi la rete non è proprio di piccole dimensioni.
Io lavoro con db oracle e as oracle e posso spiegarti perché secondo me
il aoracle dice cosí.
Se hai delle query sostanziose avendo as+db sulla stessa macchina non
generi traffico in rete, la cosa comunque é aggirabile facendo un ampio
uso delle stored procedure (cioé ti fai tutta l'elaborazione lato db e
trasferisci all'as il minimo indispensabile magari usando delle tables*
su lato as che riempi con con i BULK BIND che ti permetto no di
trasferire in blocco n record in una struttura).
Se invece fai sopratitto query tipo OLTP piccoline e frequenti la cache
di solito ti permette di avere tempi di ritardo accettabili per
l'utente.
La cosa comica é che l'as della oracle in configurazione ottimale deve
essere distribuito su due macchine (struttura di controllo + as vero e
proprio) e sulla seconda richiede MINIMO 2,5Gbyte di ram. Che macchine
anno loro per suggerirti di mettere as + struttura +db sulla stessa
macchina?!!!!
Ni hao, Lelle.
* le tables sono delle versioni in memoria delle tabelle