Πώς σχεδιάζετε σχήματα στο MongoDB;

Question

Accepted Answer

Ο σχεδιασμός σχήματος στο MongoDB επικεντρώνεται σε μια βασική απόφαση: **embedding** (αποθήκευση συσχετιζόμενων δεδομένων μέσα σε ένα document) έναντι **referencing** (αποθήκευση συσχετιζόμενων δεδομένων σε ξεχωριστά documents/collections με αναφορές). Σε αντίθεση με το normalize-by-default της SQL, ο σχεδιασμός στο MongoDB βελτιστοποιεί τον τρόπο με τον οποίο τα δεδομένα *προσπελαύνονται*.

## Embedding — αποθήκευση συσχετιζόμενων δεδομένων μαζί

```js
// embed related data within the document
{
  _id: ObjectId("..."),
  name: "Ann",
  address: { city: "NY", zip: "10001" },        // embedded sub-document
  orders: [                                      // embedded array of orders
    { product: "Phone", amount: 999 },
    { product: "Case", amount: 20 }
  ]
}
// → ONE query gets the user AND their address AND orders (no joins)
```

**Embedding** κρατά συσχετιζόμενα δεδομένα σε ένα document — διαβάστε τα όλα σε ένα ερώτημα (γρήγορο, χωρίς joins). Κατάλληλο για δεδομένα που προσπελαύνονται μαζί και σχέσεις "περιέχει".

## Referencing — σύνδεση ξεχωριστών documents

```js
// store a reference (id) to a document in another collection
{ _id: ObjectId("u1"), name: "Ann" }                          // users collection
{ _id: ObjectId("o1"), userId: ObjectId("u1"), product: "Phone" } // orders collection
// → query orders by userId; use $lookup to join when needed
```

**Referencing** αποθηκεύει δεδομένα ξεχωριστά και συνδέει με id (όπως ένα ξένο κλειδί) — ερώτημα ξεχωριστά ή join με `$lookup`.

## Πότε να κάνετε embed έναντι reference

```text
EMBED when:
  ✓ data is accessed TOGETHER (read the parent → you want the children)
  ✓ a "contains"/ownership relationship (address, order line items)
  ✓ the embedded data is bounded (not unboundedly growing)
  ✓ one-to-few relationships

REFERENCE when:
  ✓ data is large or grows UNBOUNDEDLY (avoid huge documents — 16MB doc limit!)
  ✓ data is accessed/updated INDEPENDENTLY
  ✓ many-to-many or one-to-many with many
  ✓ the same data is shared/referenced by many documents (avoid duplication)
```

## Σχεδιάστε για μοτίβα πρόσβασης (η βασική αρχή)

```text
MongoDB schema design is driven by HOW YOU QUERY the data, not pure normalization:
  → Structure data so common queries are efficient (often a single document read).
  → "Data that is accessed together should be stored together."
  → This may mean DENORMALIZING (some duplication) for read efficiency — acceptable
    in MongoDB, traded against update complexity.
```

## Γιατί έχει σημασία

Ο σχεδιασμός σχήματος είναι κρίσιμης σημασίας στο MongoDB — είναι διαφορετικός από και ισχυρίζεται ότι πιο σημαντικός από ό,τι στο SQL, επειδή το ευέλικτο μοντέλο document του MongoDB σας δίνει επιλογές που επηρεάζουν σημαντικά την απόδοση και τη δυνατότητα συντήρησης, οπότε η κατανόησή του είναι απαραίτητη για την κατασκευή αποτελεσματικών εφαρμογών MongoDB.

Η κεντρική απόφαση — **embedding έναντι referencing** — είναι η καθοριστική επιλογή σχεδιασμού MongoDB: **embedding** (αποθήκευση συσχετιζόμενων δεδομένων μέσα σε ένα document) επιτρέπει γρήγορες ενιαίες ερωτήσεις ανάγνωσης συσχετιζόμενων δεδομένων (χωρίς joins) και ταιριάζει με δεδομένα που προσπελαύνονται μαζί και σχέσεις "περιέχει", ενώ **referencing** (σύνδεση ξεχωριστών documents με id) ταιριάζει με μεγάλα/απεριόριστα δεδομένα, ανεξάρτητα προσπελάσιμα δεδομένα και κοινές/πολλαπλές σχέσεις.

Η κατανόηση **πότε να χρησιμοποιήσετε το καθένα** (embed για δεδομένα που είναι περιορισμένα, προσπελάσιμα μαζί, κατοχύομενα· reference για μεγάλα/αναπτυσσόμενα, ανεξάρτητα, κοινά ή πολλαπλά δεδομένα — και να είστε προσεκτικοί με το όριο μεγέθους document 16MB του MongoDB) είναι η βασική δεξιότητα.

Το πιο σημαντικό, η κατανόηση της καθοδηγητικής αρχής — **σχεδιάστε για μοτίβα πρόσβασης** (δομήστε δεδομένα γύρω από *τον τρόπο με τον οποίο τα ερωτάτε*, ώστε τα συνηθισμένα ερωτήματα να είναι αποδοτικά, συχνά μια ενιαία ανάγνωση document, αντί να κανονικοποιείτε ως προεπιλογή όπως στο SQL) — είναι αυτό που διακρίνει τον καλό σχεδιασμό σχήματος MongoDB.

Αυτό μπορεί να σημαίνει αποδοχή κάποιας **αποκανονικοποίησης** (διπλοτυπίας) για απόδοση ανάγνωσης, ένας συμβιβασμός έναντι της πολυπλοκότητας ενημέρωσης που είναι αποδεκτός και συχνά σωστός στο MongoDB.

Επειδή ο σχεδιασμός σχήματος επηρεάζει βαθιά την απόδοση και τη δυνατότητα συντήρησης εφαρμογών MongoDB (μια κακή επιλογή embed/reference προκαλεί αργές ερωτήσεις, τεράστια documents ή πολυπλοκότητα ενημέρωσης), και επειδή η προσέγγιση driven-by-access-patterns, embed-vs-reference είναι θεμελιακά διαφορετική από τη κανονικοποίηση SQL, η κατανόηση του σχεδιασμού σχήματος MongoDB — η απόφαση embed/reference, πότε να χρησιμοποιήσετε καθένα, και σχεδιασμός για μοτίβα πρόσβασης — είναι απαραίτητη, γνώση υψηλής αξίας για την κατασκευή αποτελεσματικών εφαρμογών MongoDB, ένα από τα πιο σημαντικά και διακριτικά θέματα MongoDB που χωρίζει αυτούς που σχεδιάζουν καλά σχήματα document από αυτούς που αφελώς μεταφέρουν σχεσιακά σχέδια.