Discussion :

[Mickael Baron]

La société Arolla, cabinet de conseil en technologies de l'information vous propose un retour d'expérience d'une formation MongoDB pour les développeurs Java.


Pour lire le tutoriel, accéder à : http://arolla.developpez.com/tutorie...loppeurs-java/


N'hésitez pas à mettre vos critiques et impressions par rapport à cet article dans ce forum.


L'équipe Java

[pcaboche]

Il faut savoir que chaque document au sein d'une collection a un identifiant unique, par défaut un champ de type ObjectId généré par Mongo. On peut cependant très bien utiliser un ID de notre système d'information à la place (numéro de sécurité sociale pour un individu par exemple).

Désolé, mais ça c'est interdit...

Le numéro de sécurité sociale ne peut être utilisé que dans des cas très précis définis par la loi (paye, frais maladie) et ne peut en aucun cas être utilisé comme identifiant pour un individu.

En particulier, le numéro de sécurité sociale ne fait pas partie de la liste des informations qui doivent figurer dans le registre unique du personnel, fixée par les articles L.620-3 et R. 620-3 du code du travail, (L1221-13 à 15 depuis 2008) et ne doit donc pas être enregistré dans ce cadre.

Le numéro de sécurité sociale d’un employé ne peut donc pas être utilisé comme numéro de matricule unique pour l’identifier dans tous les fichiers de gestion des ressources humaines de son entreprise ou de son administration.

Source : http://www.cil.cnrs.fr/CIL/spip.php?article1434

[landry161]

Je te félicite pour ton tutoriel.

[benjani13]

Merci pour ce tuto, je m'initie en ce moment à mongodb et je le trouve donc très intéressant. Cependant, étant très habitué au modèle relationnel j'ai du mal à trouver mes repères et à trouver les bonnes pratiques.

Petite question sur le premier exemple:

Exemple :

Imaginons un blog contenant des posts, chaque post contenant des commentaires. [...]

Avec MongoDB, on va créer des documents qui contiennent un tableau de commentaires (dénormalisation) comme suit :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
{
       "_id" : { "$oid" : "5143ddf3bcf1bf4ab37d9c6d" },
       "body" : "Je suis un super post !",
       "post_date" : { "$date" : 1363402227874 },
       "comments" : [
             {
                    "_id": 1,
                    "comment_text": "Je suis le commentaire 1",
                    "author": "Mickael Barroux"
             },
             {
                    "_id": 2,
                    "comment_text": "Je suis le commentaire 2",
                    "author": "Arolla",
             }
       ]
}

Cela sera optimisé pour la récupération des données en lecture. Par contre, revers de la médaille, ce sera un peu plus compliqué dans des cas de mises à jour du nom d'un auteur par exemple (il faudra mettre à jour l'auteur de chaque commentaire écrit par la personne).

Je me posais la même question en regardant le schéma de la base, comment changer le nom de l'auteur si celui ci change son pseudo. On devra boucler sur tous les messages, comparer le champs author (donc comparaison de chaine, plus lent que comparer un id). Existe il une meilleur pratique? Tout ce que je peux imaginer retombe dans un modèle relationnel...


Imaginons aussi qu'un utilisateur a une signature sur ces messages (potentiellement longue). Si la personne a 3000 messages, et qu'il décide d'en changer, on va devoir réécrire 3000 fois sa signature dans la base?

Ma deuxième question porte sur le schéma dynamique de mongodb (le fait de pouvoir rajouter des champs ou des sous collections à certains documents seulement). Comment le gérer efficacement dans son application (comment éviter d'appeler un champs qui n'existe pas)? Avez vous des exemple d'utilisation concrets de cette possibilité?

[youx]

Le système est optimisé pour la lecture alors oui il faut reparser tout les éléments à changer. Si des éléments varient il doivent appartenir à une autre "colonne" (heu... quel nom donner) avec l'identifiant qui va bien.