2016-08-07 41 views
2

Angenommen, ich möchte eine Blog-App schreiben. Sollte ich eine der folgenden zwei Optionen bevorzugen? Ich würde es vorziehen, so viel "einzige Quelle der Wahrheit" wie möglich zu haben, aber ich bin mir immer noch nicht sicher, ob diese Präferenz von meinem Hintergrund in SQL kommt.Firebase (NoSQL): Denormalisierung vs Indexierung

Option 1 (Denormalisierung):

Posts: { 
    post_1: { 
    title: "hello", 
    body: "hi there!", 
    uid: "user_1", 
    comments: { 
     comment_1: { 
     body: "hi I commented", 
     uid: "user_2", 
     }, 
     comment_2: { 
     body: "bye I commented", 
     uid: "user_2", 
     }, 
    } 
    } 
} 

Users: { 
    user_1: { 
    uid: "user_1", 
    post_1: { 
     title: "hello", 
     body: "hi there!", 
     uid: "user_1", 
     comments: { 
     comment_1: { 
      body: "hi I commented", 
      uid: "user_2", 
     }, 
     comment_2: { 
      body: "bye I commented", 
      uid: "user_2", 
     }, 
     } 
    } 
    } 
} 

Option 2 (Indexierung):

Posts: { 
    post_1: { 
    title: "hello", 
    body: "hi there!", 
    uid: "user_1", 
    authorName: "Richard", 
    comments: { 
     comment_1: true, 
     comment_2: true 
    } 
    } 
} 

Users: { 
    user_1: { 
    uid: "user_1", 
    displayName: "Richard", 
    email: "[email protected]", 
    posts: { 
     post_1: true 
    }, 
    comments: { 
     comment_1: true, 
     comment_2: true 
    } 
    } 
} 

Comments: { 
    comment_1: { 
    body: "hi I commented", 
    uid: "user_1", 
    }, 
    comment_2: { 
    body: "bye I commented", 
    uid: "user_1", 
    }, 
} 

ich glaube, ich Option 2.

Das Hauptproblem, das ich sehe, lieber sollte Bei Option 1 gibt es zu viele Quellen für eine Datenquelle. Nehmen wir an, ich möchte die App so erweitern, dass jeder Beitrag zu einer bestimmten Kategorie oder einem bestimmten Tag gehört. Dann muss ich ein post Objekt unter /categories/category_id zusätzlich zu /posts und /users/uid schreiben. Wenn der Post aktualisiert wird, muss ich daran denken, das Objekt post an drei verschiedenen Stellen zu ändern. Wenn ich mit Option 2 gehe, habe ich dieses Problem nicht, da es nur eine Quelle für Daten gibt.

Fehle ich etwas?

Referenzen:

  1. Firebase data structure and url
  2. https://firebase.google.com/docs/database/web/structure-data
+0

Wenn Sie die zweite Option mögen, warum überhaupt NoSQL? Gehen Sie einfach mit SQL ... – obe

+0

Ich möchte Firebase für mein Backend versuchen. Außerdem möchte ich lernen, ob ich Option 1 zu Option 2 in NoSQL vorziehen sollte. Diese (https://firebase.google.com/docs/database/web/structure-data) sagt Option 2 ist besser, aber viele Beiträge schlagen auch vor, Option 1 zu tun. –

+0

Nun, Disclaimer-weise, habe ich nicht praktische Erfahrungen mit NoSQL als primärem Backend. Ich mag altmodisch sein, aber ich mag es, wenn möglich Daten zu normalisieren. Es ist in Ordnung, die Regeln zu beugen und einige Doppelzüngigkeit für erhebliche Leistung oder Einfachheit Gewinne, aber in den meisten Fällen denke ich, dass für komplexe relationale Daten die beste Wahl ist eine relationale Datenbank (möglicherweise mit NoSQL als Cache-Tier). Ich bin mir bewusst, dass ich Ihre Frage nicht beantworte, aber deshalb schreibe ich einen Kommentar statt einer Antwort :) – obe

Antwort

-1

Die zweite Option ist besser denn sonst würden Sie den Benutzer werden gezwungen, alle Kommentare und Beiträge zum Download (das viel sein kann) .

Sie können in der Dokumentation here einchecken.

Und Sie können die Duplizierung tun atomic writes across multiple locations.

+0

Diese Antwort ist sinnvoll für dieses Beispiel, aber ich würde gerne einige Kommentare zu Beispielen sehen, die nicht das Problem haben, wie "Kommentare" und "Beiträge", d. H. Daten, die nicht viel wachsen werden. Wäre es akzeptabel, "indexOn" für Werte festzulegen, die nicht skaliert werden? –

+0

Ist die Antwort falsch? –