Publicité
+ Répondre à la discussion
Page 1 sur 2 12 DernièreDernière
Affichage des résultats 1 à 20 sur 34

Discussion: sgbdo vs sgbdr

  1. #1
    Invité de passage
    Inscrit en
    avril 2005
    Messages
    6
    Détails du profil
    Informations forums :
    Inscription : avril 2005
    Messages : 6
    Points : 0
    Points
    0

    Par défaut sgbdo vs sgbdr

    Bonjour,

    Je suis désolé de vous déranger.
    Je suis entrain de faire une petite étude sur les SGBDO.
    J'ai besoin de quelques retours d'expérience.

    En fait je dois répondre à la question suivante :
    Pourquoi les SGBDO n'ont pas de succès comme les sgbdr ?
    est ce à cause des performances insatisfaisantes,
    est ce à cause de la complexité de mise en place ou impasse des professionnels ?

    Merci pour vos réponses.

    Cordialement,

  2. #2
    Rédacteur
    Avatar de orafrance
    Inscrit en
    janvier 2004
    Messages
    15 966
    Détails du profil
    Informations personnelles :
    Âge : 37

    Informations forums :
    Inscription : janvier 2004
    Messages : 15 966
    Points : 18 731
    Points
    18 731

    Par défaut

    je crois que c'est simplement dû au fait que les SGBDR habituelles intégrent déjà les objets. Les objets ne sont en plus pas vitaux puisque la modélisation Merise tend à "casser" les objets en tables statiques. Les analystes étant habitués à cela ne ressente pas le besoin d'un SGBDO. Enfin, c'est probablement trop nouveau encore et on manque de compétence.

    Tout ceci ne sont qu'allégation, j'imagine ces raisons mais je ne suis pas sûr que ce soit la réalité

  3. #3
    Invité de passage
    Inscrit en
    avril 2005
    Messages
    6
    Détails du profil
    Informations forums :
    Inscription : avril 2005
    Messages : 6
    Points : 0
    Points
    0

    Par défaut

    Merci pour votre réponse Orafrance,

    C'est un argument de plus, merci beaucoup.

    Est ce que vous avez des retours d'expériences sur des entreprises qui ont utilisé les SGBDO ?

    Merci encore.

  4. #4
    Rédacteur/Modérateur
    Avatar de fadace
    Homme Profil pro Fabien Celaia
    Administrateur de base de données
    Inscrit en
    octobre 2002
    Messages
    3 935
    Détails du profil
    Informations personnelles :
    Nom : Homme Fabien Celaia
    Âge : 44
    Localisation : Suisse

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

    Informations forums :
    Inscription : octobre 2002
    Messages : 3 935
    Points : 15 888
    Points
    15 888

    Par défaut

    Les SGBDO sont venus des milieux académiques et pas d'une demande utilisateur.

    Les problèmes de performances n'ont jamais vraiment été résolus.

    En fait, les éditeurs de SGBDR ont à peu près tout fait pour faire mourir le bébé dans l'oeuf

  5. #5
    Invité de passage
    Inscrit en
    avril 2005
    Messages
    6
    Détails du profil
    Informations forums :
    Inscription : avril 2005
    Messages : 6
    Points : 0
    Points
    0

    Par défaut

    Merci Fadace pour ces arguments,

    J'ai vraiments du mal à trouver des gens qui en ont fait.
    Qui pourront me donner leur avis.

    Mais que penser des produits comme versant, JDO, ...

    Merci encore.

  6. #6
    Membre Expert
    Avatar de Adjanakis
    Profil pro
    Inscrit en
    avril 2004
    Messages
    739
    Détails du profil
    Informations personnelles :
    Localisation : France, Pas de Calais (Nord Pas de Calais)

    Informations forums :
    Inscription : avril 2004
    Messages : 739
    Points : 1 333
    Points
    1 333

    Par défaut



    Pour ma part, j'ai utilisé 2 SGBDO. Le premier, durant mes études, s'appelait O2. L'un des premiers serveur purement Objet. Il était sympa dans l'idée, mais vraiment pas pratique! Il fallait développer toute son appli dans le serveur de base de données, ça plantait tout le temps, bref... il fallait vraiment revoir la copie. Il était par exemple impossible de porter du code déjà fait auparavent dans ce SGBDO...

    Sinon j'ai aussi utilisé, et utilise toujours ObjectDB qui est une solution JDO. Superbe d'ailleurs! Une fois que l'ont a compris le fonctionnement de JDO ça marche sur toutes les implémentations, quelles soient purement objet ou relationnelles-objets. Mais, dans ce contexte, j'ai préféré utiliser ObjectDB car c'est un serveur qui utilise à fond la structure de Java. Lorsque l'ont utilise le client, il est possible de faire des requêtes utilisant les méthodes des objets stockés, ce qui m'aurait été impossible en utilisant un SGBD tel que MySQL. Par contre, je doute que ObjectDB supporte bien la montée en charge.

    Néanmoins pour que l'objet entre dans les entreprises, il faudra déjà que les informaticiens s'y mettent. A mon boulot, sur 15 informaticiens, je suis le seul à connaitre un langage orienté objet. Si cette situation est possible en 2005, je ne crois pas qu'il soit concevable que les entreprises passent le pas. Surtout que pour les sociétés intéressées, il existe de bonnes solutions de mapping Objet-Relationnel.

  7. #7
    Invité de passage
    Inscrit en
    avril 2005
    Messages
    6
    Détails du profil
    Informations forums :
    Inscription : avril 2005
    Messages : 6
    Points : 0
    Points
    0

    Par défaut

    Merci Adjanakis pour ces éclaircissements.

    Donc, si je comprend bien l'avenir est dans les SGBDO-R et dans le mapping objet vers relationnel.

    Merci encore à vous tous.

  8. #8
    Membre du Club
    Inscrit en
    avril 2003
    Messages
    79
    Détails du profil
    Informations forums :
    Inscription : avril 2003
    Messages : 79
    Points : 53
    Points
    53

    Par défaut

    J'ai fait de la BD objet en licence info, donc y a un peu plus de 2 ans.
    Ca ne ce fait pas dans toutes les facs je pense.
    Ils me semble qu'on avait fait ça sur Oracle, donc si Oracle supporte l'objet ...

    Par contre cette année en cours, un intervenant de chez Renault disais que pour eux ce qui les interessais c'etait les performances et que l'objet n'a pas vraiment fait ces preuves a ce niveau, mais bon je doute qu'ils aient vraiment essayé ou même qu'ils en soient capable. Et de toutes façon c'est tellement enorme leur datawarehouse qu'ils peuvent pas vraiment s'amuser a experimenter avec des technologies nouvelles.

    Bref il y a deux sons de cloches.
    Mais je trouve que en objet c'est quand même beaucoup plus naturel, au niveau de la modelisation.
    Les tables utilitaires et uniquement relationnelles disparaissent vite.
    La notion de pointeur peu aussi paraitre bizarre.

  9. #9
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro Frédéric BROUARD
    Expert SGBDR & SQL
    Inscrit en
    mai 2002
    Messages
    13 456
    Détails du profil
    Informations personnelles :
    Nom : Homme Frédéric BROUARD
    Localisation : France

    Informations professionnelles :
    Activité : Expert SGBDR & SQL
    Secteur : Conseil

    Informations forums :
    Inscription : mai 2002
    Messages : 13 456
    Points : 29 817
    Points
    29 817

    Par défaut

    Il y a un autre argument de poids contre le SGBDOO. J'avais rencontré les équipes commerciales et de dev de O² .

    En fait l'absence de client est essentiellement dû au poids du passé : comment jusitifier le passage d'une BD relationnelle vers un BDOO pour des quantité de données pharamineuses alors que les programmes qui utilisent ces énormes masses de données sont encore en Cobol ?

    Les BDOO sont arrivée trop tôt et n'assurait pas la continuité des bases de données relationelles.

    Ce handicap est maintenant franchi du fait de l'évolution des bases de données R vers l'objet, c'est à dire la base de données, objet relationnel.
    Ceci a été introduit avec la nouvelle norme SQL:1999.
    A lire dans mon prochain bouquin à paraître chez PearsonEduc (en collaboration avec Christian Soutou)


    A +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Blog SQL, SQL Server, modélisation données : http://blog.developpez.com/sqlpro
    http://www.sqlspot.com : modélisation, conseils, audit, optimisation, formation
    * * * * * Enseignant CNAM PACA - ISEN Toulon - CESI Aix en Provence * * * * *

  10. #10
    Invité régulier
    Profil pro
    Inscrit en
    octobre 2004
    Messages
    29
    Détails du profil
    Informations personnelles :
    Localisation : France, Rhône (Rhône Alpes)

    Informations forums :
    Inscription : octobre 2004
    Messages : 29
    Points : 9
    Points
    9

    Par défaut

    Moi aussi je dois comparer SGBDR et SGBDO.
    En fait jusqu'a il ya peu de temps je ne connaissais que les BD
    Relationnelles.
    Je suis juste au debut de mon etude mais ce que j'en vois:

    - construire une SGBDR a partir d'un modele UML peut s'averer laborieux
    malgre l'existance d'outils dedies. On est encore loin de la generation
    automatique de code qui fait tout tout seul comme on veut et sans probleme.

    - construire un SGBDO a partir d'un modele UML c'est du gateau

    - j'avoue que je suis un peu manchot avec le SGBDO ou n'existe plus la
    notion de cle .; enfin certains concepts propres aux SGBDR et bien
    pratiques ne s'y retrouve pas .. a ce jour ca me gene un peu

    - cote performance, j'attends de voir mais on m'a dit que les BD Objets sont particulierement performantes

    - les BD objets je n'en connais pas beaucoup: le seule que je connais
    est representee par quelques dizaines de personnes dans le monde.
    Ca me generait de lancer un projet avce un outil aussi peu represente!

    Voila .. je te transmettrais mes retours (d'ici 1-2 mois)
    Je suis preneuse d'informations si tu en as (perfs? etc.)

  11. #11
    Membre à l'essai
    Homme Profil pro
    Étudiant
    Inscrit en
    janvier 2013
    Messages
    20
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Sénégal

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : janvier 2013
    Messages : 20
    Points : 23
    Points
    23

    Par défaut

    Salut à tous,

    Je veux relancer le débat.
    Depuis 2005 jusqu'en 2013, il doit y avoir des changements. Est ce que quelqu'un peut m'aider en me fournissant des arguments solides et à jour motivant l'usage d'un SGBDR par rapport à un SGBDO ou vice à versa ?

  12. #12
    Modérateur
    Avatar de al1_24
    Homme Profil pro Alain
    Ingénieur d'études décisionnel
    Inscrit en
    mai 2002
    Messages
    5 618
    Détails du profil
    Informations personnelles :
    Nom : Homme Alain
    Âge : 53
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Ingénieur d'études décisionnel
    Secteur : Conseil

    Informations forums :
    Inscription : mai 2002
    Messages : 5 618
    Points : 13 634
    Points
    13 634

    Par défaut

    Commence par chercher les SGBDO commercialisés aujourd'hui, ce sera un bon moyen d'évaluer si c'est une technologie qui a de l'avenir.
    Modérateur Langage SQL
    Règles du forum Langage SQL à lire par tous, N'hésitez pas à consulter les cours SQL
    N'oubliez pas le bouton et pensez aux balises
    [code]
    Si une réponse vous a aidé à résoudre votre problème, n'oubliez pas de voter pour elle en cliquant sur
    Aide-toi et le forum t'aidera : Un problème exposé sans mentionner les tentatives de résolution infructueuses peut laisser supposer que le posteur attend qu'on fasse son travail à sa place... et ne donne pas envie d'y répondre.

  13. #13
    Membre à l'essai
    Homme Profil pro
    Étudiant
    Inscrit en
    janvier 2013
    Messages
    20
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Sénégal

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : janvier 2013
    Messages : 20
    Points : 23
    Points
    23

    Par défaut

    Citation Envoyé par al1_24 Voir le message
    Commence par chercher les SGBDO commercialisés aujourd'hui, ce sera un bon moyen d'évaluer si c'est une technologie qui a de l'avenir.
    Merci de votre réponse.
    Mais pour vous, dans quel cas serait-il plus juducieux un SGBDO par rapport à un SGBDR ou l'inverse ?
    Pour info, je suis entrain de développer une application basée sur la technologie Java EE, avec Tomcat comme serveur d'application et je veux choisir entre un SGBDR ou un SGBDO tout en motivant mon choix.

  14. #14
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro Frédéric BROUARD
    Expert SGBDR & SQL
    Inscrit en
    mai 2002
    Messages
    13 456
    Détails du profil
    Informations personnelles :
    Nom : Homme Frédéric BROUARD
    Localisation : France

    Informations professionnelles :
    Activité : Expert SGBDR & SQL
    Secteur : Conseil

    Informations forums :
    Inscription : mai 2002
    Messages : 13 456
    Points : 29 817
    Points
    29 817

    Par défaut

    Par darwinisme, les SGBDOO n'existent pratiquement plus....
    Le marché est réduit à peau de chagrin, et pour essayer de vendre des licences, les quelques éditeurs qui ont cela a leur catalogue en propose une version "libre" dont l'avenir est plus qu'incertain.
    La raison de cette disparition : il est impossible d'indexer n'importe quel type d'objet. Or ce qui fait la force des SGBDR c'est avant tout l'indexation et les contraintes.
    Sans index le système reste lent.
    On sait cependant indexer certaines formes d'objet, pour certaines requêtes. Quelques exemples :
    • le spatial, pour des recherches de proximités entre objets
    • le XML pour certains prédicats des requêtes XQuery XPath.

    mais aujourd'hui, les bons SGBD relationnels intègrent tout cela de manière native... Exemple MS SQL Server.

    Mis à part des applications très particulières, il n'y a donc aucun intérêt d'utiliser un SGBD OO

    A +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Blog SQL, SQL Server, modélisation données : http://blog.developpez.com/sqlpro
    http://www.sqlspot.com : modélisation, conseils, audit, optimisation, formation
    * * * * * Enseignant CNAM PACA - ISEN Toulon - CESI Aix en Provence * * * * *

  15. #15
    Membre à l'essai
    Homme Profil pro
    Étudiant
    Inscrit en
    janvier 2013
    Messages
    20
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Sénégal

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : janvier 2013
    Messages : 20
    Points : 23
    Points
    23

    Par défaut

    OK merci de m'avoir répondu.
    Cependant, lorsqu'on développe une application à partir d'un langage de programmation OO, ne serait-il pas mieux d'utiliser un SGBDO comme db4o plutôt qu'utiliser un SGBDR afin de ne pas être obligé d'adapter les deux mondes (monde orienté objet et monde relationnel) ?

  16. #16
    Modérateur
    Avatar de CinePhil
    Homme Profil pro Philippe Leménager
    Ingénieur d'études en informatique
    Inscrit en
    août 2006
    Messages
    13 819
    Détails du profil
    Informations personnelles :
    Nom : Homme Philippe Leménager
    Âge : 51
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Ingénieur d'études en informatique
    Secteur : Enseignement

    Informations forums :
    Inscription : août 2006
    Messages : 13 819
    Points : 24 808
    Points
    24 808

    Par défaut

    La POO existe maintenant depuis pas mal d'années (2 décennies au moins je pense) et est très utilisée.
    Si c'était vraiment mieux d'utiliser un SGBDOO avec la POO, les SGBDOO, Les SGBDR classiques seraient des dinosaures en voie de disparition et seraient remplacés par des SGBDOO. Visiblement, ce n'est pas le cas.
    CQFD !

    Il y a plusieurs manières de faire communiquer les objets d'un POO et les tables d'une BDDR :
    1) via les Objets Réellement Merdiques qui semblent a priori pratiques mais nécessitent un temps d'apprentissage inutile de leur pseudo SQL, génèrent eux mêmes des requêtes souvent plus compliquées que celles qu'un programmeur SQL normal aurait écrites et de ce fait sont moins performants que du SQL natif ;
    2) via un modèle objet constitué de vues SQL qui sont les seules interrogées par l'application mais qui sont, selon le SGBD utilisé, pas toujours pratiques pour la mise à jour des données ;
    3) via la programmation en bases de données épaisses, c'est à dire en utilisant massivement les procédures SQL, le programme appelant une procédure SQL qui se charge de faire le boulot de mise à jour des données.

    La meilleure solution est la combinaison des 2 dernières méthodes :
    - mapping objet sur les vues SQL ;
    - ajout, mise à jour, suppression de données en appelant des procédures SQL.
    Philippe Leménager. Ingénieur d'étude à l'École Nationale de Formation Agronomique. Autoentrepreneur.
    Mon blog sur la conception des BDD, le langage SQL, le PHP avec Zend Framework...
    « Ce que l'on conçoit bien s'énonce clairement, et les mots pour le dire arrivent aisément ». (Nicolas Boileau)
    À la maison comme au bureau, j'utilise la suite Linux Mageïa !

  17. #17
    Membre chevronné
    Profil pro François
    Inscrit en
    février 2010
    Messages
    411
    Détails du profil
    Informations personnelles :
    Nom : François

    Informations forums :
    Inscription : février 2010
    Messages : 411
    Points : 744
    Points
    744

    Par défaut

    A noter, Oracle peut travailler avec des objets.

    Mais ça soulève très vite tout un ta de problème: genre pour faire un ORDER BY, ou un DISTINCT il faut créer une fonction de comparaison. A priori simple, mais entre deux objets "HOMME" comment on les classe? Par date de naissance, taille, poids? Et une fois ça décidé, faire une fonction qui compare les objets deux à deux, c'est avoir un temps de tri énorme, là ou un simple hash permettrait d'aller immensément plus vite.

    Mais bon pareil, la doc pour l'orienté objet dans la BdD est pas très classe.

  18. #18
    Membre à l'essai
    Homme Profil pro
    Étudiant
    Inscrit en
    janvier 2013
    Messages
    20
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Sénégal

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : janvier 2013
    Messages : 20
    Points : 23
    Points
    23

    Par défaut

    Citation Envoyé par CinePhil Voir le message
    La POO existe maintenant depuis pas mal d'années (2 décennies au moins je pense) et est très utilisée.
    Si c'était vraiment mieux d'utiliser un SGBDOO avec la POO, les SGBDOO, Les SGBDR classiques seraient des dinosaures en voie de disparition et seraient remplacés par des SGBDOO. Visiblement, ce n'est pas le cas.
    CQFD !
    C'est clair. Merci pour la démonstration.

    Cependant, vous avez énuméré 3 méthodes pour faire communiquer les objets d'un POO avec une BDDR. Personnellement, je n'en connais que deux :
    1) On utilise un framework de persistance comme Hibernate en Java qui permet de faire la translation entre le monde orienté objet et le monde relationnel. Ce framework utilise comme langage d'interrogation des classes persistantes, le HQL (Hibernate Query Langage) dont la syntaxe est proche du SQL.
    2) On utilise directement des requêtes SQL dans le POO et on se charge de faire des adaptations entre types (type SQL et type du langage POO).

    Par souci de compréhension, merci de me fournir un exemple pratique pour comprendre les 3 méthodes que vous avez énuméré précédemment.

    Citation Envoyé par CinePhil Voir le message
    - mapping objet sur les vues SQL ;
    - ajout, mise à jour, suppression de données en appelant des procédures SQL.
    D'autre part, qu'appelez vous "vue SQL" et "procédure SQL" ?
    Ne seraient-ils pas des requêtes SQL ?
    Désolé, si mon niveau est si faible !

  19. #19
    Modérateur
    Avatar de CinePhil
    Homme Profil pro Philippe Leménager
    Ingénieur d'études en informatique
    Inscrit en
    août 2006
    Messages
    13 819
    Détails du profil
    Informations personnelles :
    Nom : Homme Philippe Leménager
    Âge : 51
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Ingénieur d'études en informatique
    Secteur : Enseignement

    Informations forums :
    Inscription : août 2006
    Messages : 13 819
    Points : 24 808
    Points
    24 808

    Par défaut

    Citation Envoyé par lamine87 Voir le message
    Cependant, vous avez énuméré 3 méthodes pour faire communiquer les objets d'un POO avec une BDDR. Personnellement, je n'en connais que deux :
    1) On utilise un framework de persistance comme Hibernate en Java qui permet de faire la translation entre le monde orienté objet et le monde relationnel. Ce framework utilise comme langage d'interrogation des classes persistantes, le HQL (Hibernate Query Langage) dont la syntaxe est proche du SQL.
    Ça, c'est la première méthode que je décrivais... avec tous les défauts engendrés par les ORM !
    - langage "proche" du SQL mais en réalité plus complexe et carrément galère quand il s'agit de faire des requêtes un peu complexes ;
    - construction des requêtes par l'ORM pas du tout optimisée.

    2) On utilise directement des requêtes SQL dans le POO et on se charge de faire des adaptations entre types (type SQL et type du langage POO).
    Ça c'est une 4ème méthode que je n'avais pas mentionnée car c'est en quelque sorte la moins professionnelle : on attaque directement les tables en écrivant les requêtes SQL et en les envoyant au SGBD. Ça fonctionne mais s'il y a modification de la structure des données, il faut aussi revoir les programmes qui utilisent la BDD.

    Par souci de compréhension, merci de me fournir un exemple pratique pour comprendre les 3 méthodes que vous avez énuméré précédemment.
    Citation Envoyé par CinéPhil
    - mapping objet sur les vues SQL ;
    - ajout, mise à jour, suppression de données en appelant des procédures SQL.
    Un ORM fait classiquement un mapping objet sur les tables de la BDD. Il est même capable de construire tout seul les opérations CRUD sur les tables.
    Mais ce mapping ne correspond généralement pas à la construction des objets métier car dans une BDDR, les données sont réparties dans plusieurs tables pour optimiser leur accès.

    Exemple...
    On peut définir une classe "personne" avec les propriétés suivantes : nom, prenom, adresse, date_naissance, tel_fixe, tel_portable, courriel.
    Par contre, une adresse est composée au moins de la partie rue, d'un code postal et d'une ville, laquelle est située dans un pays. C'est donc une propriété multivaluée et plusieurs adresses seront dans la même ville qu'il est inutile de répéter dans la base de données. Il y aura donc une table des villes et une clé étrangère référençant la ville dans la table des personnes si on considère qu'une personne n'a qu'une adresse, ou dans la table des adresses si on considère qu'elle peut en avoir plusieurs ou qu'on ne connaît pas forcément l'adresse de toutes les personnes enregistrées dans la BDD.
    On voir aussi qu'une personne peut avoir plusieurs numéros de téléphone.

    La solution consiste à modéliser de manière rigoureuse les données en séparant villes, pays, téléphones et personnes puis de réaliser une vue, c'est à dire une requête enregistrée, qui reconstitue la structure souhaitée pour l'objet métier personne.

    Ce principe peut être généralisé pour réaliser ce que j'ai appeler un modèle objet qui est propre à l'application utilisatrice et correspond à la logique métier. On peut aussi l'appeler le "modèle organisationnel de données" en méthode Merise, de la même manière qu'il existe un "Modèle organisationnel des traitements".

    Ensuite, le programme n'interroge que les vues qui sont à sa disposition. Si la structure des données change, il suffit de modifier la vue qui conservera, elle, la même structure (les mêmes colonnes de résultat) et il n'y a pas besoin de modifier les programmes.

    Les vues s'interrogent en effet comme des tables :
    Code SQL :
    1
    2
    SELECT -- les colonnes
    FROM la_vue

    Par contre, selon le SGBD utilisé, il peut être impossible de mettre à jour les données à travers une vue ; on ne peut pas toujours faire UPDATE la_vue ou bien DELETE FROM la_vue, ni même de INSERT INTO la_vue.

    Il convient alors d'utiliser une procédure SQL, c'est à dire un programme qui va réaliser toutes les requêtes nécessaires, pour ces opérations d'insertion, de mise à jour ou de suppression.

    De la même manière qu'en POO, on appelle une fonction publique d'une classe sans se préoccuper de toute la salade faite par cette fonction, en base de données épaisse, on appelle une procédure SQL sans savoir concrètement ce qu'elle fait dans la BDD mais en étant sûr de la solidité du résultat.
    Un article de SQLPro sur le développement en bases de données épaisses est disponible ici.
    Philippe Leménager. Ingénieur d'étude à l'École Nationale de Formation Agronomique. Autoentrepreneur.
    Mon blog sur la conception des BDD, le langage SQL, le PHP avec Zend Framework...
    « Ce que l'on conçoit bien s'énonce clairement, et les mots pour le dire arrivent aisément ». (Nicolas Boileau)
    À la maison comme au bureau, j'utilise la suite Linux Mageïa !

  20. #20
    Membre à l'essai
    Homme Profil pro
    Étudiant
    Inscrit en
    janvier 2013
    Messages
    20
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Sénégal

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : janvier 2013
    Messages : 20
    Points : 23
    Points
    23

    Par défaut

    Un seul mot à CinePhil : Merci !

Liens sociaux

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •