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 Maxime G . En réponse au journal A quoi peut servir couchdb ?. É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....