[DEBAT] L'avenir des bases de données ?

[voyageur]

Je me permet de poster ce message pour initier un débat sur l'avenir des bases de données.
Le domaine des bases de données contrairement aux langages de programmation a peu evolué depuis 20 ans, il repose toujours sur la théorie relationnelle.
Quelqu'un qui connait bien cette théorie et les grands principes des sgbd peut s'adapter à n'importe quel sgbd sans avoir à remettre en cause ses acquis tous les 6 mois.
Les sgdb basés sur la théorie relationnelle ont t'il encore de longues années devant eux ? ou va t'il y avoir des révolutions prochainement qui entraineront la caducité des connaissances des ingénieurs bd actuels ?

Sous leurs formes actuelles, les bases de données sont incontournables. Le sql est LE langage pour gérer les données, a vrai dire, je n'en connais pas d'autres.

Avec internet, je ne vois pas comment on pourrait s'en passer!!

Quant aux évolutions...Certains sont peut-être plus au courant que moi!

[elbj]

Bonsoir

En fait, lorsuq'on se pose la question de l'avenir d'une technologie c'est généralement parce qu'un substitut existe. De nos jours on voit de plus en plus de gens porter bien haut le XML et le Mapping O/R.

XML n'est pas prévu pour le stockage mais pour l'interopérabilité. Les perfomances de XPath sont bien médiocres par rapport à SQL, ce ne peut être un "concurrent" à la hauteur.

Le Mapping O/R revient, basiquement, à ne coder que les requêtes CRUD et n'utiliser que des objets dans le code applicatif. Le tout objet poussé à l'extrême ne me semble pas le meilleurs choix car les performances ne sont pas au rendez-vous.

En conclusion, les SGBDR ont encore de belles années devant eux. D'autant que, contrairement aux dires de voyageur, les SGBDR ont beaucoup évolué. Certes peu en syntaxe, la norme SQL avance petit à petit, mais énormément en rapidité, efficacité et optimisation. C'est une évolution moins visible.

Cordialement

[alain.couthures]

Pour ce qui est du XML, il existe maintenant des gestionnaires de bases de données XML que l'on manipule avec XQuery (qui ne s'écrit pas en XML...).

Mais, communément, on utilise simplement un document XML que l'on charge en mémoire : on obtient une micro base de donnée en mémoire mais des contraintes existent... Les volumes évidemment, l'efficacité de certaines requêtes, la sauvegarde sur disque ... Il faudrait faire un XML version 2 pour enrichir tout cela et arriver au niveau des bases navigationnelles (rien d'impossible, ce n'est qu'un problème de notation pas de représentation mémoire).

L'efficacité par rapport à une base relationnelle est un point délicat. Une base de donnés relationnelles a le travers de regrouper dans une seule table des données qui ne sont que rarement lues ensemble, voire jamais, tandis qu'en XML on met les données dépendantes des autres au plus près de celles-ci ou, plus exactement, des pointeurs sont présents en mémoire pour trouver directement les élements dépendants. Ce n'est pas pour rien qu'Oracle a rajouté la notion de cluster de tables !

[fsmrel]

Une base de donnés relationnelles a le travers de regrouper dans une seule table des données qui ne sont que rarement lues ensemble, voire jamais

1) Si vous procédez à une modélisation sémantiquement rationnelle des données et si vos tables sont normalisées, leur en-tête a un sens au plan de la logique : cet en-tête est en réalité un prédicat :

"Le fournisseur IdFournisseur, nommé NomduFournisseur, habitant à IdFournisseur, a pour score ScoreFournisseur"

"Le fournisseur IdFournisseur, fournit le produit IdProduit en quantité Qté"

"Le Produit IdProduit de couleur CouleurProduit et de poids PoidsProduit est localisé à AdrProduit".

Pour établir une commande à destination d'un fournisseur, ou toute autre relation avec celui-ci, les données correspondantes sont utilisées de façon tout à fait naturelle, ensemble et non pas "rarement", "voire jamais".

Une base de données relationnelle n’a pas systématiquement de travers, la pauvre ! mais certains de ceux qui la conçoivent feraient bien à l’occasion d’apprendre à modéliser.

2) En parlant de base de données relationnelle, vous avez sans doute en point de mire SQL : pour ma part, celui-ci m’agace car il ne colle pas au Modèle Relationnel de Données. Il n’en est qu’un avatar caricatural, avec un bon fond, certes (comme dit à juste titre elbj, les SGBDR gagnent sans cesse en rapidité et efficacité), mais que de gâchis quand même depuis bientôt 30 ans, pleurons QUEL...

Ce n'est pas pour rien qu'Oracle a rajouté la notion de cluster de tables !

