Jusqu'où le contenu a-t-il été mis à jour ? 
Les deux premiers chapitres pour l'instant.
Les remarques suivantes sont merdiques. Désolé pour le dérangement.
utilisant le langage SQL ont été presque systématiquement utilisées pour stocker les données
Au début, j'avais compris que le "systématiquement" se rapportait à "stocker" et non à "utilisant le langage SQL". Plutôt : "utilisant le langage SQL ont été utilisées pour stocker les données presque systématiquement".
Si l'on peut faire évoluer la base de données horizontalement, donc en ajoutant simplement un serveur de plus au cluster de serveur en charge de la base de données, ça ne pose pas de problème. Par contre
Je me suis un peu perdu là. Est-ce bien ça que tu veux dire :
demande du temps et des précautions, sans compter un certains temps
Aurais-tu un peu de détails à ce sujet ?
Les bases de données relationnelles, avec leur modèle extrêmement rigide et statique (chaque type de données doit être défini à l'avance pour pouvoir être enregistré), ne sont pas adaptées à toutes ces données.
Ah ! Je l'attendais celle-là. A mon avis, tu devrais un poil développer. Je vois ce que tu veux dire parce que j'ai rencontré ce problème dernièrement, mais ça peut être un peu flou pour ceux ne l'ayant pas rencontré ni même utilisé une base relationnelle. Un court exemple éclairerait ce passage.
En fait, tu en parles un peu plus dans "Représentation des données dans une base de données relationnelle". Mais je donnerais tout de même un exemple. A ce niveau plutôt qu'en dessous, sinon les lecteurs risquent de se poser une question et d'attendre avant d'avoir la réponse.
on ne peut pas simplement distribuer une base de données MySQL ou Oracle sur plusieurs serveurs différents.
Aurais-tu un peu plus d'explications à ce propos ?
Tirer parti du « cloud computing » également pour dupliquer
Le "également" est peu clair. C'est "Tirer également parti" ou "pour également dupliquer" ? Dans le premier cas, le "également" ne me semble pas nécessaire.
Les différents modèles et technologies ayant émergés sont aujourd'hui regroupés sous la bannière « NoSQL », qui signifie « Not Only SQL » (« Pas seulement SQL »).
De plus, je ne crois pas que tu aies expliqué ce "pas seulement". Ca me semble nécessaire puisqu'on s'attend à un "pas du tout". J'en parlerais dans "Représentation des données dans une base de données NoSQL", juste avant "Bases de données clé-valeur".
qui soient complètement factorisées et agnostiques[^1]
La note ne passe pas au niveau du rendu.
Prenons l'exemple classique de l'article de blog
Après avoir lu cet article, je me suis dit : "mais c'est nul une base relationnelle". Ce n'est pas vraiment le but de ce tutoriel, mais peut-être devrais-tu expliquer quand il faut s'en servir en plus d'expliquer quand il ne faut pas s'en servir. 
Les valeurs (= données) stockées peuvent être n'importe quoi
Et les clés ? 
et il est possible de faire des requêtes soit en utilisant la clé du document
Dans l'exemple que tu donnes, le document n'a pas de clé. D'ailleurs, Mongo ne m'a jamais demandé de clé pour insérer un document dans une collection.
Bases de données orientées colonnes
C'est très clair à présent. Par contre, j'aérerais les exemples, en ajoutant des espaces autour des point-virgules.
permet de stocker des données sur des réseaux, c'est-à-dire où les éléments sont connectés entre eux
C'est vraiment pour chercher la petite bête mais le "c'est-à-dire" ne va pas vraiment. Soit "permet de stocker des données sur des réseaux, où les éléments sont connectés entre eux", soit "permet de stocker des données sur des réseaux, c'est-à-dire dans des trucs où les éléments sont connectés entre eux". La deuxième option, en modifiant "truc" a le mérite d'être plus précise. Mais on comprend très bien comme ça.
Chaque arête peut lier de 2 à X noeuds
Je chipote, mais on utilise plutôt $n$ pour les entiers naturels.
Les remarques suivantes sont merdiques. Désolé pour le dérangement.
Seront ensuite présentés les logiciels nécessaires pour faire tourner MongoDB.
Je complèterais, en disant que "MongoDB" est un terme désignant en fait un ensemble d'outils et que nous allons revenir sur chacun d'eux par la suite.
Une collection est simplement une liste de documents.
N'est-ce pas plutôt un ensemble de documents ? Autrement dit, Mongo indexe-t-il les documents d'une collection ?
On aura par exemple une collection client, une collection arbres, etc.
Je me posais justement la question : y a-t-il une convention concernant le nombre (singulier ou pluriel) du nom d'une collection ?
Un document JSON est délimité par des accolades { document }
Ca fait bizarre de commencer par ça. Je ferais plutôt un truc du genre : "Un document JSON est une liste (voir remarque ci-dessous) de clés auxquelles sont associées des valeurs. Il est délimité par des accolades, de la manière suivante :".
une liste de clés auxquelles sont associés des valeurs
Je préciserais de plus que les clés sont nécessairement des chaînes.
Beaucoup de langages informatiques utilisent le paradigme de la programmation orientée objets. Ces langages manipulent des objets, qui vont avoir plusieurs propriétés, certaines de ces propriétés étant elles-mêmes des objets ou des listes d'objets. Dans MongoDB, un document est le pendant d'un objet. On peut stocker directement des documents complexes dans Mongo.
Je ne suis pas sûr que ça aide les débutants à comprendre.
Si on peut stocker des documents complètement différents dans une collection, pourquoi ne pas tout stocker dans une seule collection ? Pourquoi même avoir des collections, et pas tout simplement un ensemble de documents ?
L'exemple ne me semble pas assez précis et je ne suis pas certain de bien le comprendre : si je mélange stylos et feuilles dans un tiroir mais que je n'en ai qu'un de chaque, cela ne jouera pas sur mon temps de recherche ; ainsi, c'est plus le nombre que le type des données qui joue sur l'efficacité, non ? Par exemple, je ne vois pas pourquoi rechercher un document nommé "Aragorn" prendrait plus de temps dans la première collection que dans la seconde :
1 2 3 4 5 6 7 8 9 10 | { "latitude": 0, "longitude": 0, "population": 5000 }, { "nom": "Aragorn", "genre": 0, // Homme "arme": ["épée"] } |
1 2 3 4 5 6 7 8 9 10 | { "nom": "Frodon", "genre": 0, "arme": ["lance-pierres"] }, { "nom": "Aragorn", "genre": 0, // Homme "arme": ["épée"] } |
Comptes-tu dédier un chapitre/extrait à la conception d'une base Mongo ? Par exemple, je me demande s'il est préférable de créer des collections garçons et filles ou d'en créer une personnes avec un champ pour le genre. J'imagine que ça dépend si mes recherches porteront ou non sur plusieurs genres (autrement dit, sur les personnes en générale et pas seulement sur que des garçons ou que des filles). Le cas échéant, partager en deux collections ralentira les recherches (il faudra sonder deux collections au lieu d'une). Dans le cas contraire, si filles et garçons sont clairement séparés au niveau des recherches, les mettre dans la même collection augmente le nombre d'éléments de celle-ci et ralentit de facto les recherches.
Ce paragraphe est une conversation avec moi-même mais permet d'éclairer un peu ma remarque ci-dessus. Du moins, c'est plus clair pour moi maintenant.
Une autre question que je me pose à propos des collections est : à quel point factoriser ? Si j'ai une collection de personnages, chacun ayant un champ ville contenant un document, me faut-il créer une collection villes, sachant que beaucoup de personnages pourront habiter la même ville ?
On peut faire des recherches par comparaison directe ("tous les livres de Charles Dickens" par exemple), mais aussi en faisant des comparaisons
"On peut faire des recherches par comparaison directe mais aussi en faisant des comparaisons" fait bizarre.
de manière ordonnée. Ainsi, quand la requête se fait sur la portion en question, il est plus facile de retrouver les documents qui correspondent au critère demandé
Quand le critère de recherche est le même que celui d'indexation, non ? A priori, ranger mes documents selon leur champ nom n'accélère pas ma recherche si celle-ci se fait sur un autre champ.
plusieurs copies, placées sur des serveurs. différents
Il y a un point (".") gênant.
gérer ces ensembles de copies, appelés "réplicats"
Ce sont les ensembles qui sont appelés "réplicats" ou les copies elles-mêmes ?
D'ailleurs, tu n'as pas parlé plus haut d'ensembles. Tu as juste dit qu'on copiait la base et la stockait sur d'autres serveurs.
en créant facilement un ensemble de fragments (en anglais, "shards"). Chaque fragment contient alors un sous-ensemble des données
Je pense que tu introduis le terme "fragments" un peu trop brutalement. Comme j'ignore ce que c'est exactement, je ne peux pas proposer de formulation exacte, mais je ferais un truc du genre : "en créant facilement un ensemble de TODO, appelés "fragments" (en anglais, "shards"). Chaque fragment contient alors un sous-ensemble des données".
MongoDB ne permet pas de telles transactions.
Pourquoi donc ? Ca ne semble pas compliqué à implémenter pourtant, si ?
lorsque l'on enregistre des changements dans un document, on peut être sûr que tous les changements seront effectués, qu'aucun ne le sera.
Il manque un "ou".
On a bien une garantie d'atomicité avec MongoDB, mais elle est plus restreinte que dans les bases de données relationnelles, et n'est pas faite au même niveau.
Je préciserais. Par "plus restreinte", tu veux dire que l'atomicité n'est vérifiée que pour un seul document ? Que signifie alors "au même niveau" ?
sans étape intermédiaire dans laquelle les données sont invalides
Je préciserais. Je ne suis pas du tout un expert, mais j'imagine qu'il y a nécessairement un moment où les données sont invalides. Seulement, on ne peut y accéder.
Une fois le changement effectué, toute transaction sur la base de données ne doit avoir accès qu'au nouvel état valide.
"Une fois le changement effectué, toute opération sur la base de données ne doit pouvoir se faire que sur le nouvel état valide." ? Le terme "transaction" est déjà utilisé pour désigner un ensemble atomique d'opérations.
Par défaut, MongoDB garantit la cohérence des données. Cependant, dans certaines configurations, MongoDB peut être cohérente au final.
Au final de quoi ?
Imaginons qu'on veuille modifier tous les documents d'une collection pour leur ajouter un champ.
Tu dis en introduction de cet extrait que les propriétés ACID sont vérifiées par les SGBDR. Là, tu parles d'une base NoSQL. Je formulerais ainsi : "Toute opération sur les données doit être isolée des autres opérations potentielles, ce qui n'est pas complètement respecté par Mongo. En effet, imaginons".
Si pendant que cette opération se déroule, on tente de modifier un certain document
Je remplacerais "modifier un certain document" par une opération précise, du genre "soustraire 42 à l'un de ses champs". En effet, quand tu parles de "modification" par la suite, on ne sait plus trop si tu fais référence à l'ajout d'un champ à tous les documents ou à l'opération effectuée pendant cet ajout. Tu pourras alors clairement parler d'"ajout du champ" ou de "la soustraction".
qui garde une trace de chaque opération d'écriture réalisée
"à réaliser" plutôt, non ? Enfin pour moi, une opération d'écriture est une écriture sur le disque, pas seulement dans le journal. Mais peut-être me trompé-je.
Toutes les 60 secondes (par défaut), MongoDB applique les opérations du journal aux données sur le disque.
Cela signifie que si j'insère un document dans ma base maintenant, il est possible que ce ne soit pas vraiment fait avant une minute ? Ca craint pour la cohérence là, non ?
Il est possible (et même courant) d'avoir plusieurs clients différents communiquant avec le même serveur
Ce n'est pas très clair : parles-tu de logiciels clients différents ou d'instances démarrées de ces logiciels ?
Je préciserais qu'il s'agit ici d'installer tous les composants (ou alors je n'ai pas compris).
Il suffira de le préciser au démarrage du serveur.
"comme nous le voyons plus bas." ?
Vous pouvez donc écrire des instructions en JS, elles s'exécuteront sans problème.
Comme c'est la première fois qu'on joue avec le shell, j'afficherais le résultat des commandes. Par exemple :
1 2 | > 4+6*3 22 |
Pour quitter mongo, vous pouvez soit fermer votre utilitaire de ligne de commande, soit utiliser la fonction quit().
Moi, je fais Ctrl+C.
Sinon, "Pour quitter mongo" n'est pas très précis. En l'occurrence, quit() n'est valable que pour le client. Oui c'est évident, mais tu auras des lecteurs noobs.
J'ai commencé à relire le cours qui est plutôt bien écrit dans l'ensemble.
Néanmoins, comme la relecture est plutôt facilement interrompue (je fais ça sur mon temps libre) et qu'elle donne lieu à des commentaires qui prennent beaucoup de place et qui sont difficiles à "checklister" sur zds, j'ai créé un etherpad pour gérer le tout. Par contre il a une durée de vie de 2 mois sans modification.
du nouveau ici?
Grosse pause cet été pour raisons personnelles. Je reprends doucement, avec d'abord écriture d'un article que k'ai promis pour le prochain CdS, puis je m'occupe de ce tuto
Bonne rentrée alors
Ledit article étant en validation, on va pouvoir te revoir par ici ? 
Concernant mes remarques précédentes, elles sont affreusement merdiques, désolé. Au niveau de la forme, déjà, mais aussi sur le fond, puisque je relève des points de détail en même temps que des points sur la structure du tutoriel.
Comme dit en MP, le contenu est de grande qualité, mais l'absence de fil directeur est un peu dommage, parce qu'on se retrouve avec une suite de commandes illustrées par des exemples mais introduites sans contexte particulier.
Ca demanderait un travail monstre, mais tu pourrais, à l'instar du tutoriel sur MySQL, plonger le lecteur dans un problème concret, qu'il lui faudrait résoudre en gérant une base Mongo. Ou alors, plutôt qu'avoir une grande "histoire", introduire une nouvelle situation à chaque chapitre. Bien sûr, je comprendrai que tu souhaites conserver cette structure et, le cas échéant, baserai mes remarques futures sur ce choix.
Merci.
Hello,
J'espère pouvoir reprendre ce tuto bientôt oui.
Pas de souci sur tes remarques, au contraire. Je préfère en avoir trop que pas assez, quitte à faire le tri entre ce que je trouve pertinent (la plupart de tes remarques) et le reste.
Concernant la structure de mon tuto, oui, je vais essayer de la repenser pour l'axer sur 2-3 problématiques. Sans doute un blog (classique mais ça fonctionne toujours), un système de logging, et un jeu. Faut encore que je réfléchisse comment j'introduis ça.
J'ai enlevé les remarques orthographiques de mes précédents messages. Il faudrait que je me replonge dans le tutoriel, mais je préfère attendre que tu le revois.
Plop, j'ai donc commencé à repenser le tuto. \o/
Vous m'en voulez si j'utilise l'exemple bateau du blog pour la première partie ? J'utiliserai probablement des lutins et des loup-garous plus loin mais pour les fonctions basiques, y a rien à faire, un blog permet des exemples et des mises en situation simples et réalistes.
Tu es l'auteure, tu utilises les exemples que tu souhaites au bénéfice de ton tuto.
Wai je sais… Mais les blogs, c'est moins marrant que les lutins 
Des traineaux/hottes avec des cadeaux ?
J'utiliserai probablement des lutins et des loup-garous plus loin
Comment ça "probablement" ?
mais pour les fonctions basiques, y a rien à faire, un blog permet des exemples et des mises en situation simples et réalistes.
Et puis ça fait en quelque sorte office de tutoriel "Créer son blog avec Mongo", ce qu'un certain nombre de personnes risquent de vouloir faire.
Bon, tant pis pour l'originalité alors
C'est juste que c'est vraiment l'exemple utilisé par tous les bouquins techniques ces 10 dernières années, mais je suppose qu'il y a une raison…
Simplicité et pas envie de se prendre la tête, je suppose.
C'est surtout un exemple très commun, donc très utile. Et assez simple et complet pour pouvoir être transposé à autre chose si besoin.
Te prends pas la tête pour l'instant. Rien ne t'empêche d'adapter si une idée géniale te vient plus tard. 
Bonsoir,
Je viens de tomber sur ce tutoriel, et hormis quelques fautes çà et là (que je n'ai évidemment pas notées pour les indiquer ici), il s'apprête à être d'une très bonne qualité je pense. En tout cas j'aime bien, il est intéressant et bien écrit.
J'ai deux questions sur le contenu, je ne sais pas si tu préfères répondre succintement ici ou si tu l'aborderas plus tard en détail dans le tutoriel, mais voici :
Typiquement si on compare avec un cours sur MySQL rédigé de façon classique, on ne reste pas en console très longtemps et on attaque vite fait l'utilisation à travers JDBC ou PDO… certes on n'a pas un langage de requêtage complet et pratique comme JavaScript à disposition, mais… tout de même…
En attendant d'avoir les réponses, merci pour ce joli début de tutoriel et bon courage pour rédiger la suite.
- Les jointures n'existent pas, tu l'expliques très clairement. Est-ce que ça veut dire que, pour avoir une base performante, dans le cadre d'un blog par exemple, j'ai intérêt à stocker un array de tags dans chaque document de la collection billets et un array d'ID de billets dans chaque document représentant un tag ? Avec les risques de données obsolètes associées ? Avoir deux collections liées est une mauvaise idée du coup ?
Apparemment dans la version 3.2, il est possible de faire des jointures : https://docs.mongodb.org/master/reference/operator/aggregation/lookup/#pipe._S_lookup
Pourquoi donc ? Ca ne semble pas compliqué à implémenter pourtant, si ?
https://docs.mongodb.org/v3.0/core/write-operations-atomicity/
C'est trivial sur un document pour un utilisateur, ça l'est moins sur plusieurs documents, dans un environnement concurrent sans passer par des locks et toutes les joyeusetés qui vont avec.
A priori isolated peut/va faire le job. Mais pour le coup, je n'utiliserais pas Mongo dans un environnement nécessitant des transactions multi-documents. L'idée c'est de stocker des données plutôt disjointes, sans side-effect et le faire rapidement dans un environnement à accès concurrents.
Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte