Newsgroup: it.comp.java
Titolo: [OT] DB or OO?

Ho dei dubbi pratici sul passaggio da programmazione con approccio DB
relazionale ad approccio OO.
In tempi in cui non esisteva l'interazione con il programma (CODD -
1976) ma solo un terrificante data-entry (normalizzato), il requisito
utente era sempre un tabulato con la stampa di una tabella
(denormalizzata) recante informazioni per lui significative.
A volte la tabella era enorme e veniva stampata su qualche kg di
tabulato.
Grosso passo avanti è stato fatto nella presentazione del tabellone
finale, presentazione che si può sintetizzare e fruire mediante nuovi
concetti e tecniche grafiche/interattive.
Ma il tabellone è rimasto comunque un requisito molto importante.
Ed è un requisito spesso fondamentale che un certo utente sia messo in
condizioni di operare con buona autonomia nell'analisi della base dati
secondo i propri scopi, costruendo e analizzando tabelloni definiti
con criteri "ad libitum" e "una tantum" con un qualche programma di
interfaccia per le query.
Per mia esperienza l'utente evoluto riesce -con un po' di pazienza- a
capire le relazioni e come fare le query con uno strumento qualsiasi.
Sono molto preoccupato che lo stesso utente riesca a districarsi a
fare le query su un db che nasce come strato persistente di un modello
OO.
Presumo infatti che l'utente sia più portato a ragionare con relazione
e join di tabelle nel modello db (anche normalizate) in cui lo schema
è definito da concetti intrinseci e visibili nell'informazione stessa,
piuttosto che con tabelle che esprimono la persistenza di oggetti
legati tra loro da concetti di responsabilità intrinseci di altri
processi che possono esseregli estranei.
Non so di esperienze in merito.
E ancora. Cosa succede se cambio la struttura degli oggetti? Dato che
OO non è una religione ne veniamo fuori con quattro colpi ben
assestati di SQL e una bella elaborazione record per record in stile
vecchia migrazione del db?
Oppure qualche pattern con cui inglobo l'oggetto vecchio
nell'interfaccia del nuovo? E la analisi dei dati on fly?
Se qualcuno mi dice che la struttura degli oggetti non si cambia mai,
passo al COBOL.
Nicola Grippaldi

 passo al COBOL.
La struttura degli oggetti evolve - ma, contrariamente all'approccio E/R - 
in ambito OO si riconosce che tale evoluzione e' un processo complesso di 
per se' che richiede gestione esplicita e attenzione. Non e' che non sia 
vero con l'E/R, e' solo meno immediato - col risultato che la stragrande 
maggioranza dei database applicativi "degradano" col tempo e le modifiche.
Tenativi di fornire strumenti di base per tale gestione (come "id" di 
classi e regole di compatibilita' automatica) in proposito cominciano ad 
esserci in molti linguaggi, da C++ a Java.
-- 
Life's something u don't get out alive..
ObjectZone - 
http://space.tin.it/computer/csadun

 esserci in molti linguaggi, da C++ a Java.
Bho! A me non pare valga la pena, almeno nel campo gestionale. Se il
degrado avviene in un tempo superiore al lustro o se c'è una
rivoluzione, meglio cogliere l'occasione per fare una nuova versione.
Sarà l'occasione per cambiare verso una piattaforma più moderna che
sarà obbligatoria tra altri cinque anni.
Ma forse sono solo un selvaggio.

 Ma forse sono solo un selvaggio.
No, e' che pensi in piccolo. Se il tuo sistema ripaga l'investimento in 
dieci anni e lo cambi in cinque... :-D


 dieci anni e lo cambi in cinque... :-D
......Giusto.
La scala di investimento sw a 10 anni non l'ho mai incontrata.

La scala di investimento sw a 10 anni non l'ho mai incontrata.
Quasi tutti lo sono, ma pochissimi vi arrivano.
-- 
Magellano
"Contro la stupidita` anche gli Dèi lottano invano",
da _Giovanna d'arco_ di Friedrich Schiller

 un programmatore per definirli. 
Non necessariamente. Tipicamente, per "business objects" stanno emergendo 
standard (generalmente, appunto, XML-based) che definiscono una volta per 
tutte sia gerarchie di classi che processi che fanno uso di quelle 
gerarchie, ed esistono interfacce che, per esempio, consentono di usarle in 
modo "visuale".
*Ad oggi*, pero', non c'e' ancora nulla di equivalente ad Access.
Infine, un'opinione: la cosa puo' non essere troppo malvagia. L'utente deve 
avere piena liberta' nel definire _cosa_ vuole fare; ma il _come_ farlo 
dovrebbe essere lasciato a professionisti. Meccanismi come quelli che citi, 
che consentono all'utente di costruirsi le sue applicazioncine e query 
senza aver basi solide sulla relativa scienza sembrano (e sono) utili a 
breve termine, ma in genere (in casi non banali) risultano in sistemi e 
processi cosi' frammentati ed inefficienti da essere, a medio e lungo 
termine, molto piu' costosi di integrazioni e applicazioni ben realizzate 
con identiche funzionalita'.. anche se a prima vista non *sembra*. :)
C'e' anche da notare che purtroppo esistano una marea di "professionisti" 
che hanno anche meno scienza dell'utente. Ma questo e' un altro discorso. 
:)