1) Vous mettez dans le même sac le modèle logique, mathématique (les tables) et le modèle physique (la tuyauterie, avec les clusters et toutes ces sortes de choses). Ce dernier est du ressort du SGBD, voire d’un gestionnaire situé au niveau intermédiaire, du type de celui qui a été conçu par Steve Tarin, avec son modèle de transformation, le TransRelational Model.

2) Concernant le cluster proprement dit : Je suppose que vous évoquez la possibilité de regrouper dans la même page physique une commande, ses lignes de commandes, les engagements sur commande de celles-ci, et les livraisons relatives à ces dernières ? Le problème est que ce genre d’artifice favorise un certain accès aux données, au détriment des autres accès : il y a un manque de symétrie évident, tout à fait préjudiciable. Si pour l’ensemble des camions qui ont effectués des livraisons chez les clients, vous recherchez des données dans la table des commandes, bonjour les I/O et les temps de traitement. Au reste, cette technique de clustering n'est pas nouvelle, on l'utilisait avec plus ou moins de bonheur au début des années soixante-dix, contraints et forcés, avec IMS/DL1 (SGBD hiérarchique un peu poussif, mais toujours actif...)

[alain.couthures]

J'avoue être dans l'opérationnel plutôt que dans le théorique parce que la distance entre les deux est gérée par les éditeurs qu'il ne nous est pas possible d'influencer.

Je persiste à penser que les SGBDR d'aujourd'hui sont une solution de facilité où l'on peut faire des requêtes inédites sans que ce soit catastrophique mais je trouve que cela ne respecte pas les proportions effectives entre les requêtes courantes et les requêtes exceptionnelles.

Je suis toujours préoccupé par les performances et les SGBDR consomment des quantités astronomiques d'espace mémoire parce qu'ils sont détachés de ce à quoi servent les données.

J'aime bien l'idée des Datawarehouse pour faire les requêtes farfelues des contrôleurs de gestion alors que l'opérationnel reste sur une base efficace : les SGBDR permettent de confondre les deux usages sur une même base de données mais c'est au détriment de l'efficacité.

Moi, j'aimais bien les bases navigationnelles...

XML bouscule tout cela en permettant de faire sa propre base de données en mémoire et de naviguer dedans avec beaucoup de puissance tout cela sans SGBDR : c'est la base de données pour tous les usages et avec un minimum de moyens.

[ylarvor]

Je note qu'effectivement les serveurs de bases de données comme sql serveur gagne en performance, en scalabilité, d'années en années, en simplicité d'utilisation, en complexité et en puissance. Ce qui démontre bien que l'on n'est pas sur une technologie "statique" comme on pourrait le croire.

Je note aussi que de plus en plus, on parle de décisionnelle et que les DBA ne sont pas forcement préparé à ces techniques. c'est une des évolution du métier à laquelle il faudra se préparer.

concernant le mapping objet-relationnelle, mon expérience dans ce domaine révèle des problèmes de performance sur une grosse application.
concernant LINQ, ce sera certainement une trés bonne chose pour les applications moyennes mais qu'en sera t'il des requetes lourdes ?

concernant XML, cela apporte un plus aux sites web éditoriaux, mais, un bémol, les bases de données de grande capacité sont relationnelles.

[alain.couthures]

Que pensez-vous de l'évolutivité du schéma de données comme le permet le XML ?

C'est bien sûr choquant au premier abord mais si pragmatique... J'ai vu tellement souvent des schémas de bases de données complètement incompréhensibles après quelques versions parce que mal pensés au début en terme d'évolutivité (il est parfois dur de prévoir l'avenir...) !

Là encore, ça peut déranger mais, en XML, le typage des données n'est pas imposé !

C'est une évolution pour moi plutôt qu'une régression : on est dans le pragmatique.

Quant à la puissance des différents systèmes d'aujourd'hui, elle me semble d'abord dû aux évolutions matérielles parce que je crains que, a contrario, les programmes d'aujourd'hui soient des usines à gaz par rapport aux malheureux programmes d'antan qui faisaient des choses super avec bien peu de moyens !

[ylarvor]

Concernant le typage, l'évolution entre le javascript, le vba et vb.net est tres claire, on va vers un typage fort. c'est le sens de l'évolution et je pense que c'est pour de bonnes raisons...
Les SGBD ont mis en place un typage fort pour réduire au minimum la quantité d'information stockée en ainsi gagne en place.
concernant le XML, le stockage est rarement un problème.

Concernant les programmes, entre un programme assembleur, c ou pascal et un programme vb.net, la productivité a ete multiplié par "10".

Concernant les SGBD, la scalabilité(montée en charge) n'a pas cessée d'augmenter.

[pifor]

