Newsgroup: it.comp.java
Titolo: Complicarsi la vita... (Database, Tabelle di trascodifica)

Questo che segue è un cut (riadattato) di una mail spedita a un mio amico,
giusto per chiedergli un'opinione. La chiedo anche a Voi tutti :)
Intendevo postare un thread su cui chiedere opinione sulla tendenza di
alcuni a creare un database in cui ci sono una decina di tabelle di business
e 40 tabelle di trascodifica di codici inutili... L'ultima analisi che mi
hanno passato (perché a me come analisi mi passano il database...) prevede
per esempio, l'uso di una tabella che ospita due record
TABELLA STATO:
CODICE    DESCRIZIONE
    1          OK
    2          KO
Questo di sopra è giusto per fare un esempio.
Due record! una tabella!!!! e ne ho un'altro sacco.... tutte tabelle delle
balle che poi pretendono che io uso, magari per popolare una combo!!!
è follia oppure sono io che ho una visione del mondo distorta? Giuro che
stavolta accetto qualsiasi critica, perché comincio a dubitare di quello che
credevo di sapere...
Naturalmente ci sono anche integrity constraints, e tutto il resto. Per
sapere se lo stato di una certa entità è ok o ko devo mettere la tabella in
join... naturalmente lo stato è ralativa di un unica tabella. Potevo capire
se la stessa tabella di trascodifica venisse usata da più entità... ma avere
una tabella *dedicata* a tascodificare codici di un'unica tabella mi sembra
volersi complicare la vita.
Ho sollevato il problema con chi ha fatto l'analisi, e mi hanno raccontato
favole sui database 'normalizzati' e roba del genere. Ora capisco che mi ci
vorrebbero davvero delle migliori doti comunicative...
Ho visto qualcosa di strano anche sul db, ma spero di aver capito male... ad
ogni modo, penso che il prossimo post che faccio sarà una barzelletta sui
database.
E' la solita polemica che c'è tra gli analisti e i programmatori. Mi
piacerebbe vedere un'azienda dove gli analisti sono ex-sviluppatori, che
conoscono davvero quali sono i problemi dello sviluppo, e che sanno fare le
cose in modo semplice. Esiste o è solo nelle favole?
~Jigi

 piacerebbe vedere un'azienda dove gli analisti sono ex-sviluppatori,
se la trovi scrivimi.
Davide

> Che c'entra con Java ?
E' vero... dovevo metterci un [OT] nel subject. Sorry.
~Jigi

 ~Jigi
Auguri
Alessandro

 elementi, dovresti aprirti il progetto, rimodificare tutte le parti
<ZAP>
Se la tabella di decodifica contiene solamente "codice" e "descrizione",
la gestione particolare e' fatta in ogni caso all'interno del codice 
dell'applicazione (if codice=...), quindi devi metterci le mani dentro 
ugualmente.
Inoltre se il campo codice e' un Int (2 byte) e la descrizione e'
una stringa di due caratteri... non vedo molta differenza tra l'avere
la descrizione direttamente nella tabella "madre" senza una tabella
di decodifica.
Davide

 quello che credevo di sapere...
Non e' follia, ma l'approccio tipico di progettisti che considerano il
database come fondazione dell'applicazione, e/o prevedono che la
"manutenzione" sia principalmente sui dati, non sul codice. 
Il ragionamento di mettere costanti in tabelle e' che per
estendere/customizzare l'applicazione si possano aggiungere/modificare
"semplicemente" righe alla tabella. Che e' un'operazione che un analista
sa fare da se', senza bisogno di un programmatore. Da un punto di vista
diverso di quello del programmatore, questo e' un *grosso* vantaggio. :) 
Il che, non e' sbagliato in linea teorica (se l'approccio e'
procedurale/db-centered), per quelle situazioni in cui il processo cui i
dati sono sottoposti *e'* identico, a meno di dati collaterali
raggiungibili esclusivamente navigando relazioni (fk) tra tabelle (e se,
naturalmente, l'implementazione usa questa proprieta' invece di comparare
valori nel codice... tipicamente, 'ste cose si fanno con SQL embedded
piuttosto che nel linguaggio general purpose). 
Il problema e' quando questo approccio viene preso anche con dati che
richiedono processing *differente*, non modellabile/ato con navigazione
tra chiavi. 
In casi come il tuo - senza saper nulla - se il tuo codice *ha* due
risposte diverse per il caso 'ko' e 'ok' (in pseudocodice, if codice =
"ko" then .. else...), aggiungere un terzo valore alla tabella
*richiedera'* modificare il codice per gestirlo.. quindi il vantaggio e'
solo apparente. Molti analisti non hanno chiara questa distinizione. 
-- 
Life's something u don't get out alive..
ObjectZone - 
http://space.tin.it/computer/csadun

 wrote in message
