Ho due modelli nella mia applicazione, Transazione e Persona, con una relazione molti-a-molti. Ci sono persone incluse in ogni Transazione. Per ogni persona, c'è anche una somma collegata a ciascuna Transazione a cui è connessa la Persona. Perciò ho bisogno di modellare una relazione molti-a-molti con i dati di relazione. Google Suggest questo approccio:Modellazione molti-a-molti con dati di relazione in Google App Engine
http://code.google.com/intl/sv-SE/appengine/articles/modeling.html
Con questo approccio ho un modello come questo:
class TransactionPerson(db.Model):
# References
transaction = db.ReferenceProperty(Transaction, required=True)
person = db.ReferenceProperty(Person, required=True)
# Values
amount = db.FloatProperty(required=True)
Ma trovo che molto male per le prestazioni, perché se ho bisogno di riassumere la quantità per ogni persona in tutte le Transazioni ho bisogno di ciclizzare Persona * Transazione * TransactionPerson volte per implementare il "join" mentre sommando gli importi.
mia idea
La mia idea è quella di avere due liste nel modello di transazione:
class Transaction(db.Model):
persons = ListProperty(db.Key)
persons_amount = ListProperty(float)
In questo modo non ho bisogno di ciclo di tutti TransactionPerson per ogni persona di trovare la associato Transazione. E posso ancora interrogare le transazioni in base a una persona.
DOMANDE
- è possibile? Puoi fidarti del fatto che l'ordine delle liste è sempre lo stesso quando si memorizza/rientra e quindi gli indici si sincronizzano tra gli elenchi?
- È un buon modo per implementare la relazione molti-a-molti con i dati associati?
Ma perché l'ente di un'associazione intermedia è un buon approccio quando causerà operazioni meno efficienti? Ad esempio con il tuo approccio; se una Transazione viene aggiornata, spesso devo aggiornare tutti gli oggetti Person associati alla Transazione. Non ne ho bisogno se utilizzo il mio approccio? Quali sono le ragioni per cui è meglio utilizzare un'entità di associazione? – thejaz
O potrebbe essere la scelta migliore per quello che stai facendo, ma la mia risposta si concentra sulla specifica questione del calcolo dei dati di riepilogo. Se devi caricare più di una manciata di entità per soddisfare una particolare richiesta, probabilmente devi trovare un modo per estrarre quel processo dalla richiesta e crearlo in un altro modo, come quando il valore cambierebbe. – SingleNegationElimination
I dati di riepilogo erano solo un esempio. Spesso desidero ottenere tutte le persone in una Transazione che nella pratica si traduca nella stessa Persona * Transazione * TransactionPerson cicli che non devono essere accettabili per quanto riguarda le prestazioni, anche se lo faccio più raramente (quando aggiungo o modifica un TransactionPerson). Anche se dovessi memorizzare nella cache i dati (una lista di persone) sulla Transazione, sarebbe lo stesso di quello che ho suggerito nella mia domanda, ma con l'aggiunta di avere anche i dati della relazione in una lista. Non porterebbe a dati duplicati. Come lo faresti? – thejaz