Quale modello risolverà questo - recuperando il record dipendente dal database

Question

Quale modello risolverà questo - recuperando il record dipendente dal database

#1 da (2 voti)
#2 da (1 voti)
#3 da (1 voti)

3

Ho queste classi

class Match
{
  int MatchID,
  int Team1ID, //used to reference Team
  int Team2ID,
  ... other fields
}

Nota: la partita ha in realtà 2 squadre che significano 2 TeamID

class Team
{
   int TeamID,
   string TeamName
}

Dal mio punto di vista ho bisogno di mostrare List<Match> che mostra TeamName. Così ho aggiunto un altro campo

class Match
{
  int MatchID,
  int TeamID, //used to reference Team
  ... other fields

  string TeamName;
}

Ora posso fare

Match m = getMatch(id);
m.TeamName = getTeamName(m.TeamId); //get name from database

Ma per un List<Match> , getTeamName(TeamId) andrà al database per recuperare TeamName per ogni TeamID.

Per una pagina di 10 risultati per pagina, che potrebbe essere (10x2Teams)=20 di viaggio nel database. Esempio:

for(1..10)
{
   Match m[i] = getMatch(i);

   //the team are never going to be repeated, 20 teams spread over ten matches 
   m[i].Team1Name = getTeamName(m.Team2Id);
   m[i].Team2Name = getTeamName(m.Team2Id);
}

Per evitare questo, ho avuto l'idea di caricare tutto una volta, memorizzarlo in memoria e cercare solo il TeamName in memoria. Questo mi ha fatto ripensare a cosa succederebbe se i record fossero 5000 o più.

Quale modello è usato per risolvere questo e come?

programming-practices

posta tunmise fasipe 28.08.2012 - 01:13

fonte

3 risposte

2

Ci sono diversi modi per ottimizzare ciò che stai facendo:

Query per molti , non fare un select * from teams where id = ? , fai un select * from teams where id in (?) . L'implementazione del metodo predefinito riceve un elenco e fa il successivo, il metodo sovraccarico per un singolo ID trasforma l'id in un elenco di dimensione 1 e chiama il metodo che accetta l'elenco come parametro. Dal modo in cui lo vedo, stai facendo l'inverso.
Potresti non averne mai bisogno TUTTO , lo hai detto tu stesso, usi la paginazione, quindi il massimo possibile è definito dalla dimensione massima della pagina che hai.
Ma ... se devi richiedere che molti prendi in considerazione un modello di peso vivo , in cui puoi archiviare i dati in una struttura casuale di dati a tua scelta e utilizzare un singolo oggetto per accedere ai dati con la stessa interfaccia che utilizzeresti con N oggetti.
Utilizza un modello , ricorda che Model in MVC (se stai utilizzando MVC) non supporta database, ma solo dati. Un modello può fungere da facciata per le query più complesse ed evitare inutili sofferenze nei controller (vedere "> fat skinny controller "

risposta data 28.08.2012 - 10:52

fonte

1

Penso che il tuo problema non debba essere risolto da uno schema specifico, ma dal design del software stesso.

Ci sono molte cose che possono essere fatte, se ti stai connettendo direttamente a un database relazionale, puoi recuperare i dati in una singola query, usando i join e nel codice associare i dati dove vuoi. Puoi anche farlo in due viaggi e cercare gli oggetti già caricati in memoria. O anche usare qualcosa come NHibernate, tutto dipende dal design e dall'architettura del tuo software.

Riguardo al problema con molti record, dove devi usare questi dati? Potrebbe probabilmente essere paginato o filtrato e potresti caricarlo in blocchi dall'archivio dati.

In situazioni come questa dovresti cercare nel complesso il tuo progetto e vedere come sono state gestite situazioni come questa, e provare a seguire lo stesso schema, migliorando così la manutenibilità del codice

risposta data 28.08.2012 - 02:01

fonte

Leggi altre domande sui tag programming-practices

Numeri di porta in progetti di Visual Studio e IIS Dove collocare la convalida personalizzata durante l'utilizzo di Entity Framework

score 1 · Accepted Answer

Prima di tutto ... sembra che tu stia cercando di risolvere un problema che non sai di avere. A meno che non si sappia per certo che colpire il database 20 volte per pagina (che non è nulla) sarà un problema, attenersi a ciò che si ha per ora e affrontarlo quando diventa effettivamente un problema.

Detto questo ... un paio di approcci:

In SQL, puoi fare qualcosa di simile:

select name from teams where id in (10, 15,....)

Anche se lo fai una volta per partita, questo è di 10 viaggi per il db, non per 20. Che è sufficiente tagliarlo a metà.

In alternativa - ed è qui che le astrazioni possono morderti - ripensare a ciò che stai facendo. Anziché caricare oggetti e interrogare i nomi dei team, creare una singola query che generi tutte / la maggior parte delle informazioni necessarie per elencare tutto sulla pagina che si sta visualizzando (almeno per quanto riguarda le informazioni sulla corrispondenza). Con un po 'di SQL elegante, puoi probabilmente ridurre l'intera operazione a una singola query che restituisce 10 righe (una per corrispondenza).