MongoDB est une base de données de type documents, sous
licence GNU AGPL V3, et dont la version 1.4 vient de sortir. Elle s'inscrit dans le mouvement
NoSQL, et propose des fonctionnalités très intéressantes :
- Le stockage des documents se fait dans un format très proche du JSON (le BSON) et sans avoir à imposer un schéma ;
- Les requêtes dynamiques sont d'une richesse fonctionnelle que je pense être équivalente au SQL, et de nouveaux opérateurs font apparition au fur et à mesure des versions ;
- Il est possible d'indexer plein de choses, dont les objets internes et, nouveauté de la 1.4, des données géospatiales ;
- Les requêtes peuvent être profilées ;
- Il est faisable de stocker des objets binaires volumineux, comme des photos ou des vidéos, dans MongoDB grâce à GridFS ;
- MongoDB supporte la réplication, le failover, et de manière expérimentale le sharding automatique ;
- Des pilotes permettent de l'utiliser depuis de nombreux langages, dont le PHP, le Ruby et le Python.
Cela en fait une base de données solide, offrant
des performances impressionnantes. Elle est déjà utilisée par de grands noms comme
Sourceforge, EA, le New-York Time et
bien d'autres. Elle me semble être particulièrement bien adapté pour le développement web (enfin, si vous visez à devenir le prochain twitter,
Cassandra est probablement un meilleur choix). Certains prédisent même qu'elle pourrait
prendre la place de MySQL dans ce domaine.
Aller plus loin
# Théorème CAP
Posté par Victor STINNER (site web personnel) . Évalué à 10.
http://blog.nahurst.com/visual-guide-to-nosql-systems
CAP est un sigle pour désigner (traduction approximative) :
- Consistency (cohérence) : chaque client a toujours la même vue des données
- Availability (disponibilité) : tous les clients peuvent lire et écrire
- Partition tolerance (tolérance au partionnement ?) : le système peut être réparti physiquement à travers le réseau
Le théorème CAP dit qu'on peut pas tout avoir : au mieux, on peut en avoir que deux.
Les bases de données relationnelles ont choisi Consistency+Availability (donc mauvaise performance pour une base distribuée), Cassandra et CouchDB ont choisi Availability+Partition tolerance (donc mauvaise cohérence), et MongoDB a choisi Consistency+Partition tolerance (donc mauvaise disponibilité).
[^] # Re: Théorème CAP
Posté par barmic . Évalué à 3.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Théorème CAP
Posté par claudex . Évalué à 2.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Théorème CAP
Posté par Volnai . Évalué à 3.
No set of failures less than total network failure is allowed to cause the system to respond incorrectly ( http://www.julianbrowne.com/article/viewer/brewers-cap-theor(...) )
On peut faire ça avec les RDBMS classiques il me semble, non ?
[^] # Re: Théorème CAP
Posté par Volnai . Évalué à 2.
D'après ce que je comprends de Nosql, la cohérence est de type 'eventually consistency' pas stricte. C'est un peu gonflé de mettre ça comme choix numéro 1.
[^] # Re: Théorème CAP
Posté par El Titi . Évalué à 10.
Le théorème CAP dit qu'on peut pas tout avoir : au mieux, on peut en avoir que deux.
Ah! moi je ne connaissais que le théorème BAC qui me bien parait plus intéressant car on peut satisfaire les 3 :
- le Beurre
- l'Argent du beurre
- Le Cul de la crémière.
Le vendredi, c'est permis :o)
[^] # Re: Théorème CAP
Posté par zebra3 . Évalué à 1.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Théorème CAP
Posté par El Titi . Évalué à 10.
[^] # Re: Théorème CAP
Posté par blackshack . Évalué à 1.
[^] # Re: Théorème CAP
Posté par Bruno Michel (site web personnel) . Évalué à 2.
Il explique Availability et Partition tolerance.
[^] # Re: Théorème CAP
Posté par Bruno Michel (site web personnel) . Évalué à 3.
# What about CouchDB?
Posté par lrbabe . Évalué à 2.
Moi je vois encore pas mal de compétition entre MongoDB et CouchDB. Il est encore trop tôt à mon avis pour dire lequel de ces deux projets sera le prochain MySQL.
[^] # Re: What about CouchDB?
Posté par Bruno Michel (site web personnel) . Évalué à 2.
Par contre, MongoDB a de la concurrence pour devenir le prochain MySQL, c'est indéniable. Par exemple, j'aimerais bien trouver un peu de temps pour explorer Riak [http://riak.basho.com/].
[^] # Re: What about CouchDB?
Posté par Maclag . Évalué à 3.
Comment ces BDD vont-elles s'imposer et surtout où??
Moi je vais pas lancer mon Twitter perso et me jeter sur le premier hébergeur qui va me le proposer...
MySQL, par contre, c'est limite si tu t'insurges pas quand c'est pas inclus d'office!
[^] # Re: What about CouchDB?
Posté par Bruno Michel (site web personnel) . Évalué à 4.
Je verrais bien ces bases de données NoSQL se répandre pour les applications web, car les bases de données SQL ne sont pas vraiment ce qu'il y a de plus adaptées pour ça, et ça se ressent quand on utilise des ORM.
[^] # Re: What about CouchDB?
Posté par Misc (site web personnel) . Évalué à 1.
1) trés connu ( cf article sur linux mag )
2) utilisé pour desktopcouch ( et donc gwibber, ubuntuone, feedie, etc )
[^] # Re: What about CouchDB?
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
[^] # Re: What about CouchDB?
Posté par Bruno Michel (site web personnel) . Évalué à 2.
Si on prend un autre domaine, les files d'attentes, il y a également une forte concurrence entre différents produits. Le gagnant (à mes yeux) est RabbitMQ, qui est également en Erlang. Et pourtant, il y avait une concurrence avec d'autres projets en C (beanstalkd), Java (ActiveMQ) ou Ruby (Starling).
[^] # Re: What about CouchDB?
Posté par kowalsky . Évalué à 9.
# pitié ...
Posté par Julien . Évalué à 8.
[^] # Re: pitié ...
Posté par jhc_ . Évalué à 3.
On peut comparer le choix d'un MySQL ou Mongo pour une application en fonction d'un problème, cela est parfaitement censé.
Là où cela a dérivé je pense, c'est qu'une bonne partie des web apps ont une utilisation tellement basique des DB que virer le SQL ne ferait pas de mal ( sur le papier ).
Ca me rappele le début de Rails, avec toute sa hype à la con, qui finalement nuit à la techno elle même en lui donnant une réputation de truc juste à la mode tellement certains fanboys aveugles racontent que c'est 'la solution à tout nos problèmes (tm)'.
[^] # Re: pitié ...
Posté par LeBouquetin (site web personnel, Mastodon) . Évalué à 10.
Par exemple, pour stocker les pages d'un wiki, utiliser postgresql me semble être une hérésie. Ceci étant dit, j'adore PostgreSQL pour sa puissance fonctionnelle ; mais ce n'est pas appliqué à tout type d'application ; tout dépend des besoins, des contraintes.
Je vais prendre un exemple concret, d'expérience. Au boulot, on gère des bases de données de blob de plusieurs millions d'entrées avec mots-clés associés. On doit tout charger en mémoire sur des applis spécifiques. On utilise des bases Postgresql pour gérer les bases de données "référence" (ie celles qui garantissent la qualité et la cohérence des données de nos clients) parce que c'est lié à notre système d'information et parce qu'on a besoin de gérer des requêtes complexes, des procédures stockées, etc ; mais les serveurs qui manipulent les données en question les chargent via des fichiers SQLite (on les convertit entre temps) parce que d'un point de vue performances au chargement, il n'y a pas photo. Pour tous les outils internes "courants" (bugzilla, wiki, etc) on utilise MySQL parce que ça ne nécessite pas d'administration courante (c'est plus autonome qu'une base PostgreSQL). Et pour la gestion du code source, on utilise CVS qui est aussi une base de données à part entière (et qui est basée sur des fichiers) (notez: CVS est obsolète, je dis pas le contraire, mais ça marche bien:).
Typiquement pour les outils de gestion de version, si les bases de données relationnelles étaient la poule aux oeufs d'or, on n'aurait plus de systèmes "non SQL".
C'est comme si on disait : "par pitié, parler de PHP ou Python comme un langage de programmation est un non sens". Ne pas admettre qu'à des besoins différents les meilleures solutions sont différentes, ça oui, c'est un non sens à mon avis.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: pitié ...
Posté par Julien . Évalué à 3.
[^] # Re: pitié ...
Posté par Laurent Laborde (site web personnel) . Évalué à 4.
[^] # Re: pitié ...
Posté par Julien . Évalué à 1.
"Elle me semble être particulièrement bien adapté pour le développement web (enfin, si vous visez à devenir le prochain twitter, Cassandra est probablement un meilleur choix). Certains prédisent même qu'elle pourrait prendre la place de MySQL dans ce domaine."
[^] # Re: pitié ...
Posté par Kerro . Évalué à 5.
Et pour les programmeurs qui ne sont pas du dimanche, c'est souvent la même chose. A titre pro nous utilisons trois applications web (un wiki, un gestionnaire de tâches, et un calendrier/agenda) qui ne tirent aucun parti du fait que la base de données soit relationnelle. Pour preuve, le wiki utilise uniquement le système de fichiers :-) Le gestionnaire de tâches n'a aucune liaison entre les tables, idem pour le calendrier. Les deux derniers pourraient donc utiliser tout aussi bien le système de fichiers, ou une base NoSQL, ou presque n'importe quel stockage (avec un moyen d'interrogation un poil pratique, forcément).
[^] # Re: pitié ...
Posté par fredix . Évalué à 1.
tu sous-entends que mongodb ne permet pas d'avoir des relations entre les documents, ce qui est faux, voir la doc de mongoid par exemple : http://mongoid.org/docs/associations ou mongomapper : http://railstips.org/blog/archives/2009/06/27/mongomapper-th(...)
Donc même avec des besoins relationnels légers, mongodb répond au besoin :)
[^] # Re: pitié ...
Posté par Kerro . Évalué à 3.
Non.
J'indique que la majeure partie des programmes n'utilise pas cela.
[^] # Re: pitié ...
Posté par yellowiscool . Évalué à 2.
Rien que sur ton message, il y a une relation évidente (ton message est relié à ton profil). Une autre relation est entre la news et les messages. C'est un exemple, mais cette application est pourtant simple.
Envoyé depuis mon lapin.
[^] # Re: pitié ...
Posté par Kerro . Évalué à 4.
Qu'est ce qui prouves que cette "relation évidente" est gérée par la base de données ?
Bon d'accord, il suffit d'aller voir le code :-) Pour les 3 exemples hyper courants que j'ai cité, il n'y a _aucune_ liaison gérée par la base de données. Pourtant ce sont des logiciels libres connus et maintenus. Et ça fonctionne.
Tu confonds la liaison logique, qui est dans le cerveau du programmeur, et la liaison codée en dur dans la base de données.
Si tu as deux tables SQL reliées par une clef, c'est une "vraie" relation.
Si tu as deux tables SQL tout court, la relation n'existe que virtuellement dans le programme. Et donc n'importe quel autre base de données sans cette relation fonctionne pareil.
[^] # Re: pitié ...
Posté par Julien . Évalué à 2.
[^] # Re: pitié ...
Posté par Kerro . Évalué à 5.
Si tu ne veux pas comprendre que la réalité n'a rien à voir avec les beaux principes, c'est ton affaire :-)
[^] # Re: pitié ...
Posté par Bruno Michel (site web personnel) . Évalué à 6.
Quand je relis mes propos, j'ai du mal à voir ce qui cloche. Je vais essayer de reformuler ça différemment.
L'idée est que la plupart des développeurs web ont besoin de stocker des données et prennent l'option la plus facile, en l'occurrence une base de données relationnelles, MySQL. Maintenant, si d'un coup, stocker ces données dans des fichiers yaml devenait trivialement simple, cela pourrait devenir le choix de beaucoup de développeurs (même si des fichiers yaml et une base de données relationnelles, ça n'est pas vraiment comparable). Il se trouve que je pense la même chose si on remplace "fichiers yaml" par "MongoDB (ou un équivalent)".
[^] # Re: pitié ...
Posté par kowalsky . Évalué à 6.
[^] # Re: pitié ...
Posté par Julien . Évalué à 2.
# En test sur unixfr.org, retour d'exp sur Overblog
Posté par Laurent Laborde (site web personnel) . Évalué à 5.
Au boulot on a aussi commencé à évaluer MongoDB pour http://www.over-blog.com, c'etait un peu la seule option NoSQL viable qui correspondait a peu près à nos besoins. Au final on l'a laissé de coté car postgresql est mieux adapté à notre infra ...
On reconsiderera l'option pour plus tard.
C'est pas comme si y'avait urgence, la mode NoSQL est encore jeune et le meilleur reste à venir :)
[^] # Re: En test sur unixfr.org, retour d'exp sur Overblog
Posté par Gniarf . Évalué à 2.
il revient et il n'est pas content.
[^] # HS: changement de slogan (blague)
Posté par Clément David (site web personnel) . Évalué à 1.
Pour les personnes ne voulant cliquer :
slogan = «Rails deployment that just works»
Titre de la page = «(X) Ruby on Rails application could not be started»
[^] # Re: HS: changement de slogan (blague)
Posté par Laurent Laborde (site web personnel) . Évalué à 1.
# Vous n'avez rien à faire ce weekend ?
Posté par yellowiscool . Évalué à 2.
Pouvoir participer au mouvement NoSql dès sa création est une chance incroyable, en plus en seulement deux jours, vous pouvez avoir un moteur qui est digne de se confronter aux autres.
Bon plus sérieusement, je trouve que ces nouvelles bases de données sont vraiment très légères, en termes de fonctionnalités. Ça remplace avantageusement une bidouille sur les fichiers, mais c'est un peu près tout. Surtout que l'utilisation du javascript pour manipuler les données n'est vraiment pas convainquant.
Je suis quand même allé voir le code source par curiosité: http://github.com/mongodb/mongo/tree/master/db/
Bon, il y a quand même du code, mais ça fait plus petit programme que moteur de base de données relationnelle. Ça donne envi de se lancer dans l'aventure quand on voit ça.
Envoyé depuis mon lapin.
[^] # Re: Vous n'avez rien à faire ce weekend ?
Posté par Bruno Michel (site web personnel) . Évalué à 2.
Par curiosité, quelles fonctionnalités attendrais-tu de MongoDB qui n'est pas déjà là ?
Pour ma part, je crains plutôt l'inverse : que MongoDB (ou les autres bases NoSQL) essayent de tout faire, mais le faire mal.
[^] # Re: Vous n'avez rien à faire ce weekend ?
Posté par yellowiscool . Évalué à 3.
Envoyé depuis mon lapin.
[^] # Re: Vous n'avez rien à faire ce weekend ?
Posté par Jul (site web personnel) . Évalué à 1.
On inventerait DBfs opur recycler les povres vieux mysql solitaires :
1 fichier = BLOB qui possède des attributs permissions droits et tout. On pourrait implémenter des droits qui n'existe pas encore.
Et on créerai aussi mogoFS tout accès au file system se ferait pour être sûr que ce soit bien long avec un webservice :)
Développeurs du dimanche ou pro souffrent du même atavisme : la maladie du sentier.
Les premiers préfèrent prendre les nouveaux sentiers et haïssent les sentiers battus, les deuxièmes préfèrent les sentiers battus et n'aiment pas les nouveaux.
Les problèmes d'entreprises sont malheureusement eux assez agnostiques des modes :)
# le mouvement NoSQL ...
Posté par paul . Évalué à 3.
Ce mouvement surf sur la frustration qu'on peut ressentir à devoir respecter tout un tas de contraintes pour aboutir à une structure validée, que ce soit un programme correctement typé ou une base de donnée avec des relations valides. C'est un peu, de façon générale, le mouvement noRTFM. On ne veut plus étudier et concevoir, on ne veut plus de contraintes statiques, on veut retarder au maximum le verdict, on veut des outils les plus souples possibles et puis après tout, si on a envie d'y mettre n'importe quoi on a le droit, on s'en rendra compte nous même. Peut-être un jour en production parce que, dans le meilleur des cas, le code plantera et dans le pire il donnera une info erronée parce que 1 + null == 1.
J'ai testé CouchDB et tenté de l'appliquer à un programme. Constat : c'est plus proche d'un système de fichier spécialisé que d'une base de donnée relationnelle. C'est pratique pour certains cas, je n'en doute pas, mais qu'on arrête de dire que ça va concurrencer des bases relationnelles. Si le résultat c'est que les scripteurs PHP qui subissaient le relationnel abandonnent tout simplement le relationnel au lieu de l'apprendre, ce ne sera pas vraiment un progrès :)
Ah, pour être tout à fait honnête, il y a un aspect qui m'a beaucoup séduit : la réplication. Je suis fan de décentralisé, donc j'aimerais que les BDD relationnelles proposent des mécanismes de réplications aussi simples que ce que propose CouchDB. Il suffirait probablement que les clefs primaires ne soient plus séquentielles. Savez-vous ce qui existe pour cela ?
[^] # Re: le mouvement NoSQL ...
Posté par Bruno Michel (site web personnel) . Évalué à 5.
Par contre, tu sembles penser que les langages statiques permettent d'écrire des applications plus fiables. Les études semblent au contraire montrer que le nombre de bugs est proportionnel au nombre de lignes de code et les langages dynamiques permettent généralement d'écrire un même code de manière plus courte. D'autre part, le vrai facteur qui améliore grandement la fiabilité d'un programme est la présence de tests. Les langages dynamiques proposent généralement des bibliothèques de tests bien plus avancées et pratiques à utiliser que celles pour des langages compilés. Mais, au final, peu importe que ce soit un langage statique ou un langage dynamique, un bon développeur écrira toujours du code de meilleure qualité qu'un développeur débutant (mieux testé, et donc plus fiable).
Tu sembles aussi sous-entendre que les "vrais" développeurs utilisent des langages statiques, alors que les langages dynamiques sont tout juste bons pour les scripteurs PHP du dimanche. C'est faux. De très bons développeurs utilisent des langages dynamiques par choix. Il suffit par exemple de regarder les sites à fort trafic pour croiser de nombreux exemples : facebook (PHP), twitter (Ruby), wikipedia (PHP), etc.
[^] # Re: le mouvement NoSQL ...
Posté par paul . Évalué à 2.
Sinon, je manipule régulièrement 3 langages : haskell, ruby et scheme. Ces deux derniers sont très proches, certes. De façon générale, j'écris nettement moins de lignes de code en haskell pour faire la même chose. La vérification statique est poussée et les performances sont incomparables avec les deux derniers. Ça me fait bien réfléchir, après 6 ans de ruby et 3 de rails ...
Enfin, je ne veux pas juger les développeurs, il y a mille contraintes dans les projets qui peuvent pousser à devoir utiliser telle ou telle techno. Mais je ne me gène pas pour juger les langages, et PHP en l'occurrence, est grossier, car il cumule tous les défauts de tous les langages, sans en avoir la moindre qualité :)
[^] # Re: le mouvement NoSQL ...
Posté par Bruno Michel (site web personnel) . Évalué à 3.
De mon expérience, compiler et lancer des tests sur un projet prennent souvent un temps comparable.
Sinon, concernant le typage statique, je considère que c'est une forme de tests que l'on t'oblige à écrire. Mais je considère que ce sont des tests assez mauvais et quitte à passer du temps à écrire des tests, je préfère en écrire qui soient pertinents. Par contre, le typage statique a un effet de bord très intéressant : les performances.
Pour le développement d'applications web, les performances sont souvent une considération secondaire. On cherche plutôt la vitesse de développement, et là, les langages dynamiques sont souvent très efficaces. Et le typage statique n'apporte souvent pas grand chose en terme de fiabilité, car une très grande partie des objets manipulés sont de toute façon des chaînes de caractères.
[^] # Re: le mouvement NoSQL ...
Posté par paul . Évalué à 1.
c'est long à compiler certainement, mais à la fin t'as du code machine, donc la valeur ajoutée de la compilation ne se limite pas à l'analyse statique. Le facteur de gain en vitesse d'exécution entre une implem ruby MRI 1.9 et Haskell GHC 6.10 est de l'ordre de 50 en moyenne ... Je suis prêt à attendre 3 minutes que mon projet compile pour un tel gain. Le gain en mémoire est considérable également. Mon job est de développer et d'héberger des applis en RoR. Quand je vois comme c'est lent et tout ce que ça mange comme mémoire, malgré l'utilisation de toutes les optimisations possibles, je ne trouve pas que ce soit un problème secondaire.
Le temps requis pour aboutir à du code fonctionnel à 90% est inférieur en ruby qu'en haskell. Mais je pense que le temps pour aboutir à 99% est inférieur en haskell qu'en ruby ;)
Enfin, un système de types tel que celui de Hindley-Milner (cf journal récent) permet d'exprimer une grande partie de la logique de ton programme avec des types. Peu importe si la représentation sous-jacente est à chaque fois une chaîne de caractères, tu peux définir un type nom, un type prénom et un type numéro de téléphone, et l'analyse validera leur utilisation dans ton programme.
[^] # Re: le mouvement NoSQL ...
Posté par Bruno Michel (site web personnel) . Évalué à 5.
Tu t'appuies sur quoi pour dire ça ? Si ce sont des micro-benchmarks à la shoutout, ça ne veut rien dire (cf http://shootout.alioth.debian.org/flawed-benchmarks.php ).
> Je suis prêt à attendre 3 minutes que mon projet compile pour un tel gain.
Moi aussi, mais avant d'en arriver là, il aura fallu coder pendant des dizaines d'heures. Et coder avec des langages dynamiques va généralement bien plus vite qu'avec des langages statiques. Quand je fais du développement web, je préfère la vitesse de développement aux performances.
> Mon job est de développer et d'héberger des applis en RoR. Quand je vois comme c'est lent et tout ce que ça mange comme mémoire, malgré l'utilisation de toutes les optimisations possibles, je ne trouve pas que ce soit un problème secondaire.
Je développe également des applications Rails. Certaines d'entre elles font des millions de visites par mois, tournent sur un seul serveur dédié et le goulot d'étranglement n'est jamais Ruby mais la base de données.
> Mais je pense que le temps pour aboutir à 99% est inférieur en haskell qu'en ruby ;)
Ouais, c'est connu, les programmes en haskell, ça court les rues. Le seul programme en haskell que je connais, c'est darcs, et il est connu pour deux choses : être le meilleur DVCS sur le papier, et avoir des performances qui varient entre le meilleur et le pire sans que personne ne sache trop pourquoi.
[^] # Re: le mouvement NoSQL ...
Posté par lasher . Évalué à 3.
Petit aparté : un « bon développeur » peut parfaitement être débutant. Un « mauvais développeur » peut aussi être un « développeur senior ». Bien entendu, l'expérience joue pour devenir meilleur, mais honnêtement, un bon développeur, même avec des habitudes de développement à parfaire [1], est souvent clairement bon dès le départ.
[1] Je pense à des habitudes de présentation de code, d'utilisation d'outils et de tests unitaires pour tester ledit code, etc., bref de choses qu'on apprend soit en cours, soit (plutôt) avec l'expérience.
[^] # Re: le mouvement NoSQL ...
Posté par claudex . Évalué à 3.
Ce que tu oublies (et qui a été décris plus tôt), c'est qu'actuellement, beaucoup de programmes ne tiennent pas compte de la partie relationnelle. Ce qui fait que des bases non relationnelles sont effectivement mieux adaptées à ces programmes.
C'est pour cela qu'on dit que cela va (peut-être) remplacé MySQL, car beaucoup d'applis web n'utilise pas le relationnel. Les bases de données ne sont pas une concurrences des bases de données relationnelles mais des bases de données tout court (ce qui inclus les bases de données relationnelles).
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
# Voici un exemple de site utilisant mongodb 1.4 en production
Posté par Olivier BONNAURE . Évalué à 2.
Je me suis intéressé assez tôt à mongodb pour sa possibilité de scaler facilement horizontalement...
Je travaille sur http://solimap.com qui est un site utilisant mongodb 1.4 et Ruby on Rails.
Bien entendu on aurait pu faire la même chose avec MySQL ou PostgreSQL mais j'ai voulu créer une appli utilisant cette nouvelle base de données noSQL pour pouvoir tester en live.
Résultat :
Et bien les perfs sont bonnes, et j'ai presque envie de ne coder qu'avec ce genre de base de données maintenant ... Je trouve qu'il y a beaucoup de souplesse avec ce genre de bases.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.