Soluzioni per il recupero ORM parziale

Question

Soluzioni per il recupero ORM parziale

#1 da (1 voti)
#2 da (0 voti)

2

Ho letto la seguente domanda riguardante se è meglio usare oggetti con membri di dati completamente o parzialmente popolati. I 3 suggerimenti erano:

che forse utilizzando un modello ORM completamente popolato potrebbe non avere un sovraccarico come ci si potrebbe aspettare (test requried);
è stato utilizzato un modello errato se solo un numero limitato di elementi veniva popolato e;
usa una funzione 'lite' o un'intera classe / modello per accedere alle informazioni necessarie.

Non riesco a capire se la seguente soluzione utilizza il secondo o il terzo suggerimento o, più probabilmente, neanche:

Esempio / Soluzione: utilizzo di una tabella per le informazioni dell'utente, in cui ogni riga è un utente e memorizza le informazioni utente. Per la maggior parte delle visualizzazioni di pagina, sono necessarie solo 3 colonne su 12 per personalizzare la pagina per l'utente. Ha senso copiare queste informazioni in un'altra tabella che contiene altre informazioni rilevanti sulla sessione ed è anche accessibile durante ogni pageload? In questo caso, vi è la duplicazione dei dati, ma per la maggior parte delle attività viene recuperata una singola riga con tutte le informazioni pertinenti. Alla fine della sessione, questa riga viene rimossa.

web-development performance orm

posta user58446 03.01.2015 - 13:46

fonte

2 risposte

Leggi altre domande sui tag web-development performance orm

Procedura di sviluppo e commit delle API interne Applicazione del linguaggio di supporto per l'inizializzazione su richiesta a livello di variabili piuttosto che di classe

score 1 · Answer 1

Resisti all'impulso di pre-ottimizzare.

Si dice che per la maggior parte delle visualizzazioni di pagina vengono utilizzate solo le proprietà di un'entitàUser di 3 su 12%. Anche se sono state utilizzate 30 proprietà, è comunque abbastanza leggero. Non impiegherei troppo tempo a preoccuparmi delle perdite di prestazioni a causa della diffusione di dati inutilizzati.

È molto più economico in termini di sforzo di sviluppo (leggi: tempo e denaro) per prendere in considerazione le ottimizzazioni delle prestazioni verso la fine dello sviluppo del prodotto. A quel punto, se ci sono problemi di prestazioni gravi, un profiler li identificherà rapidamente. E con questi dati, puoi prendere una decisione informata su quali problemi di prestazioni affrontare. Sei ROI su dev time vs performance è molto più alta in questo modo.

In alternativa, potresti chiederti perché nella maggior parte dei casi sono richiesti solo un quarto dei campi della tua entità. Potrebbe essere che il tuo modello di dominio sia un po 'troppo rozzo e che suddividere il tuo User in aspetti diversi (sottoentità) abbia senso.

È difficile dirlo senza guardare il tuo codice.

Ad ogni modo, il tema principale di questa risposta è:

Non pre-ottimizzare. Attendi fino a quando non disponi di informazioni sufficienti prima di dedicare grandi sforzi alle prestazioni.

score 0 · Answer 2

In generale, non è opportuno duplicare valori a meno che non vi sia un motivo valido. Per la soluzione di cui sopra, non è sicuramente una buona idea.

Sebbene possa sembrare contro-intuitivo, gli ORM di default (Hibernate) preferiscono caricare e salvare tutti i campi di un'entità (consigliato fino a un limite di ~ 50 colonne). Il motivo principale è che possono preconfigurare questi SQL durante l'avvio e compilare la cache dell'istruzione per ottenere prestazioni migliori.

Se scegli di eseguire un aggiornamento dinamico o di specificare in modo dinamico le colonne specificate dall'utente, ad esempio se stavi implementando il componente server di un'implementazione OData, allora avrebbe senso creare un po 'di ottimizzazione.

Inoltre, se stai guardando una tabella con un numero elevato di colonne. Questo può accadere soprattutto se viene utilizzata la strategia "Tabella per classe gerarchia", quindi è possibile esaminare le query HQL specifiche per selezionare solo le colonne necessarie. JPA 2.1 ha introdotto una funzionalità chiamata Entity graph che affronta questo problema specifico della selezione parziale di un grafo di oggetti.