2008-11-20 8 views
8

Mi chiedo se qualcuno possa fornire alcuni consigli concettuali su un modo efficiente per creare un modello di dati per realizzare il semplice sistema descritto di seguito. Sono un po 'nuovo a pensare in modo non relazionale e voglio provare a evitare qualsiasi insidia evidente. A mio avviso, un principio fondamentale è che "lo storage è economico, non preoccuparti della duplicazione dei dati", come potresti fare con un RDBMS normalizzato.Consigli per la modellazione dei dati per il sistema di tagging blog su Google App Engine

Quello che mi piacerebbe modello è:

Un blog articolo che può essere dato 0-n tag. Molti articoli del blog possono condividere lo stesso tag. Quando si recuperano dati si desidera consentire il recupero di tutti gli articoli che corrispondono a un tag. In molti modi molto simile all'approccio adottato qui in StackOverflow.

La mia mentalità normale sarebbe quella di creare una relazione molti-a-maggio tra tag e articoli di blog. Tuttavia, sto pensando nel contesto di GAE che questo sarebbe costoso, anche se ho visto esempi di ciò che è stato fatto.

Forse utilizzando una ListProperty contenente ogni tag come parte delle entità dell'articolo e un secondo modello di dati per tenere traccia dei tag man mano che vengono aggiunti ed eliminati? In questo modo non c'è bisogno di alcuna relazione e ListProperty consente comunque query in cui qualsiasi corrispondenza dell'elemento di lista restituirà risultati.

Qualche suggerimento sul modo più efficiente per avvicinarsi a questo su GAE?

risposta

7

Grazie a entrambi per i vostri suggerimenti. Ho implementato (prima iterazione) come segue. Non sono sicuro che sia l'approccio migliore, ma funziona.

Classe A = Articoli. Ha una proprietà StringList che può essere interrogata sugli elementi della lista

Classe B = tag. Un'entità per tag, mantiene anche un conteggio progressivo del numero totale di articoli utilizzando ogni tag.

Le modifiche dei dati ad A sono accompagnate da lavori di manutenzione su B. Pensare che il conteggio sia precalcolato è un buon approccio in un ambiente di lettura intensa.

+0

Solo l'approccio che stavo per suggerire, tranne che non ho trovato il tempo. :) –

1

Suoni molti-a-molti ragionevoli. Forse dovresti provarlo prima per vedere se è effettivamente costoso.

Buona cosa su G.A.E. è che ti dirà quando stai usando troppi cicli. Profilazione gratis!

+0

Stavo pensando molti-a-molti troppo, ma anche la documentazione di Google mette in guardia contro questo in tutti, ma le situazioni più necessarie. Un buon consiglio pensato sulla profilazione, penso che proverò a fare alcuni test usando approcci diversi e riporterò i risultati qui. – Matty

1

Un modo possibile è con Expando, dove ci si aggiunge un tag come:

setattr(entity, 'tag_'+tag_name, True) 

Poi si potrebbe interrogare tutte le entità con un tag come:

def get_all_with_tag(model_class, tag): 
    return model_class.all().filter('tag_%s =' % tag, True) 

Naturalmente è necessario per ripulire i tuoi tag come identificatori Python corretti. Non ho provato questo, quindi non sono sicuro se sia davvero una buona soluzione.

+1

Cosa succede se i nomi dei tag non devono essere in inglese? –

2

conteggi pre-calcolati è non solo pratico , ma anche necessario perché la funzione count() restituisce un massimo di 1000 . se la controversia sulla scrittura potrebbe essere un problema, assicurati di controllare l'esempio di contatore con caratteri grigi.

http://code.google.com/appengine/articles/sharding_counters.html

+0

Nelle versioni più recenti di gae sdk la funzione count() non ha limiti massimi: http://code.google.com/appengine/docs/python/datastore/queryclass.html#Query_count –

+0

true! editerà. – mainsocial

Problemi correlati