Ma questo e' un altro discorso. 
Si, ma in *strettissima* sinergia con gli altri.
-- 
Magellano
"Contro la stupidita` anche gli Dči lottano invano",


 O(lettera O) con il bicchiere.
Be', se "avere la scienza" signfica sapere quel che si sta facendo, essere 
in grado di valutare rischi e conseguenze e prendere rischi meditati (ed 
esser coscienti di prendere rischi), allora ovviamente e' sinonimo di 
capacita'. Se significa ripetere a pappagallo qualcosa, no. :) Ma io 
intendevo la prima.



Certameeeeeeeeeeeeeeeeente !!!!!! 
Solo breve termine, per carità. 
Ma sai quante lamentele in meno perchè il "programmino che non ci
vuole niente a farlo" e che serviva entro 30' non è ancora pronto?
E poi si diffonde un po' di cultura tra gli utenti, che fa tanto bene.

Quasi tutti lo sono, ma pochissimi vi arrivano.
Se un investimento è a 10 anni e non ci arriva, vuol dire che era un
investimento sbagliato. Forse è per questo che non ne conosco ;-)
Pensavo più che altro a grandissimi progetti: compagnie aeree, grandi
sistemi di telecomunicazione, ricerca aerospaziale  ecc...

intendevo la prima.
*Non* avevo dubbi sul fatto che tu potessi intendere la prima, la mia
voleva essere solamente *un sottolineare* ed ampliare un concetto che
troppo spesso, ma non sempre intendiamoci, viene trascurato.
Ed e giusto sottolinearlo a quelle persone che avvicinano la realta
;-) per le prime volte, e non sempre hanno la possibilita di avere
vicino persone di *scienza*.
Un buon professionista ha e deve avere scienza e capacita in buon
misura.
IMHO


sistemi di telecomunicazione, ricerca aerospaziale  ecc...
Beato te e sfortunato me. :-< ;-D
A maggior ragione il discorso fatto pocanzi.
Stiamo balenando nell'[OT] :)
-- 
Magellano
"Contro la stupidita` anche gli Dči lottano invano",


 E poi si diffonde un po' di cultura tra gli utenti, che fa tanto bene.
La cultura che si dovrebbe diffondere e', imho, non tecnologica, ma di 
progetto. Nessuno si aspetta che una costruzione edilizia "non ci voglia 
niente a farla", anche se e' una casetta a un piano o un ripostiglio per le 
scope. Cosi sistemi software, invece..


Scusate se mi intrometto in questa interessantissima discussione.
Ho sentito parlare molto di DB OO, e, in questo thread, di linguaggi di
scripting per "interrogarmi". Potreste darmi nome e cognome di un paio
di questi strumenti attualmente in commercio? Magari con un ordine di
grandezza dei prezzi (10, 100, 1000, 10000 euro per "utente")?
Grazie
Ciao
Franco

 Grazie
Non so se ti può interessare ma l'unico DB OO che conosco è ZODB
che è il DB integrato con Zope (Zope stesso è una piattaforma
completamente ad oggetti)
trovi maggiori informazioni su 
www.zope.org
ad esempio qui
http://www.zope.org/Members/michel/HowTos/ZODB-How-To
-- 
Rhymes (rhy...@NOSPAMmyself.com)
linux registered user #219707
linux registered machine #172395