Newsgroup: it.comp.java
Titolo: [Hibernate] Opinioni sulle views dei DB relazionali

Chiedo a voi una opinione sulla mia opinione
Condividete le seguenti affermazioni ?
Viste e Hibernate:
1. Le viste hanno problemi di portabilita' e di installazione
2.Hibernate e' un framework che rende a oggetti un db relazionale.
Usare le viste con hibernate porta a non avere piu' la possibilita' di
utilizzare la potenza del db a oggetti in quando viene esclusa
l'ereditarieta' e viene praticamente persa la navigabilita' a oggetti
tramite il "punto"
3. L'utilizzo piu' correetto di hibernate sarebbe il seguente:
Si modellano le tabelle sul file hbm, e si fa generare il database al tool
apposito hibernat-jboss
Si puo' utilizzare hibernate per dei reverse engineering, di solito quando
si ha una vecchia base dati , magari di 20 anni, e si vuole usare hibernate
solo come pattenr di programmazione, minima ottimizazzione della
persistenza, e/o per un minimo aggiornamento tecnologico.
E' un peccato usare uno strumento di potenza simile in modalita' "reverse"
su un progetto in fase di costruzione
4.
sostanzialmente si mappa una classe hibernate e relativo pojo su ciascuna
vista.
Come si dovrebbe ben sapere hibernate richiede l'elezione di una chiave
primaria semplice o composta.
Il motivo e' ovvvio, cioe' lui in base alla chiave verifica se il pojo in
questione e' "persistentizzato"
Quindi il motivo e' legato alla stessa esistenza e uso di Hibernate
Questo significa che se 2 o piu' record della tabella o in questo caso della
vista dovessero avere chiavi identiche, hibernate fornira' di fatto lo
stesso pojo dalla sua cache interna per ogni record del db.
Spesso allora per mappare vecchie viste da reingegnerizzare, i progettisti
di database provano a eleggere come chiave primaria "fittizia" della vista,
l'intero set di campi.
Cio' dovrebbe garantireil recuperio di tutti i record, "quasi sempre",
infatti una vista che da 2 tuple identiche non ha molto significato
semantico, pur essendo sintatticamente corretta.
Purtroppo pero' in questo caso vengono vietati sostanzialmente in tutto il
database i campi nulli.
Si puo' provare a elegere come chiave l'insieme delle chiavi delle tabelle
coinvolte nmella vista.
Questo secondo approccio permette un uso libero dei NULL sui campi non
chiave ma ha i seguentyi limiti:
A. Qualora una vista coinvolga 3 o piu' tabelle, di cui 2 delle 3 hanno una
chiave esterna che permette i NULL nulla sulla prima tabella
se una delle 2 chiavi esterne e' NULL, l'intero record viene perduto.
Do un esempio per semplificare :
Se una persona di una tabella persone, puo' avere o meno una residenza con
l'Id residenza e i dati di residenza in una tabella correlata n:1, qualora
la persona non ha la residenza, la persona sparisce dalla vista.
Lo stesso per una automobile che non ha il bagagliaio o la capotte eccetera.
Cioe' non possiamo avere chiavi esterne nulle , il che mi pare una
assurdita'.
B. Lo stesso problema vieta l'uso nelle viste deli left join e outer join
Una scelta accurata dei campi, l'utilizzo esclusivo degli inner join,
l'utilizzo di qualche sorta di "trucco" per convivere col problema, potrebbe
portare il progetto a funzionare in qualche modo.
5.
L'utilizzo di viste con hibernate e' comunque assente o marginale nella
documentazione ufficiale ( credo assente)
Oltre che come detto completamente contraddittorio e innaturale per la
modellazione dei database a oggetti.
N
 
 
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/

 Condividete le seguenti affermazioni ?
In realta' non e' perche' ho una sfrenata voglia di dibattere :-)
Ma mi servirebbe una vostra opinione anche solo su alcuni di questi punti.
In particolare mi servirebbe sapere se alcune mie osservazioni contro le
views sono infondate o sono tutte fondate.
E' una quesione spinosa per me e qualsiasi opinione e' benvenuta :-|
Nicola


 l'intero set di campi.
Brrrr... questo porta a tutti i problemi che hai elencato... e' proprio 
necessario
utilizzare quelle viste e/o non e' possibile eventualmente crearne di nuove?
Oppure, sempre se hibernate li supporta, far uso di attributi/relazioni 
flattened?
Altrimenti devi vedere se puoi bypassare l'algoritmo di uniquing e 
farti tornare
un array di raw rows al posto dei pojo.
Ciao
Mirko


Grazie 1000 per l'opinione.
Sto cercando di convincere alcuni colleghi a non usare del tutto le viste.
E siccome e' ancora possibile eliminarle, ogni opinione mi e' preziosa.
L'idea di neutralizzare l'uniquing, non e' affatto male, certo dovendo
scegliere fra eliminare le viste o l'uniquing, io opto chiaramente per la
prima strada.
grazie ancora
Nicola


modellazione dei database a oggetti.
Ho lavorato con le viste utilizzando Jakarta OJB anzichè Hibernate, ma
credo che il punto sia comunque simile. Personalmente sono favorevole
alla vista solo in alcuni casi, per i quali sono convenienti dal punto
di vista prestazionale: in pratica, se devo spendere 20 righe di codice
per costruire un criteria per produrre un semplice report, piuttosto
che "scomodare" 'n' oggetti o costruire clausole troppo complesse,
allora può essere il caso di valutare l'utilizzo della
vista...deleghiamo direttamente al DBMS lo sporco lavoro di estrazione
dei dati e facciamoci restituire il risultato incapsulato nel classico
pojo.
CIAO!


grazie anche a te.
OJB e Hibernate concettualmente sono simili.
Se fai generare il db ad hibernate di fatto puoi utilizzare a pieno
l'ereditarieta'.
Potresti generarlo tu ma modellandolo in modo completamente innaturale,
basta che vedi un db generato e capisci cosa dico, e' quai illegibile il db
generato da lui.
SUl quetry particolari ad alto carico concordo, amche se e' tutto da
dimostrare che un hiberenate su cui si e' fatto un buon lavoro di tuning
perda di molto dalla preistorica query nativa.
Ciauz e grazie ancora.
Nicola
