Implementazione efficace della relazione uno-a-molti con Python NDB

Question

Vorrei sentire la vostra opinione sull'effettiva implementazione della relazione uno-a-molti con NDB Python. (Ad esempio, Persona (uno) -a-Compiti (molti))

A mio parere, ci sono tre modi per implementarlo.

1. Usa 'genitore' argomento
2. Usa 'ripetuta' Proprietà strutturata
3. Usa proprietà Key 'ripetuta'

ho scelto un modo basato sulla logica di sotto di solito, ma Fa senso per te? Se hai una logica migliore, per favore insegnami. è richiesto

1. Usa 'genitore' argomento

   • operazione transazionale tra queste entità è richiesta
   • riferimento bidirezionale tra queste entità
   • Fortemente intenzione rapporto 'padre-figlio'

2. Utilizzare la proprietà strutturata "ripetuta"

   • Non hanno bisogno di usare 'molti' entità singolarmente (sempre, usato con 'un' entità)
   • 'molti' entità si riferisce solo da 'un' entità
   • Numero di 'ripetuti' è a meno di 100

3. usa 'ripetuta' proprietà Key

   • bisogno di usare 'molti' entità singolarmente
   • entità 'molti' può essere definito da altre entità
   • Numero di 'ripetuti' è più di 100

No.2 aumenta la dimensione del soggetto, ma possiamo salvare le operazioni datastore. (Dobbiamo usare la query di proiezione per ridurre il tempo della CPU per la deserializzazione). Pertanto, uso in questo modo il più possibile.

Ho davvero apprezzato la tua opinione.

Answer 1

Una cosa fondamentale che ti manca: come stai leggendo i dati?

Se si visualizzano tutte le attività di una determinata persona su una richiesta, 2 ha senso: è possibile interrogare la persona e mostrare tutte le sue attività.

Tuttavia, se è necessario eseguire una query, è necessario pronunciare un elenco di tutte le attività in un determinato momento, poiché la ricerca di proprietà strutturate ripetute è terribile. Vuoi le singole entità per le tue attività.

C'è una quarta opzione, che consiste nell'utilizzare una proprietà chiave nell'attività che punta alla persona. Quando hai bisogno di un elenco di attività per una persona, puoi inviare una query.

Se è necessario cercare le singole attività, è probabile che si desideri andare al punto # 4. Puoi usarlo anche in combinazione con # 3.

Inoltre, il numero di proprietà ripetute non ha nulla a che fare con 100. Ha tutto a che fare con la dimensione delle entità Persona e Attività e quanto si adatta a 1 MB. Questo è potenzialmente pericoloso, perché se la tua entità Task può essere potenzialmente grande, potresti trovarti a corto di spazio nell'entità Person più velocemente di quanto ti aspetti.

Answer 2

Una cosa che la maggior parte degli utenti GAE realizzerà (prima o poi) è che il datastore non incoraggia la progettazione secondo i principi di normalizzazione formale che sarebbe considerata una buona idea nei database relazionali. Invece spesso sembra incoraggiare il design che è non intuitivo e anatema alle norme stabilite. Sebbene i principi di progettazione dei database relazionali abbiano il loro posto, semplicemente non funzionano qui.

Penso che la base per la progettazione datastore invece si divide in due domande:

1. come faccio a leggere questi dati e come faccio a leggere con il numero minimo di operazioni di lettura?

2. Lo sta archiviando in questo modo causando un'esplosione del numero di operazioni di scrittura e indicizzazione?

Se rispondi a queste due domande con la maggior lungimiranza e test effettivi che puoi, penso che stai andando abbastanza bene. Potresti formalizzare altre regole e casi specifici, ma queste domande funzioneranno per la maggior parte del tempo.