Vista materializzata vs POJO Vista basata su oggetti che rappresentano tabelle Oracle

Naviga le tue risposte
6

Ho circa 12 tabelle Oracle che rappresentano dati che vengono integrati da un sistema esterno nella mia applicazione web. Questi dati verranno utilizzati in modo informativo e comparativo per i clienti che utilizzano la mia applicazione Web.

In una pagina specifica della mia applicazione web, ho bisogno di combinare i dati da 3 a 5 tabelle Oracle per visualizzarli come una tabella HTML sulla pagina.

Al momento NON stiamo usando un framework (Apache Struts per esempio) e non siamo in grado di spostare questa applicazione Java in uno solo in questo momento (sto cercando di farci arrivare lì ...).

Non sono certamente un architetto, ma vedo uno dei due modi in cui posso effettivamente costruire questa pagina (so che ci sono altri modi, ma sembra che siano buoni ...): 1. Creare una vista materializzata Oracle che rappresenti l'aspetto della tabella HTML e quindi creare un POJO basato sulla vista che posso quindi integrare nel mio JSP. 2. Creare POJO che rappresentino le tabelle Oracle stesse e quindi creare un altro POJO che è la vista utilizzata per la tabella HTML e quindi integrare tale POJO nel mio JSP.

Per me, sembra che la Vista materializzata possa offrire risultati più rapidi, il che è sempre quello a cui miriamo nelle applicazioni web. Ma, se creo solo 12 POJO che rappresentano le tabelle Oracle e poi creo le POJO Views, ho il vantaggio di mantenere tutto il codice in un posto per questo e la possibilità di creare un numero qualsiasi di viste e componenti riutilizzabili nel mio applicazione web.

Qualche idea su quale potrebbe essere la via migliore? O forse ne conosci uno ancora migliore?

    
posta Zack Macomber 30.05.2012 - 22:00
fonte

3 risposte

4

Lo svantaggio più ovvio per una vista materializzata è il suo effetto su inserimenti, aggiornamenti ed eliminazioni o come risultato di essi. Se il tuo database non è volatile, questo è un non-problema.

Il secondo problema sarebbe la manutenzione futura: una modifica dei requisiti per la tabella html richiederebbe una revisione del JSP, dei POJO, dell'SQL e della vista. Se dovessi spostare la logica della vista nel tuo SQL, allora c'è una cosa in meno da modificare.

Quindi, non potresti semplicemente avere un pojo che viene caricato da una query che viene eseguita contro le 12 tabelle? Con gli indici giusti, dovrebbe comunque essere alquanto performante. Se non lo è, direi andare con la Vista materializzata.

    
risposta data 30.05.2012 - 22:14
fonte
6

I tuoi requisiti dichiarati non mostrano la necessità di una vista materializzata. Potresti usare le viste normali se vuoi. Quello che farà la vera differenza è come si codifica l'SQL e come si progettano gli indici oltre a quanti dati si recuperano in ogni chiamata al database. È anche possibile codificare la logica per combinare le tabelle nei processi memorizzati e con la singola chiamata ottenere i risultati.

    
risposta data 30.05.2012 - 22:24
fonte
0

Quello che faccio in quella situazione e funziona per me è:

  1. Crea una vista normale che rappresenta l'aspetto della tabella HTML
  2. Crea un POJO che legge tale visualizzazione e genera un output di testo separato da tabulazioni
  3. Crea un POJO che riceve i dati separati da tabulazioni e dipinge la tabella HTML

Le funzionalità future possono utilizzare la vista creata al passaggio 1.

Le funzionalità future possono utilizzare POJO creato al punto 2.

    
risposta data 24.08.2012 - 22:44
fonte

Leggi altre domande sui tag

DRY, string, e unit test Uso Pythonic della funzione isinstance?