Bonjour.
Depuis quelques temps, je vois beaucoup d'articles cà et là à propos de couchdb. Pour ma part, j'ai un peu de mal à voir dans quel cas ce type de base de données peut servir. En effet, si j'ai bien compris, on peut stocker un peu tout et n'importe quoi de façon plus ou moins structuré .... Or c'est une façon de faire que je ne maitrise pas trop. Et vous, voyez-vous dans quels cas ce gestionnaire de bases de donnéres pourrait avoir son utilité ? Le premier truc qui me vient à l'esprit et de loin, c'est la GED, mais bon, je n'ai pas trop d'expérience dans ce domaine ....
Journal A quoi peut servir couchdb ?
18
fév.
2010
# Moi, j'ai bien une idée...
Posté par windu.2b . Évalué à 10.
on peut stocker un peu tout et n'importe quoi de façon plus ou moins structuréÇa pourrait s'interfacer comme base de stockage pour un projet LA RACHE !
# J'ai trouvé un site plein de références
Posté par dave . Évalué à 2.
[1] http://nicolas.steinmetz.fr/journal/post/2009/06/14/CouchDB-(...)
Systemd, the bright side of linux, toward a better user experience and on the road to massive adoption of linux for the desktop.
[^] # Re: J'ai trouvé un site plein de références
Posté par totof2000 . Évalué à 4.
[^] # Re: J'ai trouvé un site plein de références
Posté par jhc_ . Évalué à 6.
En gros, tu peux tout à fait modéliser tes données sous forme de hash pour ton application métier et il se trouve que ces DB visent à stocker sous cette forme tes données.
C'est plus souple, plus simple et en plus ce genre de DB vise à s'héberger facilement sur du cloud. Par contre, c'est assez déroutant après autant d'années de SQL, pas rassurant pour les clients.
Faut imaginer un peu sur une application genre au hasard hein, un truc social kikoo communautaire, qui évolue énormément le coût d'un changement de schema, qui ici est inexistant du coup. FriendFeed par exemple utilise une couche ORM schema-free au dessus de MySQL.
Par contre, dans tout ce qui est grosse base de données au sens classique du terme ( banques et autres ) c'est tout sauf adapté. Pour le reste, mon avis personnel est que cela a clairement du sens.
Après ya une grosse hype autour du mouvement NOSQL, il faut rester pragmatique et bien cerner les besoins avant de s'orienter vers ce genre de solutions.
[^] # Re: J'ai trouvé un site plein de références
Posté par totof2000 . Évalué à 3.
Un peu comme Berkeley DB ? A ceci près que couchdb est en plus concu pour gérer efficacement les accès concurents ainsi que, si j'ai bien compris la gestion "distribué" de la base.
C'est plus souple, plus simple et en plus ce genre de DB vise à s'héberger facilement sur du cloud. Par contre, c'est assez déroutant après autant d'années de SQL, pas rassurant pour les clients.
Je pense surtout que c'est pas adapté pour la plupart des bases stockées actuellement en SGBDR, mais que ça peut être utile pour des cas ou le SGBDR/SQL montre ses limites et oblige à avoir un schéma de base de données ultra complexe.
Après ya une grosse hype autour du mouvement NOSQL, il faut rester pragmatique et bien cerner les besoins avant de s'orienter vers ce genre de solutions.
C'est d'ailleurs la raison de mon post : de toutes mes lectures sur le sujet je n'ai jamais vu vraiment de cas ou un tel gestionnaire s'imposerait naturellement, mais peut-être que si un jour je veux implémenter mon propre moteur de wiki, j'y viendrai naturellement.
[^] # Re: J'ai trouvé un site plein de références
Posté par barmic . Évalué à 2.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: J'ai trouvé un site plein de références
Posté par Bruno Michel (site web personnel) . Évalué à 3.
Au contraire, pour les vraiment grosses bases de données, les bases NoSQL conviennent bien. De ce coté, on parle beaucoup moins de CouchDB, MongoDB, Riak, mais hbase/hadoop, cassandra et voldermort ont clairement la côte. J'ai entendu parler d'une société française dans le monde de la finance qui utilise voldemort pour traiter des petabytes de données.
[^] # Re: J'ai trouvé un site plein de références
Posté par Larry Cow . Évalué à 2.
On ne doit pas prononcer son nom!
(pardon)
[^] # Re: J'ai trouvé un site plein de références
Posté par Mali (site web personnel) . Évalué à 1.
http://www.youtube.com/watch?v=Bfje5csISQ8
# Plus de partie serveur
Posté par Johann Ollivier-Lapeyre (site web personnel) . Évalué à 4.
1) Une partie "cliente", en JS, qui GET/POST/PUT/DELETE des objets en Json avec le serveur
2) Une partie serveur (en Django, Turbogears, Ruby on rails, Grails...) qui offre une api REST en Json au niveau Controlleur, utilisant des objets metiers, mappé tant bien que mal sur une base de donnée relationnelle.
L'interet de couchdb, c'est qu'on peut potentiellement zapper toute la partie 2, le javascript interroge directement la base.
[^] # Re: Plus de partie serveur
Posté par totof2000 . Évalué à 3.
A priori pour un wiki, par exemple c'est l'idéal : la base stocke directement les documents, et on interroge directement la base pour les récupérer/les mettre à jour, etc .... Je vois aussi bien ce genre de base pour stocker des documents (j'ai un tas de docs techniques PDF divers et variés). En réfléchissant plus loin, on pourrait aussi s'en servir pour stocker des photos .... Par contre, je me demande comment organiser tout ça, en raison du manque de structuration apparente de l'engin.
[^] # Re: Plus de partie serveur
Posté par HardShooter . Évalué à 4.
[^] # Re: Plus de partie serveur
Posté par totof2000 . Évalué à 1.
[^] # Re: Plus de partie serveur
Posté par windu.2b . Évalué à 10.
[^] # Re: Plus de partie serveur
Posté par totof2000 . Évalué à 5.
[^] # Re: Plus de partie serveur
Posté par Larry Cow . Évalué à 3.
[^] # Re: Plus de partie serveur
Posté par HardShooter . Évalué à 2.
[^] # Re: Plus de partie serveur
Posté par Thomas Douillard . Évalué à 2.
En fait ça a l'air d'être un peu comme XML : c'est fait pour le semi-structuré.
Si tu reprends l'exemple de tes images, ça doit pouvoir permettre de les organiser en album / sous albums, de rajouter des commentaire et de placer les photos un peu comme tu veux pour avoir un truc sympa et moins rigide que le classement en album/tag à la picasa par exemple ...
La structure, c'est l'utilisateur qui peut la faire comme il le veut, comme sur un wiki, c'est ça le principal intérêt que je peux y voir ... tout en gardant la possibilité de faire des requêtes sur les photos ?
[^] # Re: Plus de partie serveur
Posté par totof2000 . Évalué à 6.
Oui, mais un SGBDR aussi peut être utilisé pour stocker des documents :).
En fait ça a l'air d'être un peu comme XML : c'est fait pour le semi-structuré.
Oui, un peu comme le XML quoique je le vois même un peu moins rigide que le XML.
Si tu reprends l'exemple de tes images, ça doit pouvoir permettre de les organiser en album / sous albums, de rajouter des commentaire et de placer les photos un peu comme tu veux pour avoir un truc sympa et moins rigide que le classement en album/tag à la picasa par exemple ..
C'est effectivement comme ça que je le vois. Mais j'ai l'impression que ce genre de gestionnaire de BDD est l'outil idéal pour "perdre" des documents dans la base (perdre dans le sens ou je ne saurais plus y accéder, parce que le document en question utilise des clés qui ne sont plus utilisées par les autres documents du même type, et que j'ai oublié comment à l'origine celui-ci était défini).
La structure, c'est l'utilisateur qui peut la faire comme il le veut, comme sur un wiki, c'est ça le principal intérêt que je peux y voir ... tout en gardant la possibilité de faire des requêtes sur les photos
Oui mais le risque au fil du temps c'est de se retrouver avec des photos que l'on ne "trouverait plus" parce que les critères de sélection/rangement auraient changé ... Je me trompe peut-être mais c'est un des inconvénients que je note. En gros ce genre de système de BDD me fait penser à la pile de documents non classés que j'ai sur mon bureau : ce sont des feuilles de papier qui trainent sur mon bureau. Après pour savoir ce qu'il y a dedans, je suis obliger de fouiller pour identifier ce que c'est..
[^] # Re: Plus de partie serveur
Posté par Thomas Douillard . Évalué à 2.
Si tu changes les critères de rangements, deux choses : à mon avis tu peux faire le changement de critères automatiquement avec un script par exemple, et tu peux archiver la version d'avant au besoin.
De plus : le fait que l'information soit "en contexte" dans un document fait que pour le retrouver t'as pas forcément besoin de te souvenir exactement ou il est, mais de te rappeler du/des contextes dans lesquels tu aurais pu l'utiliser, par association d'idée tu devrai retrouver ton document sans trop de soucis en cherchant le contexte approprié.
Pour le bureau, effectivement ça peut être le bordel, sauf que là si tu te démerde bien tu peux faire des requêtes sur ton bureau sans déplacer toutes tes piles de papiers, et que tu peux placer un document dans plusieurs contextes différents si tu veux.
[^] # Re: Plus de partie serveur
Posté par totof2000 . Évalué à 2.
Je cherche à référencer les serveurs que je gère. Les serveurs ont un certain nombre de caractéristiques "logiques" identiques (hostname, adresse IP, disques, etc ..."), par contre le côté physique du serveur peut pêtre totalement différent. Un serveur peut être une machine standalone, une partition d'un complexe partitionnable (exemple les superdomes HP, ou les serveurs SUn style 25k), ça peut être une VM, et si on veut représenter la couche physique, on se retrouve avec des modèles totalement différents et qu'on ne peut représenter de façon simple dans un SGBDR. Je cite ce qui m'a fait tilter (voir http://www.couchdb-fr.net/introduction pour l'exemple ) :
Contrairement aux bases de données SQL qui sont conçues pour stocker et rendre compte de données très structurées et liées entre elles, CouchDB est conçu pour stocker et rendre compte de grandes quantités de données semi-structurées, orientées document. CouchDB simplifie grandement le développement d'applications orientées document, qui constituent l'essentiel des applications web collaboratif.
Le schéma évolue avec les besoins et dans une base de données SQL, le stockage des données existantes doit être mis à jour pour coller au schéma. Cela provoque souvent des problèmes dès que de nouveaux besoins apparaissent qui n'étaient tout simplement pas prévu dans le design initial de la base de données, et, pour les systèmes distribués, cela rend les mises à jour problématiques pour chaque hôte qui doit passer par une mise à jour du schéma.
Avec CouchDB, aucun schéma n'est appliqué, de sorte que de nouveaux types de documents, avec un sens nouveau, peuvent être ajouté en toute sécurité aux côtés des anciens. Le moteur de vue, en utilisant Javascript, est conçu pour manipuler facilement des nouveaux types de documents, des documents disparates… mais qui restent de simples documents.
Faut que je creuse ça ..... Avec Ruby et sa possibilité de créer/modifier des classes à la volée, ça risque d'être intéressant.
[^] # Re: Plus de partie serveur
Posté par yapoc . Évalué à 4.
Je n'avais jamais entendu parler de couchDB, je pense que je me documenterai rapidement à son sujet. Par contre, je pratique un peu la philosophie REST + XML sur mon projet actuel, et pour peu que ça se rapproche un minimum du sujet du journal, voici ce que j'en pense...
Le projet, c'est une application web. On récupère des flux en entrée, on en affiche un formatage à l'écran, l'utilisateur les enrichit éventuellement, on crache un flux en sortie. En gros, c'est juste un projet informatique de SSII.
L'architecture nous a imposé de faire du REST, avec un SILO (partie données) et un PILOTE (IHM / BATCHs). Les données transitant entre les deux sont un flux ATOM / xHTML. Voilà pour le contexte.
Dans la pratique, on a une base de données MySQL qui stocke les ATOM dans un champ BLOB, avec une colonne idtech et une autre dateMiseAJour. Basta. On souhaite faire évoluer le modèle de données? Aucun problème de changement de modèle à coups d'ALTER TABLE. La reprise de données? De toute manières, on est plus ou moins obligé d'utiliser un langage de haut niveau, on peut donc appliquer des règles métier évoluées sans "trop" s'embêter (XML parsing inside, SQL souvent insuffisant). Voilà pour les avantages.
En ce qui concerne les inconvénients, on retrouve une complexité accrue à mettre en place des objets métier (avec getter et setter par champ; toutes les données étant gérées dans du XML, beaucoup de xPath, pas mal de DOM; technologie peu maîtrisée (uniquement sur le projet???)). Et puis en général, qui dit IHM dit tris ou rechercher. On se retrouve donc peu à peu à "externaliser du BLOB" certains champs xPath dans des colonnes de la base de données. D'où duplication d'information, difficulté accrue à maintenir la cohérence des données qui sont dupliquées, etc.
J'y vois effectivement une grosse plu-value quant l'objectif de l'application utilisant cette base de données est principalement de restituer des données, peu modifiées. Il suffit alors de faire un select, une petite XSL, et c'est tout.
En espérant que ce que j'ai raconté ait un quelconque intérêt et / ou rapport avec la choucroute...
[^] # Re: Plus de partie serveur
Posté par djano . Évalué à 2.
Jette un coup d'oeil a http://www.unixgarden.com/index.php/web/couchdb-la-base-de-d(...) .
[^] # Re: Plus de partie serveur
Posté par _PinG _ . Évalué à 1.
Le projet ne serait pas pour un grand groupe publique en passe de devenir privé?
[^] # Re: Plus de partie serveur
Posté par Thierry Thomas (site web personnel, Mastodon) . Évalué à 1.
Dans ce genre de cas, on peut toujours modéliser de façon classique avec une entité des caractéristiques et une entités des valeurs associées aux caractéristiques. Au niveau des tables, ça peut revenir simplement à avoir une table permettant de stocker des paires (caractéristiques, valeurs), comme on pourrait le faire dans une structure XML, tout en ayant l'avantage de pouvoir la manipuler et la requêter en SQL.
[^] # Re: Plus de partie serveur
Posté par totof2000 . Évalué à 2.
[^] # Re: Plus de partie serveur
Posté par BAud (site web personnel) . Évalué à 3.
une recherche rapide avec open cmdb donne quelques résultats
http://www.onecmdb.org/wiki/index.php?title=Main_Page
http://sourceforge.net/projects/i-doit/
http://www.cmdb.info/pd1/html/modules.php?op=modload&nam(...)
http://sourceforge.net/softwaremap/trove_list.php?form_cat=6(...)
tu peux peut-être regarder du côté de Eyes Of Network http://linuxfr.org/2010/02/08/26452.html ou ]project-open[ http://linuxfr.org/2009/11/26/26193.html (même si cela a l'air plus opérationnel que ce que tu cherches).
[^] # Re: Plus de partie serveur
Posté par totof2000 . Évalué à 2.
[^] # Re: Plus de partie serveur
Posté par Larry Cow . Évalué à 4.
Avec une couche SQL, c'est normalement à la base de données t'imposer la structure à ton code. Ce qui était particulièrement utile pour les grosses DB centralisées d'entreprise, où chaque service tape dedans à sa guise sans forcément consulter ses petits copains avant. Fut un temps, le SQL était l'interface, et chacun développait dessus. L'utilisateur était développeur, en un sens.
Sauf qu'aujourd'hui, le SQL disparaît de plus en plus derrière des couches d'abstraction, on voit des bases de données servir de manière complètement mono-utilisateur - et je ne parle pas du serveur de DB, mais bien de la DB elle-même : quand une application PHP est la seule à taper sur sa base de données, que le développeur est obligé de faire le grand écart pour conserver une cohérence de schéma entre sa base et son code, on peut légitimement se demander l'intérêt du SQL.
On n'est plus au XXè siècle : le SQL n'est plus une interface frontale, mais tend plutôt à se voir reléguée aux arrière-boutiques. Dans ces conditions, c'est peut-être à la fois une bonne raison et une bonne occasion pour regarder ce qui se fait à côté, non?
# Erreur
Posté par アントニ ドミ . Évalué à 5.
# Les perfs.
Posté par ndv . Évalué à 2.
Grosso modo, dans le monde classique, si un serveur d'application ramait, il suffisait d'en mettre un second en parallèle pour avoir des perfs proches de ce que l'on avait fois deux. Pour les serveurs de base de données, par contre, c'est beaucoup moins évident... Les données doivent être répliquées, rendant le tout moins intéressant.
Avec une base de données CouchDb, les perfs de deux serveurs s'approchent du fois 2... Ce n'est pas pour rien que de nombreux sites avec de très nombreuses connexions simultanées utilisent un système de ce type (gmail, amazon, linkedin...)
Et puis, faire des requêtes en Javascript, c'est quand même bien plus marrant que de faire du SQL ;-)
[^] # Re: Les perfs.
Posté par barmic . Évalué à 4.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Les perfs.
Posté par Bruno Michel (site web personnel) . Évalué à 3.
# Base de Données Orienté OBJET
Posté par NeoX . Évalué à 3.
un objet a un identifiant,
ensuite il a simplement des propriétés
tu te fous de savoir si c'est un utilisateur (à stocker dans la table des utilisateurs), un post (à mettre dans la table des posts)...
tu envoie ton objet à la base.
ensuite pour lire les infos, tu cherches les objets qui ont la propriété "utilisateurs"
pour trouver les utilisateurs
# La question que je me pose
Posté par blackshack . Évalué à 2.
Cela me parait incroyablement gourmand. Hors null part j'ai vu parler de champs indexable.
[^] # Re: La question que je me pose
Posté par LeJulien . Évalué à 1.
Le fait de parcourir la base n'implique pas une instanciation des objets, donc c'est pas forcement plus gourmand. Ou j'ai rien capté...
[^] # Re: La question que je me pose
Posté par LeJulien . Évalué à 2.
[^] # Re: La question que je me pose
Posté par NeoX . Évalué à 2.
[^] # Re: La question que je me pose
Posté par blackshack . Évalué à 1.
[^] # Re: La question que je me pose
Posté par Thomas Douillard . Évalué à 2.
Ca sert à stocker des arbres sur les disques durs, typiquement pour indexer des bdds ou des systèmes de fichiers. En gros l'idée c'est que sur un disque dur tu lis et écris des clusters qui sont les unités. La taille d'un noeud de l'arbre est déterminée par la taille de ces clusters.
Arbre_B
[^] # Re: La question que je me pose
Posté par Bruno Michel (site web personnel) . Évalué à 3.
Oui et non. Il n'y a pas à proprement parler d'index, mais les views remplissent un rôle similaire et permettent d'avoir des performances tout à fait correctes.
[^] # Re: La question que je me pose
Posté par MrLapinot (site web personnel) . Évalué à 2.
[^] # Re: La question que je me pose
Posté par Thomas Douillard . Évalué à 2.
[^] # Re: La question que je me pose
Posté par MrLapinot (site web personnel) . Évalué à 2.
[^] # Re: La question que je me pose
Posté par Thomas Douillard . Évalué à 2.
Ou si tu connais l'identifiant que tu recherche, et que sa position dans la base dépend uniquement de cet identifiant, ce qui n'est pas forcément gagné non plus.
# Mongo sapin
Posté par パパフラクス . Évalué à 4.
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é.
[^] # Re: Mongo sapin
Posté par Bruno Michel (site web personnel) . Évalué à 4.
Pour ce qui est des avantages du MongoDB sur les bases de données relationnelles, ils sont nombreux et je ne vais en citer que quelques uns :
- pas de schéma, et donc pas de migrations pour modifier le schéma
- les types composés (tableau et hash) sont bien pratiques
- c'est impressionnant de rapidité (en comparaison MySQL se traîne comme un escargot)
- on peut ajouter des index sans tout bloquer pendant des heures (http://www.mongodb.org/display/DOCS/Indexing+as+a+Background(...)
- ça supporte bien de grosses quantités de données.
Pour encore plus d'avantages, vous pouvez lire ce retour d'expérience : http://www.businessinsider.com/how-we-use-mongodb-2009-11
Et pour ceux qui ont envie de tester, il existe une démo en ligne : http://mongo.kylebanker.com/
Je me permets également de citer un billet écrit par un de mes collègues sur le sujet : http://dev.af83.com/mongodb/pourquoi-choisir-mongodb/2010/01(...)
[^] # Re: Mongo sapin
Posté par パパフラクス . Évalué à 1.
Mongo plus proche de SQL? Tu peux développer?
Pas de migration pour le schema, certe, mais j'imagine que tes données, tu dois les migrer quand même? Sinon je n'imagine même pas la tête du code applicatif pour gérer le bordel!
Bon ok, quand tu ne fait qu'ajouter des champs, tu peux t'en tirer sans migration, mais sinon?
[^] # Re: Mongo sapin
Posté par Bruno Michel (site web personnel) . Évalué à 2.
Ça se discute. Il y en a un paquet sur http://linuxfr.org//2009/05/05/25414.html.
> Mongo plus proche de SQL? Tu peux développer?
Quand on veut aller chercher des données dans MongoDB, on écrit une requête qui ressemble à une requête SQL. Par contre, pour CouchDB, il faut d'abord comprendre le système de map-reduce (et rereduce). Quand j'ai commencé à utiliser MongoDB, au bout de 5 minutes, j'avais compris comment faire des requêtes assez simples. Par contre, il m'a fallu un paquet de temps pour comprendre le map-reduce de CouchDB (et encore, je ne l'ai toujours pas totalement assimilé).
> Pas de migration pour le schema, certe, mais j'imagine que tes données, tu dois les migrer quand même?
Oui, bien sûr, mais ça reste un cas assez rare. Dans beaucoup de cas, les migrations SQL que je fais consistent surtout à ajouter une nouvelle table ou à ajouter une nouvelle colonne avec NULL comme valeur par défaut. Et pour faire l'équivalent à MongoDB, il y a juste rien à faire.
C'est aussi particulièrement agréable pendant la phase de développement.
[^] # Re: Mongo sapin
Posté par パパフラクス . Évalué à 1.
Au sujet des liens, je te suggère d'essayer de cliquer sur les liens de tes posts précédents! ;)
[^] # Re: Mongo sapin
Posté par Bruno Michel (site web personnel) . Évalué à 2.
Rah, bien vu. C'est parti pour aller corriger ça dans la base de données...
# Un exemple
Posté par Bruno Michel (site web personnel) . Évalué à 4.
Nous avons donc des artistes, des fiches sur les œuvres d'arts, des périodes historiques, des lieux, et des relations entre tous ces objets (du genre tel tableau a été inspiré par le travail de tel artiste). Chaque fiche comporte des informations qui doivent notamment permettre des recherches. Ces informations rentrent plus ou moins bien dans des champs. Par exemple, si on prend le champ 'dimensions', il ne sera pas rempli de la même façon pour un tableau (2 dimensions) que pour une statue (3 dimensions). Pour les dates, nous avons parfois quelque chose de très précis (le 11/02/1827) ou au contraire de très imprécis (environ 400 ans avant JC). Enfin, il y a une multitude de champs possibles, mais généralement qu'une petite partie de ceux-là sont remplis. Cela vient notamment du fait que selon le type de l'œuvre, de nombreux champs ne sont pas pertinents : le champ "encadrement" s'applique bien à un tableau, mais pas vraiment pour une statue. Il arrive également qu'un champ est généralement une seule valeur, mais que dans certains cas ait plusieurs valeurs. Par exemple, on pourrait avoir plusieurs dimensions pour une œuvre qui serait en plusieurs parties.
Au final, si on avait essayé de faire rentrer toutes ses informations dans une base de données SQL, je vous laisse imaginer le nombre monstrueux de tables qu'il aurait fallu (ou alors, une quantité folle de colonnes et de NULL dans ces colonnes), et récupérer une fiche aurait nécessiter une requête SQL d'une complexité que je ne préfère pas imaginer. Nous nous sommes tournés vers CouchDB qui nous a permis de faire ça efficacement. Nous ne regrettons absolument pas ce choix, mais si nous avons rencontrés quelques défauts de jeunesse de CouchDB.
[^] # Re: Un exemple
Posté par Paf . Évalué à 2.
Si oui, qu'est-ce qui a fait pencher la balance vers couchdb ?
[^] # Re: Un exemple
Posté par Bruno Michel (site web personnel) . Évalué à 2.
# Persevere
Posté par gazbhan . Évalué à 3.
C'est drôle comme personne ne parle de persevere, qui fonctionne très bien, et permet à une appli web de dialoguer directement (via une API REST) à une base de données.
Bon, ok, par rapport aux autres y'a un peu un schéma de données (facultatif, suivant JSON Schema), mais ça marche du feu de dieu!
http://www.persvr.org/
[^] # Re: Persevere
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)
# Sécurité coté client
Posté par Frédéric Massot (site web personnel) . Évalué à 2.
Comment sont effectués les contrôles de sécurité, le filtrage des données ?
Le code javascript étant coté client, il peut être modifié par le client ?
C'est la base de données qui fait les contrôles ?
[^] # Re: Sécurité coté client
Posté par blackshack . Évalué à 2.
De toute façon quelle que soit la technologie utilisé ne jamais mettre d'accès directes au DATA. Toujours mettre une couche tampon pour gérer entre autre la sécurité mais aussi tout autre chose.
# Question bête
Posté par sifu . Évalué à 2.
Par contre, j'avoue ne pas avoir compris comment on pouvait faire des requêtes un peu complexes. Genre, je voudrais les entrées d'un blog du 1 janvier au 12 janvier de la catégorie 'linux' et de l'auteur 'edouard'.
J'avais vu que l'on devait faire des vues et des clefs 'tableaux' mais cela m'avait semblé complexe (enfin relativement).
Est-ce que quelqu'un pourrait m'orienter un peu sur le sujet ?
Merci.
[^] # Re: Question bête
Posté par Maxime G (site web personnel) . Évalué à 4.
Une vue (ie un index) avec comme clé : [ categorie , auteur, date ]
map = function(doc) {
emit( [doc.Category, doc.Author, doc.Date] , null);
}
et pas de reduce
appel avec start_key=["Linux", "Edouard", "2010-01-01"]&end_key=["Linux", "Edouard", "2010-01-12"]
Il faut se dire qu'on va créer un index, cad un ensemble de couple (clé,valeur) et ça sera stocké trié par clé. Donc quand on requête sur la vue (cad sur l'index) on requête par rapport à la clé.
C'est la seule manière de faire qui soit efficiente. Une vue temporaire est souvent inadmissible (car ça va tout reparcourir les documents, alors que dans une vue normal, à chaque appel on parcourt que ce qui a changé, donc c'est potentiellement très très très rapide).
Donc, dans la plupart des cas, faut penser un peu en mode je dois faire une requête SQL qui utilise complètement UN index.
(Faudrait que je finisse cette page : http://www.couchdb-fr.net/decouvrir/exemple-blog )
--------------------
Pour les autres qui se pose des questions de l'intérêt, je vais donner le mien (entres autres) :
Par exemple, comment stocker en base une facture ?
MySQL : 1 table facture + 1 table facture_lignes + clés étrangères
CouchDB :
{
...
"client": "Bill Gates",
"lignes": [
{ "Produit": "Support Linux (1/2j)", "Quantité": 10, "Prix": 500 },
{ "Produit": "Porte clé Manchot", "Quantité": 1, "Prix": 2.99 }
],
"Total": 5002.99
}
(Tout ce qui est mettable en JSON est enregistrable dans CouchDB...)
[^] # Re: Question bête
Posté par wilk . Évalué à 3.
[^] # Re: Question bête
Posté par Maxime G (site web personnel) . Évalué à 2.
La tentation est grande quand on se met à un outil de vouloir tout faire avec (et de vouloir évangéliser à tout prix).
CouchDB n'est pas le Saint Graal loin de là.
Des exemples de "vis" :
- numéros séquentiels (le genre auto_increment)
- requêtes SQL : on se rend vraiment compte du confort de MySQL quand on a à faire des requêtes "dynamiques" du genre lister des trucs avec des filtres activables (contient, commence par, de ... à ... , ...) ou non sur chaque champs, plus un tri choisi sur n'importe lequel des champs
Ce qui peut séduire vraiment c'est :
- l'aspect document : toujours pour ma facture : en un document je stocke ma facture avec tout ce qui la compose (les lignes.... et aussi par exemple des infos clients (adresse...) puisqu'une facture est censée être figée une fois validée*) plus l'historique des modifications (qui a fait quoi, qui à validé...) plus éventuellement le PDF généré (vu qu'on peut attacher des fichiers).
- les vues : sortons des factures. Je peux avoir une vue (indexée donc) qui me donne un état de stock à partir des mouvements réalisés. Car on peut vouloir ne connaître l'état du stock qu'à partir des mouvements sans stocker la quantité dispo dans une table (après il y a des contraintes d'intégrité...). Avec une bonne vue, on a ce qu'on veut, de manière indexée. Et le recalcul est partiel à chaque appel, on ne reparcourt que les doc modifiés.
- la réplication : parfait pour des applis avec un mode déconnecté...
Après, il faut faire un choix conscient, considérer ses besoins et évaluer la portée (niveau atomicité par exemple...)
Les vues peuvent être une très grosse contrainte. Il faut faire ça bien dès le départ. Avec MySQL, on peut faire des requêtes de malade qui vont très bien tourner jusqu'à 10000 enregistrements (avec du parcours complet...), mais qui dès 100000 enreg va commencer à devenir longue... Et donc on peut être amené à repenser la requête pour utiliser des index qu'on va créer spécialement pour cette requête... Je vais pas entrer dans les détails, je dirais que cet extraordinaire moteur de requête de MySQL** peut être à double tranchant.
Je dirais que pour les vues, il manque encore du map-reduce en série. Pour l'instant on ne peut en faire qu'un seul.
* : avec le principe de la clé étrangère seule, on peut avoir des surprises.
Un exemple simplet mais parlant : imaginons que dans les lignes de la facture j'ai un champs produit avec une clé étrangère. Je récupère le prix (via une jointure ou pas) dans la table produit. Je crée une facture, avec le produit X qui a le prix Y. Je la valide. Plus tard je modifie le prix du produit X, disons Z. Quand je réaffiche ma facture, j'ai le nouveau prix.
Ce type de comportement peut être très emmerdant, si non désiré.
** : tout le long, je dis MySQL, mais ya aussi PostgreSQL....
[^] # Re: Question bête
Posté par Bruno Michel (site web personnel) . Évalué à 3.
On peut alors être facilement effaré par ceux qui choisissent systématiquement des bases SQL sans se poser de questions, et essaye d'y mettre de force toutes leurs données même quand ça s'y prête très mal. J'ai déjà vu des gens utiliser MySQL pour des blobs binaires, des files d'attente, des données faiblement structurées (avec des tables 'objects', 'attributes', 'relations', 'contexts'...), et ça donne vraiment l'impression de considérer tous les problèmes comme des clous que le marteau SQL pourra enfoncer...
[^] # Re: Question bête
Posté par Maxime G (site web personnel) . Évalué à 2.
Ce qui est bien, c'est que maintenant on a un vrai choix. Ça devrait lever l'automatisme base de donnée = relationnelle.
[^] # Re: Question bête
Posté par Fabimaru (site web personnel) . Évalué à 5.
Je veux... un "ballot screen"!
[^] # Re: Question bête
Posté par wilk . Évalué à 3.
Peut-être pour des cas bien particuliers, je doute que l'on puisse généraliser comme ça (c'est un FUD !). Est-ce qu'il y a par exemple des benchs couchdb vs postgresql avec insertions atomiques, quelques contrôles d'intégrités, d'unicité et validité des données (une date est bien une date), le tout pendant qu'il y a des requêtes en lecture en parallèle ?
Sur le site de couchdb c'est assez clair : What it is Not : A replacement for relational databases.
Rien que le passage obligatoire par json ça ne doit pas être gratuit sur de grandes quantités de données. Si on prend une date par ex, j'imagine que c'est stocké en texte ? Qu'en est-il de l'occupation disque et mémoire ?
Autant je peux imaginer l'intérêt d'un tel système sur un cluster pour fournir des documents très différents en lecture seule, autant pour des données genre facturation je doute, surtout sur un grand nombre de données...
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.