• # Mongo sapin

    Posté par . En réponse au journal A quoi peut servir couchdb ?. Évalué à 4.

    Je me pose la même question.
    Par contre avec MongoD http://www.mongodb.org/ , car Mongo me semblait plus abouti lors de mon étude préalable. Et surtout des drivers sont disponibles pour de nombreux langages de toutes sortes (typé statiquement, dynamiquement, etc.)

    Donc, je fais joujou avec mongo. Mes premieres impression:

    - c'est simple ...: pas de prises de tête, installation facile, utilisable sans peine après installation du driver pour son langage favoris.
    - mais pas simpliste : on peut poser ses propres index, le langage de requête est assez riche.

    Comme intérêt, ça reste flou pour moi. Mais j'entrevois quelques points à mons avis interessants.

    Cela permet facilement de distribuer ses données, voir de répartir la charge sur plusieurs machines. Ca n'est qu'une intuition.

    Le côté non structuré est déstabilisant. Mon premier réflexe fut de créer un mini mapper typé, pour avoir quelque part une sécurité dans le typage. Et puis j'ai réfléchi, et je me suis dit que c'était aller à l'encontre de l'esprit. Donc j'ai créé un petit utilitaire qui me permet de créer un proxy sur un objet Mongo, lorsque je veut l'utiliser de manière plus structurée, tout en gardant le côté générique lorsque c'est utile.

    La généricité, c'est aussi un point qui me semble important. Mongo permet des traitements génériques beaucoup plus simplement qu'une base SQL. Si vous avez déjà utiliser JSON, ou bien même Scheme ou Lisp, vous devez avoir une idée de quoi je parle.
    De plus le mismatch entre Mongo et les langages objet me semble moins important qu'avec une base SQL.


    En résumé, je dirai l'impression pour le programmeur doit être assez proche lorsqu'il passe d'une base relationnelle à Mongo, que lorsqu'il passe de Java à Python ou Ruby.

    On y gagne une grande souplesse et puissance, et donc aussi une grande responsabilité.