comme je disais, cela dépend beaucoup de ton usage. Pour les factures, cela dépend donc si tu veux juste les stocker, puis les lister ensuite dans l'ordre par exemple, ben oui du NOSQL fait l'affaire. Par contre, si ton but est ensuite de faire des recherches dedans (ce que je peux parfaitement imaginer pour des factures) selon divers critères, alors SQL peut sembler plus adapté.
Néanmoins certains bdd NOSQL ont aussi des possibilités de requêtes avancées (MongoDB apparemment par exemple), autre que sur la clé.
Mais si le programme est plus évolué que le stockage de factures, car il liste aussi les utilisateurs, et des produits, etc. En gros, on crée des relations entre les diverses données. SQL semble de plus en plus adapté.
Je dirais donc que cela dépend énormément de ton application, ou de ce que tu la vois devenir (car elle peut être simple au début, mais si tu as des plans pour le futur, autant ne pas te mettre des bâtons dans les roues au début).
Enfin pour reprendre ta réponse a ton DBA qui te dit a juste titre que SQL facilite le compte de vente par produit, tu sembles penser que c'est une réponse a cote de la plaque. Mais je pense au contraire que c’était une excellente réponse. L'analyse décisionnel, les statistiques ou la recherche d'information peut être le but même de l'application. Tu ne peux pas dire "ah non, le métier d'une bdd, c'est juste de stocker bêtement! On va pas se mettre a analyser les données non plus!" Donc si ton application requiert ce genre d'usage et que ta bdd NOSQL ne le permet pas (encore une fois, certaines ont des fonctionnalités de recherche avancées, donc certaines le peuvent peut-être), alors c'est un mauvais choix.
Il n'y a pas de "cas métier principale". Il y a juste une décision logique suivie par applicative.
Comme je disais, il ne faut pas se borner a un choix technologique avant même d'avoir mis a plat tes besoins. On doit faire l'inverse: décrire les besoins et les choix technologiques en découlent.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: entités
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal NoSQL ou pas ?. Évalué à 5. Dernière modification le 01 mai 2012 à 04:15.
Salut,
comme je disais, cela dépend beaucoup de ton usage. Pour les factures, cela dépend donc si tu veux juste les stocker, puis les lister ensuite dans l'ordre par exemple, ben oui du NOSQL fait l'affaire. Par contre, si ton but est ensuite de faire des recherches dedans (ce que je peux parfaitement imaginer pour des factures) selon divers critères, alors SQL peut sembler plus adapté.
Néanmoins certains bdd NOSQL ont aussi des possibilités de requêtes avancées (MongoDB apparemment par exemple), autre que sur la clé.
Mais si le programme est plus évolué que le stockage de factures, car il liste aussi les utilisateurs, et des produits, etc. En gros, on crée des relations entre les diverses données. SQL semble de plus en plus adapté.
Je dirais donc que cela dépend énormément de ton application, ou de ce que tu la vois devenir (car elle peut être simple au début, mais si tu as des plans pour le futur, autant ne pas te mettre des bâtons dans les roues au début).
Enfin pour reprendre ta réponse a ton DBA qui te dit a juste titre que SQL facilite le compte de vente par produit, tu sembles penser que c'est une réponse a cote de la plaque. Mais je pense au contraire que c’était une excellente réponse. L'analyse décisionnel, les statistiques ou la recherche d'information peut être le but même de l'application. Tu ne peux pas dire "ah non, le métier d'une bdd, c'est juste de stocker bêtement! On va pas se mettre a analyser les données non plus!" Donc si ton application requiert ce genre d'usage et que ta bdd NOSQL ne le permet pas (encore une fois, certaines ont des fonctionnalités de recherche avancées, donc certaines le peuvent peut-être), alors c'est un mauvais choix.
Il n'y a pas de "cas métier principale". Il y a juste une décision logique suivie par applicative.
Comme je disais, il ne faut pas se borner a un choix technologique avant même d'avoir mis a plat tes besoins. On doit faire l'inverse: décrire les besoins et les choix technologiques en découlent.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]