Recuperare e aggregare dati da database: miglior metodo

[aasmdaa]

Ciao a tutti,
pongo la questione utilizzando un esempio così dovrebbe risultare più chiaro:
su una web applicatione devo visualizzare 100 fatture visualizzando sia la testata che le varie righe della fattura.
Va da sè quindi che nel database avrò 2 tabelle:

fatture_testata (PK fatturaID)
fatture_dettaglio (ogni riga avrà la FK fatturaID)

Il dubbio rimane su quale sia la modalità più usata / più corretta per recuperare i dati dal punto di vista del design applicativo per cui vorrei un confronto con voi.
Ecco le 3 opzioni (se ce ne sono altre ben vengano):

1) nel modello recupero tutti i dati dal database facendo una join tra fatture_testata e fatture_dettaglio.
In questo modo ottengo un unico oggetto da restituire che però contiene tutte le righe di testata ripetute e sarà poi premura della vista andare a splittare testata e dettaglio

2) nel modello recupero tutti i dati da fatture_testata, li scorro e ci inserisco un nuovo campo (dettaglio).
In questo modo avrò un oggetto con tutte le righe di testata e che avrà un oggetto collegato alla riga contenente le righe di fattura.
Molto più comodo per la vista però ho già iterato sull'array e per ogni riga ho effettuato un'altra richiesta al database.

3) nel modello creo una query con una subquery tale che associ ad ogni riga si testata le righe di dettaglio.
In questo modo (credo) che comunque venga fatta un'unica lettura al db da parte dell'applicativo e mi ritrovo già con l'oggetto ben "formato" per la vista.

Ho fatto alcune prove con i 3 metodi e i tempi sono molto vicini così come il peso dell'oggetto finale (ovviamente dipende dalla quantità).

Voi quale metodo usate?

grazie
ciao

[Scara95]

Il motore SQL è lì per essere usato.

[aasmdaa]

Il motore SQL è lì per essere usato.

Puoi argomentare perchè così non mi è chiaro cosa vuoi dire.

[Scara95]

La soluzione è ovvia, specie in questo caso: è inutile reinventare la ruota, specie in questo caso dove sicuramente sono stati spesi anni di sviluppo nell'ottimizzazione dell'engine del database che risolve perfettamente il tuo problema ed è fatto apposta per risolvere quello specifico problema!

[aasmdaa]

Probabilmente non mi sono spiegato bene, anche se avevo chiarito nel primo posto: "...modalità più usata / più corretta per recuperare i dati dal punto di vista del design applicativo...".

Non sto cercando una soluzione del problema specifico ma ho usato un esempio esplicativo.
La soluzione non mi sembra per nulla ovvia soprattutto in considerazione di pattern MVC e del corretto utilizzo del Model senza contare il layer di astrazione per il database.

Nello specifico la mia domanda si riferisce a:
- considerando che per il pattern MVC si dovrebbe spostare tutta la business logic nel Model avrebbe più senso ad esempio fare tutti i calcoli dei campi nel Model e inviarli alla View in modo da centralizzarli in un posto unico (ad es. i subtotali delle righe ecc.) senza doverli ripetere in ogni View? Questo diminuirebbe il lavoro per il team di sviluppo della View (che non devono nemmeno fare calcoli ma solo presentare la variabile finita) e i rischi di errore non dovendo ripetere le medesime formule oltre il vantaggio ovviamente di modificarle in un unico punto.
- Il fatto di utilizzare comandi specifici del database (ad es. MySQL) per effettuare questi calcoli (DATE_FORMAT, CONCAT_WS, ecc.) o la trasformazione delle date ti lega al database specifico. Utilizzando invece metodi del framework (ad es. Zend Framework) separi nettamente quelli che sono metodi specifici del motore database da quelli che sono specifici della web application. Questo ti permette in qualsiasi momento di migrare la piattaforma su un motore database diverso senza rifare l'intero lavoro (pensiamo ad esempio a 100 modelli).

Ad esempio in una web application con oltre 60 modelli ho usato proprio questa tecnica: leggo dal database i dati che mi servono, li scorro e tramite i metodi del framework calcolo e inietto nell'array di risposta i dati aggiuntivi e lo restituisco.
Si è rivelato un buon metodo in quanto gli sviluppatori delle Viste hanno apprezzato il fatto di non dover ripetere calcoli/operazioni e siamo passati da un db all'altro con il minimo intervento.

Ora spero di essermi spiegato meglio per cui ritengo che la risposta non sia così scontata ma anzi merita un confronto con altri sviluppatori di web applications di livello enterprise.