IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

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

Décisions SGBD Discussion :

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


Sujet :

Décisions SGBD

  1. #1
    Membre régulier
    Inscrit en
    avril 2002
    Messages
    182
    Détails du profil
    Informations forums :
    Inscription : avril 2002
    Messages : 182
    Points : 113
    Points
    113
    Par défaut [DEBAT] L'avenir des bases de données ?
    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 ?

  2. #2
    jnore
    Invité(e)
    Par défaut
    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!

  3. #3
    Membre confirmé Avatar de elbj
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    novembre 2004
    Messages
    371
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 47
    Localisation : France, Alpes Maritimes (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : Services à domicile

    Informations forums :
    Inscription : novembre 2004
    Messages : 371
    Points : 557
    Points
    557
    Par défaut
    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
    Christophe B.

  4. #4
    Membre éprouvé Avatar de alain.couthures
    Profil pro
    Gérant
    Inscrit en
    avril 2007
    Messages
    901
    Détails du profil
    Informations personnelles :
    Localisation : France, Gironde (Aquitaine)

    Informations professionnelles :
    Activité : Gérant

    Informations forums :
    Inscription : avril 2007
    Messages : 901
    Points : 1 137
    Points
    1 137
    Par défaut
    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 !
    Formulaires XForms sur tous navigateurs sans extension à installer (architecture XRX) : http://www.agencexml.com/xsltforms/

  5. #5
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    septembre 2006
    Messages
    7 588
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Spécialiste en bases de données
    Secteur : Conseil

    Informations forums :
    Inscription : septembre 2006
    Messages : 7 588
    Points : 28 997
    Points
    28 997
    Billets dans le blog
    16
    Par défaut
    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...)
    (a) Faites simple, mais pas plus simple ! (A. Einstein)
    (b) Certes, E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)

    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench
    Je ne réponds pas aux questions techniques par MP. Les forums sont là pout ça.

  6. #6
    Membre éprouvé Avatar de alain.couthures
    Profil pro
    Gérant
    Inscrit en
    avril 2007
    Messages
    901
    Détails du profil
    Informations personnelles :
    Localisation : France, Gironde (Aquitaine)

    Informations professionnelles :
    Activité : Gérant

    Informations forums :
    Inscription : avril 2007
    Messages : 901
    Points : 1 137
    Points
    1 137
    Par défaut
    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.
    Formulaires XForms sur tous navigateurs sans extension à installer (architecture XRX) : http://www.agencexml.com/xsltforms/

  7. #7
    Membre expérimenté

    Profil pro
    Inscrit en
    août 2002
    Messages
    1 249
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : août 2002
    Messages : 1 249
    Points : 1 745
    Points
    1 745
    Par défaut Evolution des bases de données : un point de vue développeur.
    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.

  8. #8
    Membre éprouvé Avatar de alain.couthures
    Profil pro
    Gérant
    Inscrit en
    avril 2007
    Messages
    901
    Détails du profil
    Informations personnelles :
    Localisation : France, Gironde (Aquitaine)

    Informations professionnelles :
    Activité : Gérant

    Informations forums :
    Inscription : avril 2007
    Messages : 901
    Points : 1 137
    Points
    1 137
    Par défaut
    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 !
    Formulaires XForms sur tous navigateurs sans extension à installer (architecture XRX) : http://www.agencexml.com/xsltforms/

  9. #9
    Membre expérimenté

    Profil pro
    Inscrit en
    août 2002
    Messages
    1 249
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : août 2002
    Messages : 1 249
    Points : 1 745
    Points
    1 745
    Par défaut Sens du Typage et Evolution des programmes.
    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.

  10. #10
    Membre expert

    Profil pro
    Inscrit en
    février 2006
    Messages
    3 437
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : février 2006
    Messages : 3 437
    Points : 3 527
    Points
    3 527
    Par défaut
    Citation Envoyé par voyageur Voir le message
    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 .

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

  11. #11
    Membre du Club
    Profil pro
    Inscrit en
    janvier 2007
    Messages
    141
    Détails du profil
    Informations personnelles :
    Âge : 36
    Localisation : Tunisie

    Informations forums :
    Inscription : janvier 2007
    Messages : 141
    Points : 59
    Points
    59
    Par défaut
    Citation Envoyé par pifor Voir le message
    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..

  12. #12
    Rédacteur/Modérateur

    Avatar de Fabien Celaia
    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    octobre 2002
    Messages
    4 184
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 51
    Localisation : Suisse

    Informations professionnelles :
    Activité : Administrateur de base de données
    Secteur : Service public

    Informations forums :
    Inscription : octobre 2002
    Messages : 4 184
    Points : 19 413
    Points
    19 413
    Billets dans le blog
    25
    Par défaut
    Citation Envoyé par halloula Voir le message
    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...
    Sr DBA Oracle / MS-SQL / MySQL / Postgresql / SAP-Sybase / Informix / DB2

    N'oublie pas de consulter mes articles, mon blog, les cours et les FAQ SGBD

    Attention : pas de réponse technique par MP : pensez aux autres, passez par les forums !

  13. #13
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    septembre 2006
    Messages
    7 588
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Spécialiste en bases de données
    Secteur : Conseil

    Informations forums :
    Inscription : septembre 2006
    Messages : 7 588
    Points : 28 997
    Points
    28 997
    Billets dans le blog
    16
    Par défaut
    Les chiffres parlent d'eux-mêmes, cf. :

    http://www.oracle.com/corporate/anal...dbms/34052.pdf
    (a) Faites simple, mais pas plus simple ! (A. Einstein)
    (b) Certes, E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)

    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench
    Je ne réponds pas aux questions techniques par MP. Les forums sont là pout ça.

  14. #14
    Membre expérimenté

    Profil pro
    Inscrit en
    août 2002
    Messages
    1 249
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : août 2002
    Messages : 1 249
    Points : 1 745
    Points
    1 745
    Par défaut Synthèse:
    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.

  15. #15
    Expert éminent sénior
    Avatar de orafrance
    Profil pro
    Inscrit en
    janvier 2004
    Messages
    15 967
    Détails du profil
    Informations personnelles :
    Âge : 44
    Localisation : France

    Informations forums :
    Inscription : janvier 2004
    Messages : 15 967
    Points : 19 070
    Points
    19 070
    Par défaut
    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...)

    Citation Envoyé par elbj Voir le message
    mais énormément en rapidité, efficacité et optimisation. C'est une évolution moins visible.
    et haute dispo

  16. #16
    Membre éclairé

    Profil pro
    Inscrit en
    mai 2005
    Messages
    414
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : mai 2005
    Messages : 414
    Points : 660
    Points
    660
    Par défaut
    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 !

  17. #17
    Rédacteur en Chef
    Avatar de Marc Lussac
    Homme Profil pro
    Responsable marketing opérationnel
    Inscrit en
    mars 2002
    Messages
    28 652
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Responsable marketing opérationnel
    Secteur : Communication - Médias

    Informations forums :
    Inscription : mars 2002
    Messages : 28 652
    Points : 58 650
    Points
    58 650
    Par défaut
    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...
    Ne pas me contacter pour le forum et je ne répondrai à aucune question technique. Pour contacter les différents services du club (publications, partenariats, publicité, ...) : Contacts

    15 000 offres d'emploi développeurs et informatique
    Cours et tutoriels développeurs et informatique
    Les FAQ's & Les Livres
    Codes sources
    Téléchargements

  18. #18
    Rédacteur
    Avatar de lunatix
    Homme Profil pro
    Architecte technique
    Inscrit en
    novembre 2002
    Messages
    1 960
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Architecte technique

    Informations forums :
    Inscription : novembre 2002
    Messages : 1 960
    Points : 3 645
    Points
    3 645
    Par défaut
    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

  19. #19
    Membre averti
    Profil pro
    Inscrit en
    août 2005
    Messages
    270
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : août 2005
    Messages : 270
    Points : 339
    Points
    339
    Par défaut
    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.

  20. #20
    jnore
    Invité(e)
    Par défaut
    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.



    Citation Envoyé par jmguiche Voir le message
    ...des chargements d’épice de DUNE...
    Excellent..., depuis le dormeur s'est réveillé !!!

Discussions similaires

  1. Réponses: 4
    Dernier message: 15/03/2011, 02h30
  2. Réponses: 4
    Dernier message: 15/03/2011, 02h30
  3. Réponses: 0
    Dernier message: 07/12/2010, 20h27
  4. Réponses: 0
    Dernier message: 07/12/2010, 20h27
  5. Avenir des bases de données relationnelles ?
    Par LordBob dans le forum Décisions SGBD
    Réponses: 53
    Dernier message: 31/10/2005, 00h27

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo