È appropriato usare id-s nei sottodocumenti MongoDb?

1

Attualmente mi sto familiarizzando con NoSQL creando una semplice applicazione web usando MongoDb con il driver C # ufficiale. Se ho capito correttamente il concetto NoSQL, solo il documento radice aggregato dovrebbe avere un id e le collezioni figlio sono prive di identità.

Ad esempio nel codice C # avrei i seguenti 2 Poco-s:

public class User
{
    public BsonObjectId Id { get; set; }

    [BsonElement("pets")]
    public List<Pet> Pets { get; set; } 
}

public class Pet
{
    public string Name { get; set; }
}

Come risolverei un caso, dove voglio avere visioni CRUD separate per gli animali domestici? Con un database relazionale lo farei avendo l'id dell'animale domestico nella stringa di query, con NoSQL non ne sono sicuro.

Questa domanda è nata da quando ho provato ad aggiungere un campo ID al documento secondario "Animale domestico". Invece di un id per animale domestico, un oggetto denominato "_csharpnull" è stato invece aggiunto al database.

Ad esempio, se faccio questo:

public class User
{
    public BsonObjectId Id { get; set; }

    [BsonElement("pets")]
    public List<Pet> Pets { get; set; } 
}

public class Pet
{
    public BsonObjectId Id { get; set; }
    public string Name { get; set; }
}

Quindi questo documento è inserito nel database:

{
    "_id" : ObjectId("5643a1f9766bcf0fc0b26f14"),
    "pets" : [ 
        {
            "_id" : {
                "_csharpnull" : true
            },
            "Name" : "T-Rex"
        }
    ]
}

Quando il mio comportamento previsto sarebbe qualcosa del tipo:

{
    "_id" : ObjectId("5643a1f9766bcf0fc0b26f14"),
    "pets" : [ 
        {
            "_id" : ObjectId("56439adc766bcf49a0639992"),
            "Name" : "T-Rex"
        }
    ]
}
    
posta AlanWakeUp 11.11.2015 - 21:26
fonte

2 risposte

1

Anche se non sono a conoscenza di uno standard particolare che dice sì o no, nella mia esperienza questo può e dovrebbe in molti casi essere fatto.

Nel momento in cui vuoi essere in grado di gestire un Pet su se stesso in varie operazioni hai bisogno di un ID. Il modo più semplice in MongoDB è assegnargli un ObjectID.

Ma ho anche incontrato casi in cui non era necessario, ad esempio quando hai un documento secondario che appare sempre insieme al suo documento principale.

Anche se non ho familiarità con C # in particolare, quello che stai cercando di fare funziona sicuramente in Java. Assicurati di inizializzare l'ObjectID manualmente. Mentre MongoDB crea gli ID oggetto per te nei documenti di livello superiore di una raccolta, non farà lo stesso per i documenti secondari.

    
risposta data 13.11.2015 - 02:32
fonte
0

If i have understood the NoSQL concept correctly, then only the aggregate root document should have an id and the child collections are without identity.

Non sono sicuro che i database orientati ai documenti relazionali o addirittura NoSQL vadano perfettamente bene con Domain Driven Design in tutto casi.

Il tuo documento avrà un ID oggetto / chiave primaria o non dovrebbe essere considerato un dettaglio di implementazione (anche se non stai attento, WILL influenzerà il tuo processo di modellazione).

Ciò che è più importante è il modo in cui tratti quel particolare documento. Lo accedete al di fuori dei confini di radice aggregati per ID? Se lo elimini e ricrea lo stesso oggetto completo, ma con un ID diverso, influirà in qualche modo sulla logica dell'applicazione? Ecc.

Penso che sarebbe meglio avere oggetti value senza ids in modo che non ci fosse alcuna tentazione di indirizzarli usando id. Ma se per qualche ragione dovresti avere, consideralo un dettaglio di implementazione e concentrati sul seguire prima la logica del dominio.

    
risposta data 13.11.2015 - 09:38
fonte

Leggi altre domande sui tag