2016-04-25 4 views
0

Auf das Risiko der getaggt werden doppelte, hier geht.Firebase Datenmodellierung Anleitung

Ich habe Artikel und Tags. Elemente können viele Tags haben und jedes Tag kann ein Kind-Tag eines anderen Tags sein.

Ich möchte Tags als Baum und Elemente in jedem Tag auflisten.

Im Wesentlichen ist ein Tag ein Ordner für Objekte, mit der Ausnahme, dass ein Objekt an mehreren Orten sein kann.

Ist das der richtige Weg?

/items/ 

i123 : { 
    Label : "i am an item", 
    Tags : { tagid: t234} 
} 

/tags/ 

t234 : { 
    Label : "i am a Tag", 
    Parent: {tagid: t567} 
} 

Ich bin ein bisschen unsicher, dass ich das richtig mache. Ich habe natürlich das demoralisierende Dokument und das Tutorial auf Firebase durchgelesen und ich habe mir ähnliche Fragen angesehen.

Ich bin in RDBMS stecken-denke und scheinen nicht in der Lage, die Nosql-Konzepte zu finden, deshalb hoffe ich, hier eine Anleitung für den Anwendungsfall hier zu bekommen.

Danke.

Auf Anfrage von Kommentatoren, weitere Informationen zum Anwendungsfall.

Ich versuche, einen Baum von Tags wie dieser auch

I am tag One 
I am second tag 
    this is a child tag 
     here is a child's child tag 
    another child tag 
I am a root level tag again 
// etc... you get the idea 

Es gibt Elemente, anzuzeigen und Elemente in mehreren Tags werden kann. Die Anzeige ist hier genau so wie in einem Dateibrowser. Außer hier können Elemente an mehreren Stellen angeordnet sein, d. H. Sie können mehreren zugeordneten Tags zugeordnet sein.

wie in diesem Beispiel, wo item 334 an mehreren Stellen sitzt:

tag 1 
item 209 
tag 2 
    tag 21 
    item 11 
    item 334 
tag 3 
item 334 
item 586 

Gerade jetzt, ich glaube, ich könnte die ganze Sache in einem JSON-Objekt nur speichern und zu aktualisieren, wie gebraucht, aber ich bin interessiert an Suchbar sowohl nach Tag als auch nach Artikelbezeichnung. In meinem schwachen Neuling denke ich, dass ich in der Lage sein sollte, eine URL /tags/ zu haben, die ich durchqueren kann, um Artikel zu erhalten, die den Tags entsprechen. Dito für /items/, also kann ich eine Schlüsselwortübereinstimmung auf den Aufklebern tun.

Andere Antworten auf SO beschreiben Möglichkeiten zum Erstellen von Indizes für Dinge, deshalb speichere ich Tag-Referenzen in meinem Artikelobjekt. Ich kämpfe mit den Details darum herum.

Je mehr ich darüber nachdenke, desto eher bin ich geneigt, einfach alles in einem großen verschachtelten Objekt zu speichern, aber ich denke, das sollte keine gute Idee sein. Vor allem mag ich die Idee nicht, dass ein Artikel mehrfach gespeichert wird.

Das Leben war einfacher in RDB Welt, weil ich wusste, was ich tat: P

+0

Der richtige Weg, um Ihre Daten zu modellieren, hängt davon ab, wie Ihre App diese Daten verbrauchen muss. Wir können das nicht für Sie beantworten, obwohl wir Ihnen bei einer spezifischen Anfrage helfen können. Abgesehen davon empfehle ich diesen Artikel zu [NoSQL Data Modeling] (https://highlyscalable.wordpress.com/2012/03/01/nosql-data-modeling-techniques/) zu lesen. –

+0

Danke für den Link. Ich dachte, ich wäre ziemlich klar in meiner Beschreibung, wie es Daten verbrauchen wird. – tim

Antwort

2

Diese Struktur erfüllt die Kriterien Ihrer Frage, aber es gibt wirklich keine Informationen in der Frage zusammen, um eine solide Antwort zu setzen.

items 
item_00 
    tag_00 
    tag_01 
    tag_02 
item_01 
    tag_02 
item_02 
    tag_01 

tags 
tag_00 
    parent: false 
    child: tag_01 
tag_01 
    parent: tag_00 
    child: false 
tag_02 
    parent: false 
    child: false 

In diesem Beispiel

  • Artikel ein Kind von einem anderen Tag (und die Eltern: Kind-Beziehung verfolgt wird) sein kann viele Tags
  • jeden Tag haben kann
  • die Tags aufgeführt als Baum
  • Elemente innerhalb jeden Tages können durch Abfragen der Elemente für den Tag Nummer
0 gefunden werden

Aktualisieren Sie die Frage mit mehr Daten und ich (wir) können die Antwort verfeinern)

+0

Danke, dass du dir die Zeit genommen hast, das zu beantworten. Ich muss darüber nachdenken, wie man am besten fragt. Ich möchte die Frage nicht mit unnötigen Details belasten. – tim