Envoyé par voyageur

Les sgdb basés sur la théorie relationnelle ont t'il encore de longues années devant eux ? ou va t'il y avoir des révolutions prochainement qui entraineront la caducité des connaissances des ingénieurs bd actuels ?

Je me garderai bien de faire des prévisions. En revanche il est intéressant de comparer les souhaits voire prévisions de certains chercheurs il y a une vingtaine d'années.

Par exemple, le manifeste pour les bases de données de 3ième génération (entendez post relationnel avec de l'objet mais pas trop).

Ou le manifeste pour les SGBD orientés objets.

A 20 ans de distance, finalement, c'est surtout le relationnel commercial qui domine toujours avec parfois des couches objets style "mapping objet-relationnel" ou du XML. Mais où sont donc passés les SGBD OO ? La réponse est là.

PS: Tous les articles sont en anglais. Si quelqu'un trouve un document rédigé en français, merci de donner le lien.

[Halloula]

Envoyé par pifor

Je me garderai bien de faire des prévisions. En revanche il est intéressant de comparer les souhaits voire prévisions de certains chercheurs il y a une vingtaine d'années.

ben moi je me permets de faire des prévisions
je suis loin d'etre un chercheur dans le domaine,mais je verrais bien une montée de l'orienté objet dans les années à venir que se soit avec les SGBDOO ou les SGBDOR .

et dailleurs,ca ne peut etre qu'une montée vu que de nos jours le concept de l'orientée objet vit encore à l'ombre du relationel..

[fadace]

Envoyé par halloula

ben moi je me permets de faire des prévisions
je suis loin d'etre un chercheur dans le domaine,mais je verrais bien une montée de l'orienté objet dans les années à venir que se soit avec les SGBDOO ou les SGBDOR .

et dailleurs,ca ne peut etre qu'une montée vu que de nos jours le concept de l'orientée objet vit encore à l'ombre du relationel..

En ce qui concerne les base pures OO, je crois que le marché à déjà donné son avis...

[fsmrel]

Les chiffres parlent d'eux-mêmes, cf. :

http://www.oracle.com/corporate/anal...dbms/34052.pdf

[ylarvor]

Je me suis permis de vous extraire l'information dans la doc de fsmrel

l'objet (ODBMS) - Marché en décroissance - qte totale en 2009 : 50
The pre- and postrelational database management systems (PDBMS) - marché constant - qte 1700
relationnel (RDBMS) - marché en croissance relativement importante - qte : 21000
XML database (XDBMS) - marché en croissance - Qte : 50
Access & autre (EUDBMS) march en croissance - Qte : 1500

Le XML et l'objet sont relativement "insignifiant" en quantité par rapport au relationnel.
Par contre :
Le XML est en croissance.
L'objet est en décroissance.

[orafrance]

Pour moi la modélisation merise est au SGBD ce que la logique combinatoire est à l'informatique... le B.A.BA de la représentation d'une problématique de stockage. En d'autre terme, on ne change pas une équipe qui gagne. Le XML est certe très pratique (notamment pour stocker des metadonnées de structure variable) mais ne peut être, selon moi, qu'un outil pour faciliter le développement de l'IHM... et souvent pour pallier les carences de développeurs plus habitués au code procédural qu'au code ensembliste (pourquoi faire du SQL quand on peut parcourir un tableau ligne à ligne ).

Tout ça pour dire que pour moi, le SGBD me survivra très largement et a encore de beaux jours D'ailleurs, le SQL a aussi évolué en 20 ans notamment avec des fonctions spécifiques aux nouvelles problématique liées au datawarehousing (CUBE, ROLLUP, etc...)

Envoyé par elbj

mais énormément en rapidité, efficacité et optimisation. C'est une évolution moins visible.

et haute dispo

[gregory.broissard]

imaginons 30 secondes qu'un génie invente une solution révolutionnaire pour stocker des données dans 5 ans...

Avec tous les millions de TeraOctets de bases de données relationnelles dans le monde entier, rien qu'envisager de migrer toutes ces données vers la solution révolutionnaire ca prendrait des dizaines d'années.

Donc on a pas fini de faire du SGBDR !

[Marc Lussac]

Mais qu'est ce que tu reproche aux SGBDR ?

Il n'y à pas de soucis avec les SGBDR quand on à la compétence en SGBD...

Par contre très peu de gens savent faire de bons schémas SGBD, quand quelque chose est mal fait ça n'est généralement pas la faute de l'outil mais de la personne qui à mal fait le schéma (et qui n'y comprends généralement rien).

Faire un bon schéma c'est presque un art... Je pense que environ pas plus d'un informaticien sur 10 ou sur 20 est capable de faire un bon schéma...

[lunatix]

justement, dans le web, le fait d'avoir a maitriser la conception des schémas est plutôt un handicap. Dans le monde du web ou il est nécessaire de relier des concepts, des entités simplement la rigidité des sgbdr n'est pas forcement bienvenue.

le débat est complexe (je mets quelques pointeurs) et je partage quelques points de vue. (sans penser une seconde que les sgbdr vont disparaitre hein )

approche bigtable de google. http://en.wikipedia.org/wiki/Bigtable
pour répondre a un "nouveau" besoin qui est une structuration faible des données, d'enOrmes volumes, et historisation automatique
vous pouvez jeter un oeil sur http://www.hypertable.org/documentation.html aussi et plus précisement sur http://code.google.com/p/hypertable/...ypertableWorks
pas de typage, historisation, gestion par tags...

voir aussi http://future.gigaom.com/2007/08/10/...atabase-world/
et http://marklogic.blogspot.com/2007/0...-database.html

on parle aussi beaucoup de column database. Le fait est que le web en est train de faire evoluer les besoins sur les bases de données : volumes enormes, données non structurées, historisation, interrogation REST etc..

mon avis, c'est que ca va nourrir les bases actuelles, et pas du tout faire une révolution, mais sait on jamais

[jmguiche]

L’avenir des SGBDR ?

Commençons par leur origine : une axiomatique de la structure de l’information : identifiant, dépendances fonctionnelles, dépendances multi-valuées (merci M. CODD). De cette axiomatique débouche immédiatement les concepts de relations et de normalisation. Cette axiomatique marche bien. Tant que nous gèrerons des personnes, des produits, des comptes, des mouvements, des étoiles, des galaxies, des chargements d’épice de DUNE ou que nous ficherons des répliquants, nous seront bien obligés d’identifier et de travailler sur des dépendances fonctionnelles et des dépendances multi-valuées.

A partir de ce constat sur l’aspect fondamental des travaux de CODD, je pense que, sous une forme ou une autre, les SGBDR ne devraient pas changer fondamentalement… Certes, les données « non structurées » (qui ne le sont pas tant que ça), XML, (qui n’est qu’une technique et qui durera moins longtemps que la validité des travaux de CODD), l’objet ( idem XML), ferons leur passage dans les moteurs SGBD, au même titre que d’autres techniques que nous n’imaginons pas encore.
SQL n’est qu’un langage, un génie aura peut être un jour une meilleure idée. Gloire à Lui !

Plus sérieusement, à plus court terme, je pense que les SGBDR intégreront rapidement les fonctionnalités de serveurs d’applications. Ils seront en tout cas au minimum le réceptacle de la partie « métier ». C’est déjà plus que fait (APEX d’Oracle). Les gains en termes de performance, de facilité de développement, de sureté sont tellement évidents que seul des reliquats de problème technologique freinent cette évolution.
Imaginez :
• plus de double caches entre serveur d’appli et SGBD,
• simplicité d’administration,
• moins de couches et de technologies à l’interfaçage plus ou moins réussi,
• plus de nivellement par le bas à cause d’empilement de technologies,
• un seul support technique,
• une seule montée de version,
• un seul langage de programmation,
• …
Et même peut être :
• des applications en mode connecté (le moteur connaît le user, les contrôles d’accès sont géré indépendamment de l’application),
• pas la peine de jongler entre 2 actions utilisateur (on n’a pas perdu la connexion),
• ….
En résumé : moins de temps perdu à résoudre des problèmes techniques, plus de facilité à résoudre des problèmes fonctionnels.

Enfin, tout ça sauf si l’informatique est un milieu où des gourous et des « marketeurs » sont capable de faire gober n’importe quoi à tout le monde. Comme, par exemple, généraliser une nouvelle génération d’outils qui résous les mêmes problèmes que la génération précédente mais qui coûte, en main d’œuvre, entre 5 et 10 fois plus cher que cette dernière.

Il est donc fort possible qu’un gourou quelconque arrive à vendre des SGBD exclusivement Orienté Objet (par exemple) et que, dans quelques années, pour répondre à un besoin nouveau, au lieu de faire une fonction PL (ou transact) de 10 lignes, trois jointures, deux sous-selects et un group by, il nous faille faire quelques centaines de lignes de programmation procédurale, mais objet !
Ce n'est qu'un exemple.

Ton approche me plait bien!
En ce qui me concerne, je n'arrive pas à me passer de SGBD. Je ne vois pas de toute façon comment je pourrais faire. Quand je pense application, par défaut, je pense stockage...performant de surcroit.

Envoyé par jmguiche

...des chargements d’épice de DUNE...

Excellent..., depuis le dormeur s'est réveillé !!!