Posté par steph1978 .
En réponse au journal NoSQL ou pas ?.
Évalué à 5.
Dernière modification le 30 avril 2012 à 14:41.
Le commentaire de Jehan est très intéressant mais il l'illustre par des cas d'usage très particuliers et plutôt techniques.
Pour ma part je partirai d'un raisonnement inverse: pourquoi faire du relationnel si je n'en ai pas besoin.
Le relationnel (premier réflexe de modélisation surtout chez les DBA) est très contraignant (jointures) et ne correspond que rarement à la réalité de ton application.
Beaucoup d'applications manipulent des entités riches (comprendre beaucoup d'attributs et des collections imbriquées) mais qui n'ont que très peu de relations entre elles.
Du coup, des bases de données type document ou objet sont tout à fait adaptées et évitent le calvaire du mapping relationnelobjet et de la mise à l'échelle.
J'ai eu un débat à ce sujet avec un DBA. Il soutenait que le modèle relationnel répondait très bien à tous les cas de figure en général. Je soutenais que le modèle relationnel était le modèle par défaut car poussé par les éditeurs (Oracle) et qui rassurait les décideurs mais qu'il ne résistait pas longtemps à l'analyse.
En posant le problème comme suit: quel est l'intérêt de stocker d'un côté (table) toutes les lignes de factures ensemble et d'un autre côté toutes les entêtes de factures ensemble alors qu'il y a une relation 1-N entre une entête et ses lignes.
Il n'a jamais répondu. En fait, si, il a répondu, après un grand blanc, que cela facilitait le compte des ventes par produit ! autrement dit cela facilite un autre cas d'usage (analyse décisionnel) que le cas métier principale (stocker et consulter des factures).
Bref, maintenant que de bon outils existent, MHA est qu'il ne faut pas raisonner "relationnel" par défaut. Et qu'il ne faut pas hésiter à multiplier les points de vues sur les données en fonction des cas d'usages.
# entités
Posté par steph1978 . En réponse au journal NoSQL ou pas ?. Évalué à 5. Dernière modification le 30 avril 2012 à 14:41.
Le commentaire de Jehan est très intéressant mais il l'illustre par des cas d'usage très particuliers et plutôt techniques.
Pour ma part je partirai d'un raisonnement inverse: pourquoi faire du relationnel si je n'en ai pas besoin.
Le relationnel (premier réflexe de modélisation surtout chez les DBA) est très contraignant (jointures) et ne correspond que rarement à la réalité de ton application.
Beaucoup d'applications manipulent des entités riches (comprendre beaucoup d'attributs et des collections imbriquées) mais qui n'ont que très peu de relations entre elles.
Du coup, des bases de données type document ou objet sont tout à fait adaptées et évitent le calvaire du mapping relationnelobjet et de la mise à l'échelle.
J'ai eu un débat à ce sujet avec un DBA. Il soutenait que le modèle relationnel répondait très bien à tous les cas de figure en général. Je soutenais que le modèle relationnel était le modèle par défaut car poussé par les éditeurs (Oracle) et qui rassurait les décideurs mais qu'il ne résistait pas longtemps à l'analyse.
En posant le problème comme suit: quel est l'intérêt de stocker d'un côté (table) toutes les lignes de factures ensemble et d'un autre côté toutes les entêtes de factures ensemble alors qu'il y a une relation 1-N entre une entête et ses lignes.
Il n'a jamais répondu. En fait, si, il a répondu, après un grand blanc, que cela facilitait le compte des ventes par produit ! autrement dit cela facilite un autre cas d'usage (analyse décisionnel) que le cas métier principale (stocker et consulter des factures).
Bref, maintenant que de bon outils existent, MHA est qu'il ne faut pas raisonner "relationnel" par défaut. Et qu'il ne faut pas hésiter à multiplier les points de vues sur les données en fonction des cas d'usages.