Normalisation MongoDB, clé étrangère et jonction

Avant de plonger profondément dans MongoDB pendant des jours, je me suis demandé si je devais me lancer ou non. Je n’ai fondamentalement aucune expérience avec nosql.

J’ai lu un peu sur certains des avantages des bases de données de documents et je pense que pour cette nouvelle application, elles seront vraiment géniales. Il est toujours compliqué de faire des favoris, des commentaires, etc. pour de nombreux types d’objects (beaucoup de relations de type M à M) et de sous-classes – c’est un peu difficile à gérer.

J’ai aussi une structure qui sera difficile à définir en SQL car elle est extrêmement nestede et se traduit par un document bien meilleur que 15 tables différentes.

Mais je suis confus à propos de quelques choses.

Est-il souhaitable de garder votre firebase database normalisée? Je ne veux vraiment pas mettre à jour plusieurs enregistrements. Est-ce encore ainsi que les gens abordent la conception de la firebase database dans MongoDB?
Que se passe-t-il lorsqu’un utilisateur préfère un livre et que cette sélection est toujours stockée dans un document utilisateur, mais que le livre est alors supprimé? Comment la relation se détache-t-elle sans clés étrangères? Suis-je manuellement responsable de la suppression de tous les liens moi-même?
Que se passe-t-il si un utilisateur privilégie un livre qui n’existe plus et que je l’interroge (une sorte de jointure)? Dois-je faire une tolérance de panne ici?

MongoDB ne prend pas en charge les relations de clé étrangère côté serveur, la normalisation est également déconseillée. Si possible, vous devez incorporer votre object enfant dans les objects parents, cela augmentera les performances et rendra les clés étrangères totalement inutiles. Cela dit, ce n’est pas toujours possible, il existe donc une construction spéciale appelée DBRef qui permet de référencer des objects dans une collection différente. Ce n’est peut-être pas si rapide car la firebase database doit effectuer des requêtes supplémentaires pour lire des objects, mais autorise une sorte de référence de clé étrangère.

Cependant, vous devrez gérer vos références manuellement. Ce n’est qu’en recherchant votre DBRef que vous verrez si elle existe, la firebase database ne parcourra pas tous les documents pour rechercher les références et les supprimer si la cible de la référence n’existe plus. Mais je pense que supprimer toutes les références après la suppression du livre nécessiterait une seule requête par collection, pas plus, donc pas vraiment difficile.

Si votre schéma est plus complexe, vous devriez probablement choisir une firebase database relationnelle et non nosql.

Il existe également un livre sur la conception de bases de données MongoDB: Conception de documents pour MongoDB

MISE À JOUR Le livre ci-dessus n’est plus disponible, mais en raison de la popularité de MongoDB, il en existe beaucoup d’autres. Je ne les lierai pas tous, car de tels liens sont susceptibles de changer, une simple recherche sur Amazon montre plusieurs pages, donc cela ne devrait pas poser de problème pour en trouver.

Voir la page de manuel de MongoDB pour les «références manuelles» et DBRefs pour plus de détails et d’exemples

Ci-dessus, @TomaaszStanczak déclare

MongoDB ne prend pas en charge les relations de clé étrangère côté serveur, la normalisation est également déconseillée. Si possible, vous devez incorporer votre object enfant dans les objects parents, cela augmentera les performances et rendra les clés étrangères totalement inutiles. Cela dit, ce n’est pas toujours possible …

La normalisation n’est pas découragée par Mongo. Pour être clair, nous parlons de deux types de relations fondamentalement différents que peuvent avoir deux entités de données. Dans l’un, une entité enfant appartient exclusivement à un object parent. Dans ce type de relation, la méthode Mongo consiste à intégrer.

Dans l’autre classe de relations, deux entités existent indépendamment – ont une durée de vie et des relations indépendantes. Mongo souhaite que ce type de relation n’existe pas et se méfie de la manière dont il convient de le gérer. L’incorporation n’est pas une solution. La normalisation n’est ni découragée ni encouragée. Mongo vous donne juste deux mécanismes pour y faire face; Refs manuelles (analogues à une clé avec la contrainte de clé étrangère liant deux tables) et DBRef ( méthode différente, légèrement plus structurée). Dans ce cas d’utilisation, les bases de données SQL gagnent.