Dans la société où je travaille, on développe des applications web, et on a eu l'occasion d'utiliser CouchDB sur un de nos projets. Le projet en question vise à devenir une sorte de wikipedia de l'art.
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.
# Un exemple
Posté par Bruno Michel (site web personnel) . En réponse au journal A quoi peut servir couchdb ?. É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.