Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Discussion :
Tutoriel sur la modélisation d'un schéma d'une base de données NoSQL orientée document
Bonjour,
Salaheddine Babouche de la société Palo IT (http://www.palo-it.com/blog) vous propose un tutoriel sur la modélisation d'un schéma d'une base de données NoSQL orientée document.
Vous trouverez cet article à cette adresse : http://paloit.developpez.com/tutorie...ntee-document/
Profitez de cette discussion pour laisser vos commentaires.
Mickael
Hello,
Je n'ai encore jamais testé de base NoSql mais les lenteurs dont il est question dans l'article, et qui seraient la raison de migrer vers ce type de base de données, ne seraient-elles pas le signe d'une base de données non correctement modélisées et mal administrées ?
J'administre quotidiennement des bases de données et les lenteurs que je rencontre ne se produise que sur les DB que j'ai modélisées avant d'avoir le savoir nécessaire et suffisant pour faire quelque chose de correct. Si les DB que j'ai modélisées par la suite, il n'y a jamais de réels problèmes de lenteurs. Peut-être de temps en temps un léger ralentissement mais c'est en général car un index a été mal pensé ou une requête mal écrite.
D'après ce que j'ai compris de la description des bases NoSql qui est faite dans l'article, ce serait en fait une sorte de gros data warehouse. Du coup, pourquoi pas. Mais à condition que les données qu'il contient ne doivent pas être mises à jour (ex : stockage de données des ventes d'un magasin). Si son contenu est amener à "vivre", alors je ne troquerai ma DB transactionnelle (et surtout relationnelle) pour rien au monde !
Tout d'abord il n'existe pas qu'une seule type de base Nosql. Certaines correspondent à des cas d'usage non triviaux en relationnel (par exemple les bases orientés graphe).
Je vous invite vraiment à tester et vous documenter sur les différentes bases et leurs cas d'usage. Au pire cela vous confortera dans votre idée mais avec de véritables données pour le faire.
Bonsoir,
Les points de vue peuvent être multiples, mais je donne celui du praticien du relationnel.
En remontant à un niveau conceptuel, votre exemple des auteurs et des livres est applicable à un cas particulier : celui des associations de plusieurs à plusieurs, non porteuses de données, stables dans le temps, ce qui est quand même limité et ne mérite pas d’être élevé au rang de « paradigme » (sic !)
Modélisons l’exemple sous forme d’un diagramme dans lequel ce que vous appelez « normalisation » est respecté :
_MWB_A.png)
Si l’on vous suit, la table REDACTION disparaît et ses attributs sont exportés pour moitié dans la table AUTEUR d’une part et dans la table LIVRE d’autre part :
_MWB_B.png)
Dans ce diagramme, {LivreId} représente soit une relation (au sens de la théorie relationnelle, c'est-à-dire un ensemble), soit un sac (bag, doublons autorisés). Question : qu’est-ce que {LivreId} dans votre système, une relation ? Un sac ? (Pour des raisons de symétrie évidentes, la question vaut pour {AuteurId}). Si {LivreId} et {AuteurId} sont des sacs, alors les tables AUTEUR et LIVRE sont à leur tour des sacs, et l’algèbre relationnelle ne s’applique plus : merci alors de décrire les opérateurs de l’algèbre des sacs que vous utilisez.
Par contre, si {LivreId} est une relation, c’est un ensemble et les doublons sont de facto interdits. Comment garantissez-vous alors l’unicité des valeurs de cet ensemble ?
Vous écrivez : « La solution réside dans la dénormalisation des données ».
Quelle forme normale est en cause ? Sachez que du point de de vue de la théorie relationnelle, si {LivreId} et {AuteurId} représentent des relations, alors en réalité ce sont des RVA (Relation-Valued Attributes) et selon votre modélisation, AUTEUR et LIVRE respectent (au moins) la première forme normale. Vous lirez avec profit ce qu’a écrit C. J. Date à ce sujet dans Database Design and Relational Theory: Normal Forms and All That Jazz (Theory in Practice), au chapitre 4. Pour mémoire, les RVA ne datent quand même pas d’aujourd’hui, elles ont été présentées par Date et Darwen en 1991, dans Relational Databases, Writings 1989-1991, ainsi que les opérateurs dont elles sont l’objet.
Questions :
— Quelle algèbre utilisez-vous dans votre système ? Quels en sont les opérateurs ?
— Comment garantissez-vous l’intégrité référentielle ?
— En comparant les figures 1 et2 ci-dessus, on comprend que vous mettez manifestement en cause l’opération de jointure. Où est votre prototype de performances et son bilan chiffré prouvant que votre système est tellement supérieur ès matière, que JOIN est bon pour être rangé au rayon des accessoires obsolètes ? Vous ne démontrez rien, vous ne faites qu’affirmer : opinions et incantations ne suffisent pas.
En passant, quand vous écrivez :
« L'idée est de dupliquer le minimum de données du document B dans A et de préférence, celles qui ne changent pas souvent, car lors de leur mise à jour, nous devrions faire un update sur l'ensemble des documents qui les contiennent, plutôt qu'à un seul endroit dans une base de données normalisée. N'oublions pas que ces modifications augmenteront le temps d'écriture. »
Selon la figure 1 ci-dessus, pour répondre à une question portant sur les seules données propres à un auteur : nom, prénom, indépendamment des ouvrages auxquels il a collaboré, la consultation de la table AUTEUR suffit. Maintenant, si un tuple de la table donne lieu à un enregistrement physique, selon la figure 2, certes la consultation de la table AUTEUR suffit là aussi, mais cet enregistrement physique est pondéralement surchargé par les données (images des « clés primaires ») relatives aux livres.
Supposons maintenant que l’on veuille savoir quels auteurs ont rédigé quels chapitres des livres. Selon la figure ci-dessous, ça sera simple. En effet, la structure de la figure 1 évolue ainsi :
_MWB_C.png)
Que devient votre propre structure ?
Dans le cas de la figure 3, pour répondre à la question, utilisons par exemple SQL :
Code SQL : Sélectionner tout - Visualiser dans une fenêtre à part
2
3
Merci de fournir la requête équivalente dans le contexte de votre propre système.
Vous concluez ainsi :
« Encore une fois, vous l'aurez remarqué, on vient d'assister à un bel exemple de retour vers le passé »
Phrase malheureuse ! Je remplacerais volontiers « bel » par un de ses antonymes...
Bref, étoffez, étayez, quantifiez, prouvez.
Je vais me permettre de répondre à certains points même si je ne suis pas l'auteur du post initial.
De façon générale Mongodb, comme d'autres stores orienté document, déporte une partie de la logique référentielle côté applicatif comme par exemple les questions portant sur l'intégrité référentielle (mon id de document est il bien présent dans une autre collection ?).
Vous demandez quelle algèbre relationnel est utilisé. Or justement ce n'est pas un store relationnel. Il n'y a donc pas de notions ensemblistes, pas d'union, pas d'intersection rien de tout cela. En tout cas pas entre deux collections de document.
Par rapport aux performances, effectivement MongoDB a fait des choix de design en sacrifiant des fonctionnalités au profit de performances :
- pas de transactionnalité (*)
- pas de jointures (pas de contraintes d'intégrité également)
Par rapport aux preuves concernant les performances, le mieux est d'aller sur les docs officiels de tout ces stores nosql qui ont déjà publié sur le sujet.
Attention, je le répète, oui c'est plus performant (et encore ca dépend du contexte) mais au détriment de fonctionnalité et c'est un choix assumé.
Il faut bien comprendre que Mongo parie sur le fait que vous allez être capable de modéliser sous forme d’agrégats au sein d'une même collection. Donc que vous n'aurez pas besoin de jointures car votre document sera "autonome", il contiendra toutes les données nécessaire pour le comprendre. Même si pour cela il aura été nécessaire de dupliquer de l'information (d'ou la dénormalisation). La dessus je vous invite à regarder du côté de Domain Driven Design qui revient justement beaucoup sur cette différence d'approche avec le relationnel (tel qu'on le voit souvent pratiqué en tout cas).
En fait Mongodb n'est pas adapté à tous les cas d'usage. Si vous avez un fort besoin transactionnel alors ce n'est pas adapté par exemple. Vous aurez cependant peut-être des pistes pour vous ôter cette contrainte via des mécanismes de messaging et de reprise sur erreur mais en tout cas ce n'est pas certainement pas sans effort.
Mais ce serait une véritable erreur de prendre un modèle relationnel existant et de le traduire "mot à mot" en Mongo. Le paradigme sera différent et l'absence de fonctionnalités fera très mal. Tandis que le gain en performance sur une petite volumétrie sera peu visible, sinon inexistant. Il y a une réelle nécessité à repenser son architecture.
Oui le monde relationnel est très bon pour de la modélisation car il permet de représenter beaucoup de choses et c'est assez souple post "première modélisation", notamment grace aux formes normales.
La contrepartie c'est justement que cette souplesse amène parfois à des modélisations "monstrueuses" avec des centaines de tables, des dizaines de colonnes pour certaines. Je suis sûr que vous allez me dire que c'est exagéré ou que c'est la faute des développeurs. Par expérience j'ai pourtant souvent vu ces monstres, y compris avec des DBA sur le projet. Et c'est plutot logique pour un modèle qui évolue pendant des années.
Je suis conscient que cette réponse et l'article puisse paraître très frustrant car on ne voit pas forcément les possibilités offertes. De plus un grand nombre de cas ne se prête pas à l'utilisation d'un store orienté document et il y a des gens qui se plantent en s'y essayant. En tout cas en s'y essayant avec une approche "relationnelle" entré avec un marteau dans le modèle de Mongo.
Pensez peut-être à d'autres cas d'utilisation : stockage de logs (aucune relation entre logs, schéma flexible et non prédéfini), vue analytique, monitoring.
Vous trouverez d'autres cas d'usage possible sur cette page :
- http://docs.mongodb.org/ecosystem/use-cases/
- ou sur cette présentation http://fr.slideshare.net/Dataversity...cases-13695677
(*) A noter que Tokumx propose une surcouche transactionnelle au dessus de MongoDB.
Hugo,
ça c'est de la réponse. Merci pour ton point de vue.
Mickael
Bonsoir,
Vous me trouverez un peu bavard, mais je souhaiterais comprendre ce qu’est un système de gestion de documents afin de le comparer avec la théorie relationnelle à laquelle j’adhère (attention ! ne pas confondre relationnel et SQL qui n’en est qu’un avatar plus ou moins conforme).
Dois-je comprendre qu’à ce propos on en revient au temps jadis, quand nous devions nous mêmes garantir l’intégrité référentielle ? S’il en est ainsi, c’est bien là où le bât blesse ! D’expérience, même avec une vigilance extrême, une surveillance constante des bases de données et des applications archi-testées, je témoigne qu’une fausse manipulation est toujours possible et que la cata suit.Envoyé par hugo123
Quand il s’agit des contrats des clients, du suivi des cotisations de la retraite des salariés, et autres thèmes, c’est particulièrement préoccupant.
Pour illustrer, je reprends un échantillon d'expériences que j'ai vécues chez ceux qu'on appelle les "grands comptes", quand il a fallu que je m’échine à faire comprendre aux décideurs que le contrôle de l’intégrité référentielle par l’applicatif est faillible.
La question posée était alors bien la suivante : Peut-on donc faire l'impasse sur le contrôle de l'intégrité référentielle par le SGBD ? Demander à l’application de garantir l’intégrité des données suffit-il ? Dans le cas des applications traditionnelles de gestion, centrales, vitales, dans le monde des entreprises telles que les banques, les sociétés d’assurance, les caisses de retraite, dans la distribution, l’industrie, les administrations, etc., le suivi de la production dans ce genre d’entreprises montre que l’intégrité référentielle est à sous-traiter au SGBD. A défaut, voici quelques exemples où j’ai eu à intervenir à ce sujet.
Il était une banque où je fus appelé pour tenter de rétablir les liens entre les tables des comptes, des contrats, des clients, etc. La cata. J’ai tout tenté pour remettre les choses d’aplomb. Le Président lui-même me posait tous les matins la même question dans laquelle l’angoisse était à peine voilée : « Alors ? mes en-cours ? » Peine perdue. La banque n’existe plus.
Une société d’assurance. Pour le DSI, la base de données Clients c’était du béton : « Je n’ai jamais entendu parler de quelque problème que ce soit, tout baigne ». J’étais alors chargé de valider un modèle conceptuel de données et le modèle logique dérivé, ceci pour une autre base, alimentée à partir des données de production. Ayant mis en œuvre l’intégrité référentielle pour la nouvelle base, le bilan fut le suivant : 30% de données rejetées lors de la « remontée » dans la base toute neuve. Heureusement, le DSI n’était pas cardiaque, mais il pâlit, verdit, et il fallut plus d’un an d’efforts pour arriver à remettre la base Clients à peu près d’équerre.
Une société de crédit automobile. Pour valider une application en cour de refonte, j’avais été autorisé à copier les données de production. Je fus obligé de porter le pet au plus vite, car il y avait quelques milliers de contrats faisant référence à des clients devenus inconnus au bataillon. Panique à bord, tout le monde sur le pont... Après enquête, il s’est avéré que, suite à un incident matériel en production, il y avait eu une restauration des données Clients/Contrats, mais à partir d’une sauvegarde des clients ayant eu lieu à une date différente de la date de sauvegarde des contrats. Heureusement, il y avait un an de backup au frigo et le coup put être rattrapé. (Le SGBD n’était pas relationnel. Il a par la suite été remplacé par DB2, lequel, s’appuyant sur le catalogue relationnel, aurait tout de suite détecté la désynchronisation des sauvegardes et aurait empêché les opérations de se poursuivre.)
Une caisse de retraite. Un décideur (fonctionnel) ordonne bizarrement de faire débrancher l’intégrité référentielle pour une partie de la base de données. Prudent, je recopie les tables de production dans un environnement qu’on m’a affecté, j’écris toutes les requêtes SQL pour vérifier (de nuit, car il est hors de question de pomper du temps machine pendant la journée) que les tables impliquées sont restées cohérentes suite à traitement diurne. Au résultat, ça n’a pas traîné : je constate que 780000 périodes passées par les cotisants dans les entreprises se sont envolées (peut-être étaient-ce les vôtres ?) Traitements à refaire, avec ordre cette fois-ci du décideur échaudé, et donc convaincu, de brancher l’intégrité référentielle. Qu’est-ce qu’il ne faut pas faire pour que les gens comprennent...
Et j’en ai bien d’autres...
Conclusion : comme le DSI de la société d’assurance, il faut être vraiment naïf pour croire que les contrôles d’intégrité assurés par programme permettent de dormir sur ses deux oreilles.
Une incidente : quelle définition formelle donnez-vous au terme "document" ? Dans son article, Salaheddine Babouche écrit : « Dans une base NoSQL orientée document, une ligne d'une table relationnelle correspond à un document structuré ». Mais, pour aller plus loin, à l’instar d’un objet au sens OO, outre les attributs, un document est-il porteur de méthodes ? Quels autres concepts le caractérisent formellement ? Où trouver la BNF correspondante ?
Je n’ai pas demandé quelle algèbre relationnelle est utilisée, j’ai seulement posé la question, nuance :
Cela dit, vous conviendrez que, comme dit l’autre, une structure sans opérateurs propres, c’est comme de l’anatomie sans physiologie. Du temps des SGBD pré-relationnels, on disposait certes de primitives d’accès aux données du genre FIND, STORE, ERASE, mais agissant seulement au niveau de l’enregistrement : rien au niveau ensembliste, c’était le règne du procédural. Comment se positionnent les opérateurs proposés par votre système ? Là encore, sont-ils décrits par une BNF ? Utilise-t-on des méthodes façon OO ? Sinon, quoi d’autre ?
Au fil des ans, j’ai appris à me méfier particulièrement de ce que les éditeurs publient quant aux « performances ». Combien en ai-je vu faire des études comparatives, prouvant que leur produit est forcément le meilleur : bien sûr, ils le connaissent à fond et se contentent, pour les besoins de la cause, de se former sur le produit concurrent à comparer, en vertu de quoi celui-ci donne des résultats peu fameux. Et bien évidemment le concurrent en cause n’agit pas autrement... Dans ces conditions, du temps où j'étais actif, pour en avoir le coeur net, je préférai passer des nuits et encore des nuits à prototyper et comparer moi-même, et m’amusai de voir la tête de l’éditeur du SGBD en cause qui suivait cela, agacé, mais qui perdait de son assurance au fil de mes travaux, quand je montais des traitements propres à le contredire...
On parie plutôt sur les champs de course ou au multicolore (où l’on est sûr de perdre), mais là, vous m’expliquerez. Je ne suis pas sûr de vous suivre : les collections d’agrégats sont-elles l’objet principal de Mongo ? Auriez-vous des exemples de telles collections et de leurs agrégats ?
Donc ce document n’entretient pas de relation avec son environnement ? Alors que vient faire l’attribut "livres" dans l’en-tête du document Auteur dans l’exemple présenté par Salaheddine Babouche ? En effet il s’agit quand même en l’occurrence d'un ensemble (?) ou d'une liste (?) ou d'un sac (?) de valeurs gérées en fait par un autre document, ici du type Livre. Si une de ces valeurs disparaît du document Livre concerné, le document Auteur porteur de la référence correspondante sera toujours autonome, mais ne sera plus valide. Peut-être me direz-vous que pour éviter cela, on ne manipule pas l’un sans l’autre, mais alors le principe d’autonomie serait remis en cause.
Comme je l’ai écrit, je n’ai pas constaté dans l’article de Salaheddine Babouche de dénormalisation au sens de la théorie relationnelle. Que l’information soit dupliquée n’est pas choquant quand c’est sous le contrôle du SGBD, c’est un principe de base défini par Codd en 1970 : c’est un des fondements de sa théorie, son caractère associatif (d’où JOIN, et plus généralement l’algèbre et ses opérateurs tels que UNION, INTERSECTION, PRODUIT, DIVISION), par opposition aux modèles de l’époque (hiérarchique, réseau, liste inverse) , non ensemblistes, avec lesquels les associations entre entités donnaient lieu — à coups de pointeurs — à une navigation plus ou moins performante, à coup sûr laborieuse (j’ai eu à m’en servir...) pour aller d’un objet (en fait d’en « record ») à l’autre (je vous renvoie au grand débat de 1974, quand Ted Codd mit Charlie Bachman KO au 1er round, un an après l’obtention par ce dernier de la Turing Award...)
Pour en revenir à JOIN, vous dites qu’il n’y a pas besoin de jointure, mais dans le sens de ce que j’ai écrit ci-dessus au sujet de l’attribut "livres", pour récupérer les noms des libres écrits par tel co-auteur, il y a bien une opération (ne serait-ce qu’un FIND du bon vieux temps) permettant de mettre en relation un auteur et des livres, donc qui simule JOIN même de loin, non ? Ou alors LIVRE est absorbé par AUTEUR (et réciproquement, pour des raisons de symétrie, mais alors, comme dans le cas des SGBD pré-relationnels, la garantie de la cohérence par l’applicatif n’est pas un exercice trivial, puisque le système la lui sous-traite...)
Suite à vos explications, je ne doute pas que nous parlions de sujets se situant sur un niveau différent. Du peu que j’ai vu de DDD, celui-ci se positionnerait plutôt au niveau sémantique, comme Merise ou UML, tandis que la théorie relationnelle se situe sur un autre plan, elle n’a pas pour objet le « design » (bien sûr on peut modéliser par le biais de la normalisation des relations, donc selon une approche ascendante, mais ceci ne fait pas partie à proprement parler de la théorie relationnelle, tout en notant que, par définition, une relation est en 1re forme normale, quitte à ce que ses attributs soient des RVA, comme je l’ai écrit dans mon message précédent). Pour fixer les idées, la théorie relationnelle se définit ainsi (je vous renvoie à l’ouvrage The Relational Database Dictionary, je traduis (et, au besoin, peux commenter)) :
1. Une collection non limitée de types scalaires (dont notamment le type booléen (valeur de vérité)) ;
2. Un générateur de type Relation et l’interprétation attendue des types de relations générés par ce moyen ;
3. Les mécanismes pour définir des variables relationnelles du type de relation voulu ;
4. L’opération d’affectation relationnelle permettant d’affecter des valeurs de relations à ces variables ;
5. Une collection non limitée d’opérateurs relationnels génériques (« l’algèbre relationnelle »), pour produire des valeurs de relations à partir d’autres valeurs de relations.
Je ne retrouve pas là l’approche DDD, que l’on ne peut donc pas comparer à la théorie relationnelle qui relève en fait des mathématiques appliquées, or celles-ci ne font pas particulièrement l’objet de « design ».
Hum... La souplesse a autant à voir avec la théorie relationnelle, qu’avec la théorie des nombres...
Quant aux centaines de tables résultant de la modélisation en amont, c’est normal, dès que vous prenez en compte l’ensemble des activités de l’entreprise, mais le catalogue relationnel (la métabase comme dit l’autre, composant fondamental s’il en est) est fait pour surveiller que l’ensemble est cohérent, notamment en termes d’intégrité (décidemment je dois y revenir, au nom de la validité, de la crédibilité de la base de données...)
En amont du niveau relationnel, quand on a à modéliser des centaines d’entités-types et les associations qu’elles partagent, on commence quand même par urbaniser l’univers du discours, en le découpant en sous-univers correspondant aux différents référentiels à mettre en oeuvre (Par exemple : Personnes, Contrats, Cotisations, Catalogue produits, Prospection, Evénements, Habilitations, etc.), sinon une chatte n’y retrouverait pas ses chatons. Et chaque chef de projet, responsable d’un tel référentiel, ne manquera pas de découper son propre univers en sous-univers et ceux-ci en sous-sous-univers, ad libitum.
Dans ces conditions, les équipes de développement n’auront jamais (heureusement !) à accéder à l’ensemble des tables issues des centaines d’entités-types et de leurs associations, mais chacune à un sous-ensemble de taille raisonnable et compréhensible. Au-delà, grâce à son catalogue (relationnel lui aussi), le SGBD veille en permanence. A la limite, si elle existe encore, la complexité peut être « encapsulée » dans des vues, perçues par le développeur comme de banales tables.
Des dizaines de colonnes ? Je n’ai jamais vu cela, et pourtant combien d’audits ai-je faits... Quoi qu’il en soit, la multiplicité éventuelle des colonnes signifie que la troisième forme normale est violée, ou qu’une table entretient des relations facultatives avec un paquet d’autres tables, cause de la présence illégitime et pléthorique de bonhommes Null, ou encore qu’il y a eu une « optimisation » à côté de la plaque, du genre mettre dans une seule ligne des données normalement en colonnes, le salaire mensuel des employés, ou les statistiques du réseau par exemple), mais cela est valable pour n’importe quel type de structure (table ou autre), dans n’importe quel contexte, mais tout cela ne peut être que le résultat d’un manque de compétence lors de l’étape de conception ou de l’étape de dérivation des entités-types ou classes, dont les structures des tables ne sont ensuite que la conséquence logique. Ne tirons pas sur le pianiste...
Je n’en doute pas, aussi je reprends le problème basique, pour lequel je n’ai pas eu de réponse :
Dans un contexte classique, la dérivation d’un MCD merisien ou E-A, d’un diagramme de classes UML (au moins pour la partie attributs) donnera lieu aux tables suivantes :
Que devient la structure proposée dans l’article ? Comment sera programmée la requête permettant de savoir quels auteurs ont rédigé quels chapitres de quels livres ?
N.B. Je signale en passant que « modèle relationnel » n’est pas synonyme de structure, de schéma, mais de théorie relationnelle.
Il est évident que je ne me lancerais pas dans la modélisation d’une base de données orientée documents sans une étude approfondie préalable de l’approche correspondante, je n’ai pas procédé autrement quand j’ai abandonné les SGBD hiérarchiques et réseaux : j’ai commencé par étudier la théorie relationnelle (quant à SQL, aka Sorry Query Language ou Askew Wall, ce ne fut que plus tard, quand je me suis mis à secouer pour de bon les SGBD qu’on dit relationnels...)
Maintenant, si ’ai été sévère avec Salaheddine, je suppose quand même que la modélisation orientée document va plus loin que les deux petits exemples qu’il a fournis et que les systèmes fournissent des primitives formellement décrites pour manipuler les documents, qu’elles soient ensemblistes ou non. Quant à l’intégrité des données, je pense avoir donné un point de vue suffisant, au nom de la défense de la validité et la crédibilité des bases de données et j’aimerais savoir comment des systèmes tels que MongoDB permettent, à l’instar de DB2 d’empêcher les erreurs que j’ai données en exemple (mais à vous lire, j’ai cru comprendre que ces systèmes bottent en touche...)
Pour que nous, les bougres qui découvrons le sujet traité par Salaheddine Babouche, puissions mieux comprendre de quoi il retourne, je suggère que celui-ci (ou quelqu’un d’autre s’il n’en a pas le temps) fournisse quelque chose de plus consistant en termes de structure de base de données, des opérateurs et les contraintes d’intégrité. En l’occurrence, je propose le sujet suivant, inspiré de l’actualité hippique :
« Les courses de galop plat en France »
Les galopeurs se retrouvent sur les hippodromes de France, à l’occasion des grands prix ou de prix moins prestigieux. Voici une description sommaire, que les turfistes trouveront certes incomplète et à aménager, mais déjà suffisante pour les besoins de la cause.
— Les hippodromes
Un hippodrome a un nom et se situe dans une localité française. Par exemple, l’hippodrome de Chantilly se situe à Chantilly, l’hippodrome de Longchamp se situe à Paris. Plusieurs prix ont lieu le même jour, sur le même hippodrome.
— Les prix
Un prix a lieu une fois par an sur un certain hippodrome, toujours le même. En général le mois est aussi le même (mais ça peut varier). Par exemple le Prix du Jockey Club se déroule annuellement sur l’hippodrome de Chantilly, au mois de juin, sur une distance de 2100 mètres. Pour le Grand Prix de Saint-Cloud, c’est sur l’hippodrome de Saint-Cloud, au mois de juin ou de juillet, sur une distance de 2400 mètres. Un prix est caractérisé par son nom, l’hippodrome qui l’héberge, la distance que les chevaux doivent parcourir. En outre, chaque prix a une allocation, à répartir en fonction de l’ordre d’arrivée des chevaux lors des courses. Par exemple, l’allocation du Prix du Jockey Club est de 1 500 000 euros : 857 100 euros pour le cheval arrivé 1er, 342 900 euros pour le 2e, 171 450 euros pour le 3e, 85 650 euros pour le 4e, 42 900 pour le 5e. Cette allocation est réputée rester stable au fil des ans.
— Les courses
Une édition d’un prix, c'est-à-dire une course, a lieu une fois par an. Pour chaque course, on doit savoir quelle en est la date, l’heure du départ, l’état du terrain. Par exemple, l’édition 2014 du Prix du Jockey Club a eu lieu le 1er juin 2014, le départ a été donné à 16h15, l’état du terrain était bon.
— Les chevaux
Les chevaux ont un nom, sont d’un sexe donné (mâle entier, hongre, femelle), ils ont des parents, une date de naissance et un lieu de naissance (pays). Par exemple, Shamkiyr est un mâle né le 18 avril 2011 en Irlande. Ses parents sont l’étalon Sea the stars (né en Irlande) et la jument Shemaya (née en Irlande).
— Les participants
Les participants aux courses sont les jockeys et les entraîneurs. Un participant a un nom, un prénom et une nationalité. Si c’est un jockey, on doit connaître sa qualification : jeune jockey ou professionnel. Si c’est un entraîneur, on doit connaître l’année durant laquelle il a obtenu la licence lui permettant d’exercer. A noter qu’un entraîneur peut être aussi jockey et être l’entraîneur de plus d’un cheval dans la même course (alors qu’un jockey ne peut monter qu’un seul cheval dans une course donnée... ^^)
Par exemple, Aidan O’Brien est un entraîneur irlandais, né le 16 octobre 1969, il a acquis sa licence d’entraîneur en 1993. Christophe Soumillon est un jockey professionnel belge né le 4 juin 1981.
— Les participations
Lors de sa participation à une course, un cheval porte un numéro, il est monté par un jockey et a un entraîneur. Il porte un poids, il occupe une position (stalle) par rapport à la corde, et a une cote. Exemple : A l’occasion de l’édition 2014 du Prix du Jockey Club, Shamkiyr était porteur du numéro 2, il était monté par Christophe Soumillon et entraîné par Alain de Royer Dupré, il portait 58 kg, il avait tiré le 2 à la corde et avait une cote de 9/1. Toujours à l’occasion de l’édition 2014 du Prix du Jockey Club, Karakontie était porteur du numéro 9, il était monté par Stéphane Pasquier et entraîné par Jonathan E. Pease, il portait 58 kg, il avait hérité du numéro 15 à la corde et avait une cote de 7/1.
— Résultats
On note le résultat des courses : la place obtenue par le cheval et la distance par rapport au vainqueur dont on note le chrono. Ainsi, à l’occasion de l’édition 2014 du Prix du Jockey Club, The Grey Gatsby a fini 1er en 2’05’’58, (ce qui a rapporté 857 100 euros à son propriétaire, cf. ci-dessus la répartition de l’allocation), tandis que Shamkiyr a terminé 2e à 3 longueurs (et a rapporté 342 900 euros).
Exemples de questions (à compléter...) :
— Quels sont les hippodromes où Shamkiyr a terminé 1er ? Monté par quel(s) jockey(s) ?
— Quels chevaux ont rapporté plus de 500000 euros à leur propriétaire ?
Ouh la, il me faut du temps pour répondre.
Je vais éviter de répondre point par point mais essayer de faire une réponse plus globale. En espérant être plus cohérent du coup (on peut espérer).
Je vais aborder les points suivants : le marché des bases de données (point important selon moi car il permettra de comprendre mon point de vue sur la suite), l'intégrité référentielle, un modèle orienté document, la modélisation par cas d'usage, et un exemple en partant de votre question.
Les bases relationnelles ont désormais 40-45 ans d'historique (pas sûr des dates, je me réfère à Wikipedia). Je ne peux prétendre évoquer comment elles ont été percues à l'époque, je n'étais pas né, mais leur impact a été telle qu'on continue à les utiliser aujourd'hui. Il n'y avait pas le net à l'époque donc ca n'a pas pu faire le "buzz" mais j'imagine qu'on pouvait parler de révolution.
Des vendeurs de bases de données de l'époque sont parmi les gros monstres d'aujourd'hui : Oracle (1977), Sybase (1984).
Elles ont apporté beaucoup mais en contrepartie on a fini par tout vouloir résoudre avec.
Je me permets de citer Abraham Maslow : "Quand on a un marteau, tout finit par ressembler à un clou."
Les vendeurs de base de données, qui sont aujourd'hui des monstres commerciaux, ont réussi à imposer un modèle centré autour d'un modèle unique à toute l'IT. Vous avez les données au centre, toute interconnectées par des relations, un moteur toujours plus puissant capable de prendre en compte tous les cas d'utilisation, et un applicatif relativement léger qui se contente de présenter des vues ou bien des outils du même vendeur (de BI, de Datawarehouse etc...). Je ne caricature pas, c'est ce que souhaitent vendre les commerciaux IBM, Oracle etc...
Ceux qui ont commencé à utiliser des stores Nosql (not only SQL) ont simplement dit un truc tout bête : "et si on utilisait le bon outils pour le job ?"
- Modéliser un réseau social ? Utilisons une base orienté graphe ?
- Des sessions utilisateurs ? Une base clé valeur
- de l'analytique ? Une base orienté colonne (ou document)
etc... D'où la notion de Polyglot persistency.
Pourquoi je parle de ca ?
Parce que selon moi cela a un rapport avec le débat sur l'intégrité référentielle. J'ouvre un "disclaimer" tout de suite :
"L'avis qui suit n'engage que moi, il se base sur mon expérience, les projets sur lesquels je suis passé. En aucun cas il ne peut être généralisé etc... etc...
Comme souvent en informatique, une différence d'approche n'implique pas obligatoirement une bonne et une mauvaise approche. J'ai vu des projets réussir avec une approche différente de la mienne, et évidemment j'ai aussi vu des projets réussir avec l'approche que je défends."
Depuis que je travaille, j'ai toujours vu ce vieux débat ressurgir : "Jusqu'où doit-on déléguer au SGBD ?"
- les opérations en cascade (le delete par exemple)
- procédures stockées ou pas ? (je ne parle pas des triggers qui font partie du même débat)
- les contraintes de nullité, de valeurs ?
etc...
Un vendeur de base de données va argumenter que le modèle porte l'application, donc le SGBD doit en être garant. Tout est organisé autour du modèle.
Un développeur, comme moi, va argumenter que le SGBD n'est qu'un entrepot, qu'il peut être consulté par plusieurs applicatifs et que l'applicatif est seul à connaître ces cas d'usage. Et je ne parle même pas de tout ce qui tourne autour de l'industrialisation (versionning, test unitaire, packaging etc...), il me faudrait un article entier pour convaincre que ce n'est pas du ressort de la base de données.
Dans tous les exemples cités à propos du respect de l'intégrité, il y a une erreur qq part, une action qui a manqué. Bien sûr qu'il faut utiliser une contrainte d'intégrité lorsque c'est possible mais croire que cela suffit c'est être naif également
Une grande partie de la logique est applicative. Déjà il faut industrialiser et être capable de tester de facon automatisé à tous les maillons de la chaîne de fabrication.
Je ferme la parenthèse (et attention à bien relire le disclaimer
Concernant les performances, il faut effectivement toujours lire les benchmarks avec des pincettes. Evidemment ils sont orientés ou dépendent des biais de mesures. Toujours. Même avec la meilleure bonne foi du monde.
Malgré tout cela n'empêche pas de consulter ce qui a déjà été fait. Pour ce qui est des bases Nosql, elles sont souvent open source, utilisées par nombre d'acteurs majeurs et il existe des benchmarks publiés sur internet par des sociétés utilisatrices, pas seulement les vendeurs.
- Pour mongo, la liste des clients (non exhaustive) : https://www.mongodb.com/customers
- Pour cassandra : http://planetcassandra.org/companies/
La plupart des gros acteurs du web (twitter, facebook, google, linkedIn, viadeo) ont recours à des stores Nosql et on trouve des blogs de leur part sur leurs critères de choix qui portent notamment sur les perfs.
Ca n'empêche pas de faire ces propres benchs.
Concernant la modélisation document.
Un document c'est un ensemble de propriété, ces propriétés peuvent être des types simples (date, nombre, chaîne de caractères) et des types complexe: fonctions, tableaux ou objets complexe.
Exemple :
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
3
4
5
6
7
8
9
10
11
12
13
Quelques petits trucs à savoir :
- un tableau peut contenir des objets complexe, un objet peut contenir des objets.
- on peut indexer sur tout type de champs, y compris un tableau (chaque valeur sera mise dans l'index)
- un même champ peut être de type différent par document (peu conseillé mais c'est possible)
- on peut avoir des champs différents par document
En terme de manipulation, on va pouvoir requêter en utilisant des opérateurs simples (http://docs.mongodb.org/manual/refer...uery-selectors). Par exemple :
db.macollection.find({tab : "123"}) // trouve moi les objets dont l'une des valeurs de tab est 123
db.macollection.find({tab : {$in : ["123","456"]}) // presque équivalent, donne moi les objets dont tab contient 123 et 456
db.macollection.find({"objet.autresousvaleur" : {$gt:40} })
(A noter dans les petits bonus qu'on va retrouver des opérateurs géographiques, plain text, des index TTL etc...)
On pourra également utiliser des choses plus complexe comme le framework d'aggrégation http://docs.mongodb.org/manual/core/...-introduction/
Et on pourra également utiliser du calcul distribuée via les MapReduce http://docs.mongodb.org/manual/core/map-reduce/
Comme Mongo ne gère pas de contraintes entre documents, il s'attend à ce que vous ayez tout ce qui a besoin d'être modifié en même temps au sein de votre document. Ce qui est possible via les objets embarqués. A noter que s'il n'existe pas de transactions entre documents, toutes modification au sein d'un même document est transactionnelle par contre.
(Au fait, je ne sais pas ce que signifie BNF dans ton commentaire. Du coup je ne sais pas si je réponds correctement. Si le N de BNF correspond à "normalisation" au sens de normes. Alors non, il n'existe pas de normalisation. Il n'y a pas de languages Nosql qui fonctionne qq soit le store Nosql. Il existe des tentatives d'api communes comme Spring Data ou Hibernate OGM. Mais ca reste très light. En même temps ca ne répond pas aux mêmes cas d'usage.)
C'est la notion "tout ce qui a besoin d'être modifié en même temps au sein de votre document" qui est très piégeuse et pose beaucoup de souci.
A un instant t, on peut modéliser d'une façon et se rendre compte que nos cas d'usage par la suite ne s'accomodent plus d'avoir une modélisation particulière.
Par exemple :
Si on souhaite juste afficher des mots clés associés à une personne. On peut envisager d'ajouter ces mots clés au document. Pas besoin de documents liés.
{ _id : "hlassiege" , skills : ["mongo", "java", "elasticsearch"]}
Si on souhaite afficher l'ensemble des personnes liés à un tag, on constate que a priori ce n'est pas la bonne modélisation. Mais en fait on peut encore le faire via le framework d'aggrégation (mais c'est peut être un peu dommage si c'est le cas d'usage principal).
Là ou vraiment cette modélisation pose souci c'est quand on veut contrôler les "skills" entrés par l'utilisateur pour qu'ils soit uniformes (et pas retrouver elasticsearch, elasticSearch, elastic search etc...). Si jamais quelqu'un souhaite a un moment donné bloquer l'entrée de nouveaux "skills" et proposer à l'utilisateur un champ de saisie à la "google suggest". On sent que le modèle n'est plus adapté.
Et évidemment s'il doit y avoir une interface d'admin pour éditer des "skills", alors là ca sent vraiment le roussi puisque chaque édition devra être faite sur l'ensemble des documents qui porte le skill.
C'est pour ce genre de raison que je vais éviter de commenter la modélisation décrite dans l'article. Elle s'appuie sur un cas d'usage. Sans doute que si le cas d'usage change elle pourrait en souffrir (pour être honnête j'ai seulement lu l'article en diagonale
Un exemple vraiment adapté de données pour Mongo, un access log :
Les documents n'ont aucun lien entre eux. On va pouvoir facilement regarder des choses simples :
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
- les requêtes HTTP dont la taille dépasse x octets
- les erreurs 404, 500 etc...
L'utilisation du framework d'aggrégation va permettre de faire pas mal de choses intéressantes :
- faire le cumul par types de requêtes (GET/POST/HEAD....)
- calculer des historiques ou des camemberts sur les status
- déterminer le taux d'utilisation de chaque navigateur sur notre site
Et on peut aller encore plus loin. Si on a rajouté un id de corrélation à chaque user connecté on pourra reconstruire son parcours utilisateur. On pourra déterminer l'origine géographique des visiteurs etc...
Juste pour terminer encore sur ce type de modélisation par aggrégat, en fait vous avez vous-mêmes donné un très bon précepte, c'est vers cela que je voulais amener en parlant de DDD :
DDD va un peu plus loin. Ce n'est pas juste un découpage par entités (personnes, contrats, cotisations) mais par cas d'usage (on peut retrouver les mêmes entités plusieurs fois mais sous différentes formes).on commence quand même par urbaniser l’univers du discours, en le découpant en sous-univers correspondant aux différents référentiels à mettre en oeuvre (Par exemple : Personnes, Contrats, Cotisations, Catalogue produits, Prospection, Evénements, Habilitations, etc.), sinon une chatte n’y retrouverait pas ses chatons. Et chaque chef de projet, responsable d’un tel référentiel, ne manquera pas de découper son propre univers en sous-univers et ceux-ci en sous-sous-univers, ad libitum.
Si on fait l'exercice de demander à quoi correspond le mot utilisateur dans une entreprise, on risque d'avoir des tas de définitions différentes suivant la direction à laquelle est rattaché la personne (marketing, financière, informatique etc...). Ce que propose DDD (attention, je suis très loin d'en être un expert donc il s'agit de ma compréhension) c'est d'isoler ces définitions par domaines et d'isoler ces domaines (Martin Fowler en parle ici : http://martinfowler.com/bliki/BoundedContext.html). Ca rejoint justement la facon d'utiliser une base orientée document ou tout type de store Nosql. On va s'efforcer d'utiliser une représentation simple et légère.
L'utilisation de "contexte isolé" (bounded context) et d'applicatif dédié à ces contextes est l'une des pistes qui amène aux architectures microservices (http://martinfowler.com/articles/microservices.html). Mais là on dérive trop loin. La discussion risque d'être difficile à poursuivre si on explore tout ces points. C'est toutefois normal de les aborder car l'utilisations des stores Nosql est aussi lié à d'autres façons de concevoir les applis.
Concernant les "exercices" que tu proposes. Vis à vis des livres et auteurs.
Une structure possible pour répondre à la question "quels auteurs ont rédigé quels chapitres de quels livres ?" serait celles-ci :
Un simple find sur la collection me donne la liste des auteurs et les livres associés.
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
Si je veux la liste des livres et les auteurs associés, j'utiliserais le framework d'aggrégation pour transformer mes données et renvoyer une liste de document sous la forme :
(Je précise que cette modélisation a été faite en 30secondes, elle peut sans aucun doute être amélioré)
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
Concernant les hippodromes. Je vais volontairement simplifier tout le modèle que vous avez décrit car justement il part d'une logique ou je cherche à modéliser tout un univers complet pour répondre à toutes les questions possibles et imaginables sur cet univers.
En réalité, les deux seules questions posées sont les suivantes :
— Quels sont les hippodromes où Shamkiyr a terminé 1er ? Monté par quel(s) jockey(s) ?
— Quels chevaux ont rapporté plus de 500000 euros à leur propriétaire ?
Donc je n'ai besoin que de la liste des courses et de leur vainqueur :
Evidemment je peux rajouter des choses, la date, les autres positions etc... Ici volontairement je me contente de répondre à la question. Il est possible que vous souhaitiez conserver le référentiel des hippodromes ailleurs, peut être dans une autre collection mongo ou même dans une base relationnelle. Dans ce cas on utiliserait l'id pour faire la liaison entre ces contextes.
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
3
4
5
6
7
8
9
10
Mais la liste des courses a effectivement du sens dans une base orienté document (avec le sous ensemble de données liées nécessaires pour répondre à mes cas d'usage).
Bon, j'espère avoir répondu au mieux.
Je ne cache pas qu'il m'a fallu du temps pour écrire tout cela et je ne réitérerai pas sur tous les posts ou les prochaines questions. (Mais les questions étaient intéressantes et bien posé, ca motive
Si jamais on se croise dans un user group à Paris ou Lyon je pourrais développer encore plus (je peux être bavard également).
a+
L'article est à mon sens un peu léger. Est-ce volontaire ? L'exemple donné (auteurs / livres) semble beaucoup trop simple. Un schéma plus complexe aurait été apprécié !
Par ailleurs, moi qui ait toujours connu MERISE, j'aurais aussi aimé avoir une comparaison entre une "modélisation merisienne" et une "modélisation NoSQL". Un exemple comme celui donné dans ce PDF de MongoDB, page 2 et 3 (pour ceux que ça intéresseraient) : http://info.mongodb.com/rs/mongodb/i...ture_Guide.pdf
Concernant le débat (le questionnement ?) entre fsmrel et hugo123, je pense que l'intégrité référentielle des données est nécessaire, si ce n'est vitale dans certains secteurs d'activité (banques et assurances par exemple, mais cela ne les empêche pas de faire du NoSQL).
Mais certaines applications, dans d'autres secteurs d'activité, n'ont pas besoin d'avoir des contraintes aussi fortes. Le NoSQL est une nouvelle approche qui peut séduire (l'idée de "document" me plaît mais j'aimerais pour autant ne pas sacrifier l'intégrité de mes données).
ça dépend de la modélisation.Pour en revenir à JOIN, vous dites qu’il n’y a pas besoin de jointure, mais dans le sens de ce que j’ai écrit ci-dessus au sujet de l’attribut "livres", pour récupérer les noms des libres écrits par tel co-auteur, il y a bien une opération (ne serait-ce qu’un FIND du bon vieux temps) permettant de mettre en relation un auteur et des livres, donc qui simule JOIN même de loin, non ?
Si le document est rédigé ainsi :
Il suffit de retrouver le document ci-dessus (avec l'idAuteur à 1) pour récupérer tous les livres. Un simple "findById" suffira.
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16Auteur : { idAuteur : 1, nomAuteur : "Chrétien de Troyes", livres : [ { idLivre:1, titre: "Yvain ou le chevalier au lion" }, { idLivre:2, titre: "Lancelot ou le chevalier de la charette" } ] }
Il est aussi possible de remplacer la liste des livres par une liste de clés (chaque clé permettra par exemple de récupérer un document "livre").
Dans un tel cas (et comme c'est expliqué dans l'article rédigé par Salaheddine Babouche), on passe par 2 étapes : la première consiste à récupérer l'auteur, et la seconde correspond à faire une requête sur chaque idLivre. (note : on peut faire une requête du type "findAllById").
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
3
4
5
6
7
8
9Auteur : { idAuteur : 1, nomAuteur : "Chrétien de Troyes", livres : [ 101, 200, 304, 739 ] }
A titre personnel, je pense qu'on peut effectivement comparer ça à un "JOIN" qui est simulé, pour reprendre vos mots.
2 choses :je pense que l'intégrité référentielle des données est nécessaire, si ce n'est vitale dans certains secteurs d'activité (banques et assurances par exemple, mais cela ne les empêche pas de faire du NoSQL)
- la discussion ci-dessus portait plutot sur le fait que, quand l'intégrité référentielle est importante, alors qui, de la base et/ou de l'applicatif peut en être garant ? Mongo propose de passer par des documents embarqués pour garantir l'intégrité référentielle. De plus il y a des méthodes applicatives pour faire du two phase commit entre deux collections (mais que je ne conseille pas...)
- même dans les banques et l'assurance tout n'a pas besoin d'avoir les mêmes garanties.
En tournant la question de cette manière et en tentant d'y répondre (si j'en ai le droit
Une application bien construite et testée correctement (certains diront qu'il s'agit d'une utopie) peut tout à fait être garante de l'intégrité référentielle, tout comme une base de données relationnelle. Des entreprises utilisant du NoSQL nous l'ont certainement déjà prouvé.
Oui, évidemment. D'où ma réponse nuancée puisque je disais que "cela ne les empêche pas de faire du NoSQL".
A la question de savoir qui de l'applicatif ou de la base de données (relationnelle) doit être garant de l'intégrité référentielle, la réponse ne peut être que la base de données ! L'applicatif peut (doit!) bien sûr aider à débroussailler le terrain lorsqu'il le peut mais le dernier rempart ne peut être que la base de données.
Une base de données, si le contexte est connu et maîtrisé depuis le début, n'évoluera que peu. Tandis qu'une application est amenée à connaître pas mal d'évolution au cours de sa vie. Et je ne parle pas des évolutions concernant les données (dans ce cas, la base de données devra évoluer également) mais des évolutions dans les processus (plus généralement, l'ergonomie). Du fait de ces maintenances/évolutions régulières (dont je suis témoin tous les jours dans mon travail), croire qu'il est possible de gérer parfaitement l'intégrité référentielle des données sans oublié une situation problématique relève du bigotisme !
Sans compter que la plupart des développeurs n'ont que très peu de connaissance du monde des bases de données (et je parle en connaissance de cause, je suis développeurs à la base).
Il est même courant de voir des ordres SQL construit par concaténation par l'applicatif laissant la porte ouverte aux injections SQL. Dès lors, on aura beau déployer tous les moyens du monde, un individu malintentionné pourra venir semer la pagaille dans nos données.
Un SGDBR avec une DB correctement modélisée/normalisée sur laquelle se connectent des utilisateurs avec des droits fortement limités (par exemple, mes utilisateurs ne peuvent exécuter que des procédures stockées et rien d'autre) est, pour moi, le seule moins de garantir la validité des données.
Non c'est pas possible.
Ceci impliquerai :
- aucune interaction entre la base et un utilisateur X.
- un seule goulot d’étranglement au niveau applicatif pour toute la gestion de cette contrainte spécifique (adieu batch par exemple)
- aucun bug
- .. j'en oublie peut-etre
Dans une utopie ces 3 conditions pourrait être niée, dans un SI qui évolue l'une des trois conditions surgira à un moment donné ou un autre
JE ne parlerai pas de la gestion des rollback, ni de la quasi obligation de remonter la base en mémoire... et que sais-je encore ?
Et pourtant, certains y arrivent :
Forbes, Bosch, Cisco, Foursquare, Le Figaro, Les pages jaunes, Leroy Merlin, Rackspace, etc.. etc...
(source http://www.mongodb.com/customers)
Est-ce à dire que certains vivent dans une utopie ? Ou simplement qu'ils ont trouvé d'autres réponses aux problèmes évoqués ?
Je ne comprend pas bien ton intervention, personne n'a dit que ces technos ne fonctionnaient pas.
J'ai lu ci-dessus les mots "c'est pas possible", "bigotisme", "utopie", et des réactions assez fortes du type "les devs n'y connaissent rien, je leur coupe tous les accès pour qu'ils executent juste mes procs stocks"
Je pense que au contraire, c'est possible, qu'il y a plusieurs approches valables pour répondre à nos problèmes en informatique. Et pense que de toute facon au final ce qui fera la différence c'est pas uniquement l'idée mais la réalisation (donc avoir des gens compétents et intéressés).
Bref, je ne suis pas en train de défendre à tout prix une approche.
Par contre, je tiens à modérer les phrases des deux précédents posts en rappelant que ce qui n'est pas possible pour certains l'a été pour d'autres.
Donc mon intervention avait surtout pour but de tempérer des propos que je trouvait trop "péremptoire".
Je ne comprend toujours pas, au vu du contexte des postes, votre intervention qui est totalement décorrélée.
C'est très simple de prendre des mots éparpiller dans différent poste, sans comprendre la base de la discussion, puis d'y associée une nouvelle idée.
Perso je n'y vois aucun intérêt par contre.
Encore une fois personne dans ce topic n'a dit que telle techno ne fonctionnait pas.
Par contre elle a des limites, comme toute techno, les mettre en évidence est aussi une bonne approche.
"sans comprendre la base de la discussion"
=> je suis désolé que mon interprétation de certaines phrases ne soit pas la votre. Cependant j'interviens depuis le 3eme post et j'ai eu l'occasion de faire longues réponses à des questions intelligemment posées ci-dessus.
Evidemment j'expose mes points de vue, mais je ne le fais pas de façon dogmatique, enfin je l'espère.
Quoi qu'il en soit, ma réponse semble être aussi mal interprété, sans doute de mon tort, mauvaise expression peut-être.
Ce que je cherche à dire c'est que tous les problèmes rencontrés ont plusieurs solutions et que certains ont trouvé ces solutions. Dire qu'il n'existe qu'une méthode (en tout cas c'est mon interprétation de certains posts ci-dessus) qui peut fonctionner est trop catégorique et je tenais à souligner que certains ont répondu à ces problèmes. Savoir qu'il existe bcp de sociétés qui ont mis en place ces outils a de la valeur dans cette discussion selon moi. Cela montre aussi que nous ne sommes pas en train de parler d'une techno toute jeune et non éprouvé.
Cette remarque tend surtout à montrer qu'en prenant du recul on peut parfois trouver des approches qui supprime certains problèmes qu'on s'était posé (mais en en créant d'autres bien souvent).
Bref, désolé si mon interprétation est fausse. Je ne souhaite certainement pas entrer dans le jeu des "citations" => "réponses" pour l'étayer, cela n'aurait aucun intérêt. En espérant avoir aplani ma réponse.
Et si ce n'est pas le cas, je vous invite à me contacter par MP afin que nous ne fassions pas dériver cette discussion trop loin de son point de départ.
Bonjour,
Ce post me fait penser à ça : la machine à faire du café existe. Puis quelqu'un créé la machine à faire du thé, qui est plus adaptée __à faire du thé__. Et là il y a quelqu'un qui vient et qui dit, sûr de lui << ce truc est nul, je veux faire du café avec, et ça marche moins bien qu'avec la machine à café >>.
Franchement je ne comprends pas qu'il y ait des informaticiens non-débutants qui ne comprennent pas le "paradigme" NoSQL.
Je passe les détails, mais j'étais moi-même DBA et j'ai souvent constaté la chose suivante dans ma boite: << il faut créer un site web pour un client, il faut donc créer une base de données qui lui soit liée >>. Résultat le serveur hébergeait des centaines de bases avec genre 2 pauvres tables remplient de quelques enregistrements.. Ma vision est parfaitement claire à ce sujet : ce n'est PAS ce pourquoi les bases relationnelles SQL sont faites. Point.
C'est exactement l'histoire du marteau.
Pareil, concernant Merise, je ne comprends plus du tout son intérêt : OUI à Merise pour apprendre aux étudiants au tout début de la 1ère année en informatique (et encore, parce que c'est "franco-français"..); mais surtout oui pour dire qu'il faut l'oublier aussi sec. L'Histoire des outils et des méthodes d'analyses de conception et de réalisation ont heureusement évolués depuis (UML/SYSML par exemple, ingénierie des objectifs et des exigences etc..).
Bref on a à faire à un historique trop lourd pour certains, les mêmes qui pensent que les RDBMS sont les seuls containers de données! Moi perso j'ai conçu et développé pleins de sites utilisant les fichiers XML comme containers et XSLT (étendu ou de base) pour l'accès aux données. Ce sont les objectifs d'un SI à construire qui sont censés déterminer les outils à utiliser, jamais l'inverse. Point.
Pour terminer, et pour ceux qui ne comprennent pas NoSQL, voici un exemple simpliste d'utilisation : "utiliser Redis pour les datas liés aux sessions web".
Que ceux qui continuent d’utiliser une table dans une base de données pour cela continuent, ils pourront toujours dire << c'est pas ci >> ou << c'est pas ça >> que ça ne changera en rien le fond des choses.
Pour terminer (vraiment), le fait que les contraintes d'intégrité soient gérées par les BDD n'a jamais jamais fait qu'un SI fonctionne correctement. Jamais.
Ouais
Répondre avec citation
Partager