Qual è il design migliore per la trasformazione dei dati?

5

Il database della mia azienda rende disponibili i dati su molte applicazioni esterne. Quindi ho bisogno di trasformare gli stessi dati in molte viste dinamiche . Vedo che un ex sviluppatore di database aveva implementato molte lunghe sequenze di sequenze di chiamate view-function-procedure per rendere la trasformazione più comune a tutte le applicazioni esterne. Penso che questa architettura e le richieste così lunghe (proc memorizzato chiama una funzione, poi la funzione chiama una vista e questa vista basata su un'altra e così via) sono un problema di prestazioni, almeno Query Optimizer non risolve questi problemi (per favore conferma il mio supposizioni).

È un buon approccio? Provoca il degrado delle prestazioni? In caso affermativo, come posso reimplementare gli oggetti del database.

In questo momento vedo questi passaggi per fare questo:

  • analisi della struttura dei dati di origine (dati propri)
  • analisi di tutti i sistemi esterni (quali formati deve fornire il database)
  • viste, funzioni, stored procs separati per ogni sottosistema esterno (devo evitare catene lunghe, comuni a molti oggetti del sottosistema DB, se è una causa di problemi)
posta Zzz 20.01.2011 - 11:42
fonte

2 risposte

4

Hai invece considerato la possibilità di creare un datamart ? Forse è quello che ha già fatto il tuo collega?

Dipende molto dal tuo caso specifico, ma capisco che non puoi descrivere la tua attività nella tua domanda.

Se sei serio su questo, ti raccomando questo bel libro che descrive non solo come farlo, ma spiega in profondità tutti i problemi che potresti incontrare in tali situazioni.

Il toolkit del data warehouse

Guardaaltri libri di Ralph Kimball .

    
risposta data 20.01.2011 - 11:52
fonte
1

Penso che l'ex dipendente stia cercando di creare una vista logica sui dati che è separata dalla rappresentazione fisica.

Quando i client sono collegati alle viste e / o alle stored procedure, hai spazio per il refactoring della rappresentazione fisica senza che i client richiedano alcuna modifica.

Naturalmente questo livello logico aggiunge un po 'di indirezione e può costare un tempo di elaborazione extra. Tuttavia, questo potrebbe comunque essere utile dal punto di vista della manutenibilità. Essere in grado di destreggiarsi con tabelle e relazioni al di sotto di questo livello logico può anche aiutare quando si affrontano problemi di prestazioni.

A volte essere più lenti non è necessariamente un problema, è ancora abbastanza veloce?

    
risposta data 21.01.2011 - 19:50
fonte

Leggi altre domande sui tag