Domanda

In passato abbiamo usato per accedere al database tramite stored procedure. Sono stati visti come `il 'modo migliore di gestire i dati. Manteniamo i dati nel database, e qualsiasi linguaggio / piattaforma può accedervi tramite JDBC / ODBC / etc.

meccanismi di recupero stoccaggio Tuttavia, negli ultimi anni sulla base di run-time di riflessione / meta-dati, come Hibernate / DataNucleus sono diventati popolari. Inizialmente eravamo preoccupati che sarebbero lento a causa dei passaggi aggiuntivi coinvolti (riflessione è costoso) e come recuperare i dati non necessari (l'intero oggetto) quando tutto quello che serve è un campo.

sto iniziando a pianificare per un grande progetto di data warehousing che utilizza J2EE, ma io sono un po 'incerto se andare per le stored procedure o JDO / JPA e simili. Recentemente, ho lavorato con Hibernate, e ad essere onesti, non mi manca la scrittura procedure CRUD memorizzato!

Si riduce essenzialmente a:

Le stored procedure
+ Può essere ottimizzato sul server (anche se solo le query)
. - Ci sono probabilmente più di un migliaio di stored procedure: aggiungere, cancellare, aggiornare, getById, ecc, per ogni tabella

JDO
+ Non voglio spendere i prossimi mesi la scrittura parameters.add ( "@ firstnames", customer.getFirstName ()); ...
- sarà più lenta del SP (ma la maggior parte di supporto di paging)

Cosa vorresti grassoccio per nella mia situazione. In questo caso penso che sia un gran muchness.

Grazie,

Giovanni

Nessuna soluzione corretta

Altri suggerimenti

"JDO - sarà più lenta del SP (ma la maggior parte di supporto paging)"

Questa ipotesi è spesso falsa. Non c'è alcun motivo per SP di essere particolarmente veloce. Ho fatto alcune misurazioni e non più velocemente rispetto al codice stanno al di fuori del database.

Un data warehouse è caratterizzato da carichi insert-only e le query SELECT...GROUP BY... lunga esecuzione.

Non stai scrivendo OLTP elaborazione transazionale. Tu non stai usando 3NF come un modo per prevenire anomalie aggiornamento sulla aggiornamento / transazioni di eliminazione.

Dal momento che si sta facendo inserimenti di massa, un SP sarà sicuramente più lento di un programma di utilità di caricamento di massa. caricatori di massa sono spesso multi-threaded e consumerà tutte le risorse della CPU disponibili. La SP è parte della DB e può solo condividere risorse DB limitate.

Dato che si sta per lo più facendo SELECT GROUP BY, un SP non aiuterà molto qui, neanche. L'istruzione SELECT non beneficia di essere avvolto in una procedura.

Non hai bisogno di loro. Essi non aiutano.

Si può facilmente punto di riferimento di una massa a vuoto e una query per dimostrare che SP di non stanno aiutando.

Rod Johnson nel suo "J2EE design adn Sviluppo" ha scritto una chiara analisi su ORM / StoredProcedures. Egli ha detto che

  

Le stored procedure deve essere utilizzato solo in un sistema J2EE per eseguire le operazioni che sarà sempre utilizzare il database pesantemente, se sono implementate nel database o nel codice Java che scambia un sacco di dati con il database.

Come hai intenzione di implementare un datawarehouse, penso che l'approccio stored procedure è la scelta giusta.

Io suggerirei di usare i metadati per generare gli script che si utilizza per il caricamento nel data warehouse. Questo consente di ottenere vantaggi di prestazioni di utilizzare strumenti di carico specializzati e forse da stored procedure (se si sta utilizzando un sufficientemente antica database). Inoltre, è probabile che finirà per codifica manuale almeno un po 'di SQL. Avere i vostri script generici fatto come stored procedure vi permetterà di programmare tutti allo stesso modo e non devono preoccuparsi di cambiare il modo in cui vengono richiamati quando si riscrivono un codice generato per farlo funzionare meglio.

Per quanto riguarda ottenere i dati fuori, se quello che si sta costruendo in J2EE è uno strumento di reporting, allora si può essere meglio utilizzare JDO. Mentre io non sono terribilmente familiarità con il lato segnalazione delle cose, uno dei vantaggi che posso vedere è che sarà più facile per consentire agli utenti finali di effettuare report personalizzati che non hai anticipare in anticipo (anche se avete ancora avuto modo di avere alcuni limiti su ciò che possono fare in modo che essi non prendono il database nel processo).

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top