Il modo migliore per strutturare l'allocazione molti-a-uno degli utenti ai progetti in NoSQL

Question

Il modo migliore per strutturare l'allocazione molti-a-uno degli utenti ai progetti in NoSQL

#1 da (0 voti)
#2 da (0 voti)

3

Mi scuso se questa è una domanda un po 'stupida o generica, ma vorrei un feedback generale per favore!

Diciamo che ho questa struttura DB per gli utenti (in Mongo / JS, ma in realtà è tutto pseudocodice- e gli ID sarebbero in realtà riferimenti DB, non interi di base):

users = [
  {
    id: 1,
    name: 'John Smith'
  },
  {
    id: 2,
    name: 'Sheila X. Ample'
  }
]

... e voglio definire alcuni progetti in cui una o più di queste persone possono essere dei collaboratori. Il progetto definirà chi ha accesso generale ad esso e chi lo ha creato, chi è l'attuale collaboratore principale (questo cambierà regolarmente), chi lo ha aggiornato, ecc. Ecc.

Questo metodo è il migliore, dove gli ID sono rappresentati direttamente sull'oggetto del progetto:

projects = [
  {
    id: 1,
    name: 'Project One',
    collaborators: [
      2
    ],
    primaryCollaborator: 2,
    lastUpdatedBy: 2,
    createdBy: 2
  },
  {
    id: 2,
    name: 'Another Project',
    collaborators: [
      1,
      2
    ],
    primaryCollaborator: 1,
    lastUpdatedBy: 2,
    createdBy: 1
  }
]

// Get the primary collaborator:
primaryID = projects.find({id: 2}).primaryCollaborator;

O questo, dove le proprietà sono booleane per ogni singolo collaboratore:

projects = [
  {
    id: 1,
    name: 'Project One',
    collaborators: [
      {
        id: 2,
        primaryCollaborator: true,
        lastUpdatedBy: true,
        createdBy: true
      }
    ]
  },
  {
    id: 2,
    name: 'Another Project',
    collaborators: [
      {
        id: 1,
        primaryCollaborator: true,
        lastUpdatedBy: false,
        createdBy: true
      },
      {
        id: 2,
        primaryCollaborator: false,
        lastUpdatedBy: true,
        createdBy: false
      }
    ]
  }
]

// Get the primary collaborator:
primaryID = projects.find({id: 2}).collaborators.find({primaryCollaborator: true}).id;

Come ho detto, sono sicuro che questo tipo di domanda strutturale è stata posta un milione di volte prima, ma non vorrei che la vita di me sappia cosa trovare a Google!

Quali sono i vantaggi o gli svantaggi di farlo in entrambi i modi? Fa anche la differenza? Il primo metodo richiederebbe che gli ID referenziati sull'oggetto del progetto esistessero e causerebbero un mal di testa se, per esempio, un collaboratore fosse stato rimosso dal progetto. Il secondo metodo sembra un po 'pesante e causerebbe un mal di testa se qualcosa andasse storto e più di un collaboratore fosse classificato come true come il collaboratore principale, ad esempio. O c'è un metodo migliore del tutto?

Grazie in anticipo! :)

nosql database-design

posta Matt Fletcher 03.11.2014 - 19:49

fonte

2 risposte

Leggi altre domande sui tag nosql database-design

Divisione di un'app Rails / Ruby su più server Modellistica leggera dei dati rispetto alle classi tradizionali [chiusa]

score 0 · Answer 1

Sono giunto alla conclusione di utilizzare il metodo B. Questo perché ho capito che avevo bisogno di dividere i miei collaboratori in diversi tipi di utenti e utilizzando il metodo A, non sarei in grado di unire i riferimenti come sarebbero attraverso diversi documenti. È più facile farlo con un po 'di query / scripting più tardi di provare e forzarlo a lavorare basandosi esclusivamente sugli schemi.

score 0 · Answer 2

Consiglio vivamente il secondo approccio

where the properties are booleans on each individual collaborator

perché questo approccio cattura una delle necessità importanti per cui NoSQL (MongoDB) ha ottenuto così tanta trazione nel movimento Agile.

In primo luogo , un grande vantaggio di questo approccio è lo zucchero sintattico e il facile flusso di codice che ottieni, prendi in considerazione:

# this example demonstrates approach-1
project = projects[i] # i.e. load projects form DB
primaryCollaboratorID = project.primaryCollaborator
primaryCollaborator = # again, DB/ORM specific code to get primaryCollaborator details
# now store more state to render a separate page for each member, OUCH!

confronta questo con

# this example demonstrates approach-2
a_collaborator = collaborators[i]      # or whatever your DB says
if a_collaborator.primaryCollaborator: # note a_collaborator is already in memory
    prepareUI(a_collaborator, "send team message", "button")

Ora, non sono un programmatore esperto, e come @Phillip ha detto che ogni DB NoSQL è diverso quindi non sostengo che entrambi gli approcci sono più veloci / lenti a causa del numero di Chiamate di DB, ma puoi facilmente prevedere (prevedere?) Che il secondo approccio porterebbe a un codice più pulito, più intuitivo e facile da correggere.

In secondo luogo , il secondo approccio è (imho) più agile perché porta l'agilità a un livello più atomico. Perché ne avresti bisogno? Bene

The project will define who has general access ... current primary collaborator (this will change regularly), who last updated it, etc etc.

Quindi, domani se devi avere un nuovo campo qualityInspectorID per ogni progetto, il tuo secondo approccio ti farà risparmiare un sacco di mal di testa.