news:9uqda0$a83n3$1...@ID-18487.news.dfncis.de...


 dati su filesystem. (oppure e' il discorso di chi non e' capace)
Puoi spiegarci meglio anche questo punto? Se ti riferisci alla pratica
XP di posticipare l'introduzione del DB solo quando necessaria mi sa che
hai un po' frainteso i vari thread. Perche' poi bisognerebbe buttare gli
anni di ricerca sui DB e sull'OO?
ciao
uL

 enterprise bean) in cui si aggiungono "strati" software per il
Java 2 enterprise edition, ed Enterprise Java Beans, sono proprio le
tecnologie che verranno utilizzate in questo progetto. Purtroppo dovremo
implementare molti degli EJB come CMP proprio perché i dati sono sparsi su
piů tabelle del necessario.
Lo definirei un progetto nuovo che nasce su un database legacy. Ma questa
sembra che sia la norma purtroppo.
ora devo skappare.
Thanks
~Luigi

> implementare molti degli EJB come CMP proprio perché i dati sono sparsi su
Lapsus: BMP, non CMP.

[...]
Questo contrasta con l'osservazione. ;-)


 ~Luigi
 Ciao

> e poi siamo programmatori, ognuno di noi ha sempre un opinione diversa.
La matematica non è un opinione, l'informatica sì: ad un problema si possono
trovare centinaia di soluzioni diverse.
Quello che cambia, da una soluzione all'altra, è la 'bontà', che si
commisura anche sui requisiti da soddisfare.
La soluzione è soggettiva, la sua bontà però è oggettiva, su questo non vi
sono dubbi.

 vi sono dubbi.
Purtoppo e' veramente *difficile* dare una definizione oggettiva (aka
"rigorosa") della "bonta'" di una soluzione informatica: a differenza di
una soluzione matematica, che di solito e' valutata da gente con un
determinato atteggiamento mentale, con determinati obiettivi e con una
chiara idea di quali sono le qualita' importanti da considerare nella
valutazione, una soluzione informatica commerciale e' osservata e
valutata da molti punti di vista diversi; e la stessa nozione di
"oggettivita'" adottata da questi punti di vista varia... e ha essa
stessa differenti livelli di qualita'. :) 
Anche da un punto di vista puramente tecnico, mentre e' possibile
calcolare delle metriche su sorgenti o fare valutazioni runtime
(throughput, turnaround time, response time, resistenza al carico,
eccetera), queste non solo non coprono l'intero concetto di "buona
soluzione" che sarebbe bello poter valutare, ma costituiscono, appunto,
una misura parziale da cui e' difficile estrarre una valutazione globale
di qualita'. 
Cio' detto, questa *non* e' una licenza per far passare robaccia.. :),
anzi. Solo, rendersi conto di come funzioni valutare e comunicare la
qualita' di un sistema software e' essenziale per poter sviluppare le
"buone" soluzioni.. e far si' che il resto del mondo sia d'accordo sulla
loro "bonta'". :) 


Ok, verissimo: ciò che è buono per me, può non esser buono per
qualcun'altro. Come si dice quì a Torino "Non tutti i gusti sono alla ménta'
:)
Ad ogni modo, quando il codice è scritto male, quando ci sono porcherie,
beh, lì penso che tutti (o quasi) possono concordare sulla 'non-bontà' di
una soluzione :) e garantito... di soluzioni 'non-buone' ce ne sono tante in
giro.