Bonjour,
pouvez - vous m'indiquer des sites où je pourrais trouver des cours sur les bases de données orientées objet.
Merçi,
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
[SGBDOO] Base de données orientée objet
Bonjour,
pouvez - vous m'indiquer des sites où je pourrais trouver des cours sur les bases de données orientées objet.
Merçi,
Le SGBD le plus orienté objet que je connaisse est O2 mais c'est un SGBD universitaire. Sinon il parait que Db2 aurait sorti une nouvelle version orienté objet.
Après il y a PostgreSQL (si on peut appeler ça de l'objet).
justement, a ce propos,
j'aimerais savoir dans quelle mesure le concept d'objet est utilisé dans postgreSQL. Toutes mes recherches sur le web restent infructueuses, et la doc officielle ne mentionne que les "large objects"...
A part la notion d'héritage, je ne saisis pas bien a quoi sert ce concept dans ce SGBD.
merci
Il y a une différence de taille entre BDOO et SGBDR incorporant des notions objet (oracle 8i, Sybase 12, ...). Les BDOO sont encore très "académiques" et le marché ne les a pas suivies, ormis dans des cas très spécifiques. A ma connaissance, PostgreSQL n'est pas O2
:
Je suis du meme avis. Je dirais meme plus, sauf peut etre pour des cas rarissime, ca sert a rien une BDOO. C'est du délire de chercheur qui a toujours rien trouvé d'utile tout en étant payé avec nos impots.Envoyé par fadace
Je sais que des "furieux" dans un service de la Délégation Générale pour l'Armement s'en servent ou s'en sont servis, mais ça reste du "bricolage de dessus de paillasse de laboratoire"
Bonjour,
Pour db2, a ma connaissance il n'y a pas de oo mais plutot des mappeurs.
Pour l'bdoo, qd les perf seront à la hauteur pourquoi pas mais pour l'instant ce n'est pas le cas sauf pour des petites bases =)
j'en ai juste entendu parler mais je crois que CloudScape (gratuit) s'oriente object.
Cas d'utilisation d'une BDDOO: gestion de galeries d'images. Comme un type TEXT ou INT, il peut existe des types objets comme IMAGE, SOUND, MUSIC, VIDEO... Dans le cas d'une galerie les images ne sont pas stocker sous forme de JPG ou GIF sur le disque dur mais dans la BDD elle-mêmes. Les images ne sont plus des ressources à part entière mais font parties de la BDD, ce qui permet de mettre à un même niveau les ressources textes, identifiants et les images.
Mais ca n'est que la théorie. Et quand je tombe sur des personnes qui veulent l'appliquer à MySQL... j'ai peur
JM
Je crois que tu confonds objet au sens C++ et objets au sens "blob"
Bonjour,
Je parlais d'objets au sens BLOB du terme
Après avoir cherché et lu des nombreuses infos sur le sujet, je suis arrivé à la conclusion suivante: une BDD comme MySQL suffit largement à contenter la majeure partie des besoins que l'on peut avoir en tant que développeur d'application. Que les grands esprits s'amusent avec les BDDOO et autres, les BDD d'aujourd'hui c'est un peu comme le C d'hier.
Quand on me parle de BLOBs, je pense fichiers. Je n'en ai encore jamais eu besoin. Est-ce que vous vous en servez ? Si oui, pour faire quoi ?
JM
Ben pour moi un BLOB contenant un fichier, c'est pas la même chose qu'un lien stocké en base vers un fichier situé sur un serveur de fichier.
Pour moi, un blob est utile quand la donnée que tu y stockes fait partie intégrante de tes données.
Ex, tu gères des photos/images radios/scanner de patient ds ton appli (médicale ds l'ex). Ben ces images là font partie intégrante de tes données.
De cette façon, les imports/exports de base sont cohérants et tu n'est pas dépendant de l'OS et/ou de l'API utilisé par ton serveur de fichier pour accéder aux dits fichiers.
Voilà, ms cela n'engage que moi !
McFoggy
Bonjour,
Oui tu as parfaitement raison, je n'ai pas dit le contraire! Tout dépend de l'application après. Pour une galerie on peut apprécier le fait d'avoir directement accès aux images avec un visualisateur par exemple. On peut directement mettre à jour les images, pas besoin de la BDD. Mais un lien existe toujours entre l'image et l'entrée image de la BDD, un ID, un nom de fichier... Je sais qu'il existe de nombreux outils pour voir les BLOBs comme des images, sons... MyAdmin je crois ou quelque chose qui ressemble à PhpMyAdmin. Ca permet de gérer la galerie directement à partir de la BDD. Je pense aussi que ca peut pénaliser les performanes d'une application. Par exemple, pour afficher une image, on doit lire le BLOB image depuis la BDD alors qu'avec un fichier, on génère simplement un tag HTML IMG puis le navigateur s'occupe du reste. C'est ce genre de choses qui font pencher la balance d'un côté ou de l'autre. Le même problème se pose pour une BDD d'articles par exemple, lire un HTML ou stocker l'article dans un TEXT (BLOB non binaire après tout)... Certains ne passent pas par une BDD car ils pensent que c'est peu fiable, en un sens ils ont raison, on perd la BDD, on perd tout, mais si on stocke sur DD, on perd le DD on perd tout
J'ai relu la doc de MySQL au niveau des BLOBs car j'espérais trouver quelques idées:
MySQL Manual 6.2.3.2 The BLOB and TEXT Types
http://www.mysql.com/doc/en/BLOB.html
J'ai été assez déçu car il n'y a pas grand chose, ou peut-être que j'ai loupé le chapitre.
Tu as un lien vers l'application médicale dont tu nous parles ? Cela m'intéresse, idem pour un quelconque gestionnaire de BDD pseudo-OO (galeries et autres).
JM
Il y à aussi une très bonne gestion des BLOB's sous interbase, avec des capacités très avancées comme des BLOB's filters et autres.
Dans le cas général, un sgbdoo ne sert à rien, tout peu etre fait par un sgbd SQL, avec des blobs si nécessaire. C'est uniquement une question d'analyse correcte du besoin et de définir la solution.
Une personne qui ne maitrise pas les SGBDR et veux se lancer dans les SGBDOO parce qu'il se sait pas analyser va droit à la catastrophe...
Il faut impérativement commencer par apprendre à maitriser les SGBDR, si vous n'y arrivez pas vous ne fera pas mieux avec un sgbdoo, vous ferez pire...
Je pense que le problème se pose car les SGBDOOs ne sont pas assez mûres. J'ai essayé Interbase et ca n'est pas le genre de monstre dont j'ai besoin, petit MySQL me suffire ^^
Par contre au niveau des langages de programmation, la donne est différente, on préconise VB pour un débutant car le langage est simple est puissant. Il est entre le C et le C++ en ayant tous les avantages et sans les inconvénients.
Je suis curieux de voir où on en sera dans 10 ans
Pour ceux que ca intéressent il y a des infos très intéressantes sur le sujet dans l'ouvrage de G. Gardarin. Indispensable que l'on soit débutant ou expert!
JM
Qui préconise VB6 ?
VB 6 est à éviter, et c'est pas à préconiser aux débutants, lire :
http://www.developpez.net/forums/viewtopic.php?t=26915
http://www.developpez.com/vbasic/temoignage.htm
http://www.developpez.com/delphi/bombe.htm
La vrai préconisation pour débuter :
http://www.developpez.net/forums/viewtopic.php?t=3264
VB6 est à préconiser pour RIEN, vu que VB6 est abandonné.
Plutot que de faire les idiots et de parler d'utiliser un sgbdoo + un langage pas objet, il faut au contraire utiliser comme tous le monde un SGBDR (99,9%) et un outil et/ou un langage OBJET, exemples : C++ , Java, Delphi, VB.NET, C#, etc...
un sgbdoo, ça sert surtout à un utilisateur qui veut créer ses propres types de données, comme des structures par exemple, non ?
j'ai déjà fait ça avec Oracle 8i en utilisant des tables imbriquées (nested table)
ex : on crée le type adresse comme étant une structure comprenant ceci :
adresse(adr_perso ; adr_prof)
ce nouveau type est imbriqué dans une table relationnelle classique...
à part créer de nouveaux objets, ça sert à quoi un sgbdoo ???
Là je suis d'accord avec asphp, un sgbdo est utile pour créer ses propres structures et nouveaux types. Appliquer la techno objet.
Il doit etre possible d'utiliser l"héritage sur les objets.
Il faut bien faire la différence entre la technologie orienté objet et les objets de type text, image, son ... : ultra rien a voire.
Bonjour
Petit retour d'expérience en matière de SGBDO (je sais, ça ne répond pas à la question initiale du demandeur qui recherche des cours)
C'était en 98. La direction de ma boîte (éditeur de logiciels), inspirée par de grands penseurs, décide de lancer un progiciel de GRH résolument moderne qui va casser la baraque. Il faut faire de l'objet pour être dans le coup, et on choisit donc Java comme langage et Objectstore comme SGBD purement objet.
Les P166, qui étaient de belles machines à cette époque, rament lamentablement sous ce duo infernal. Les clients intéressés nous demandent quelle config matérielle il leur faut. Nous, bien emmerdés : ben en matière de PC, on n'a pas encore trouvé de machine suffisante...
Les pros du SGBDO, soyons honnêtes, y'en avait pas des palanquées sur le marché. On a donc fait appel massivement à des prestataires venus d'outre Atlantique, à 2500 ou 3000 balles par jour. Au plus fort du projet, une vingtaine de personnes bossaient dessus.
Spécialistes ou pas, on s'est rendu compte qu'il fallait souvent, dans ce cadre technique et conceptuel, inventer la roue, qui n'existait pas. Et continuer à gérer les problèmes de performances, réadapter le code existant aux sous-versions successives de Java, assimiler réellement le concept de données en tant que variables persistantes encapsulées dans des fonctions d'accès.
Et se casser les dents et s'arracher les cheveux pour construire un requêteur qui était prisonnier d'un mode d'accès hiérarchique, à 10 lieues de la souplesse du relationnel.
Je ne parle pas des redéfinitions en cours de route du cahier des charges, eu égard aux impossibilités techniques rencontrées en cours de route.
En 2001 (me semble-t-il), on apprend qu'Objectstore a mis la clé sous la porte, son produit n'ayant jamais trouvé de marché.
2002, on abandonne le projet, après plusieurs dizaines de millions de francs d'investissement.
Autre vision : début 2000, j'étais à une conférence Oracle 8i, avec petits fours, hôtesses canon et tout ce qui s'ensuit.
Les mecs de chez Oracle présentent les apports de la 8i, et nous jouent un long morceau de violon sur le i du 8i.
Arrivé à la séance de questions, je demande à ces messieurs : et les fonctionnalités objet introduites en 8.0, qu'en est-il ? La réponse fut claire : les fonctionnalités objet n'ont pas rencontré d'intérêt très marqué auprès de la clientèle, et les priorités d'Oracle sont recentrées sur l'intégration Internet et la facilité d'administration.
Bref, ne surtout pas faire du SGBDO pour être à la mode (aujourd'hui, cette mode est passée sans avoir jamais été très vivace), mais en faire si le SGBDO présente un avantage indiscutable. Il semble que les projets qui sont dans ce cas ne soient pas si nombreux...
Quant à un cours, je peux suggérer le livre "Bases de données orientées objet : origines et principes" chez Armand Colin. Ce bouquin date de 93 et présente les choses d'une manière conceptuelle. Ce n'est absolument pas un mode d'emploi.
Je suis tout à fait d'accord avec vous. Comment appelle-t-on un SGBD où l'on peut faire un héritage de table ? Sans doute un SGBDR... Je crois que l'on peut faire ça avec Postgre. Ca permettrait d'éviter les duplications de champs et autre que l'on fait avec un SGBDR comme MySQL. Pour ce qui est des SGBDOO j'ai trouvé des solutions bien plus souples: SGBDR + support de fichiers. Par exemple pour gérer des images, la BDD contient le nom du fichier, un identifiant, les chemins... Et le support matériel stocke les données. Car pour afficher une image à partir d'une BDD... Niveau ressource c'est loin d'être optimum. Sauf si on utilise une SBGDOO professionnelle, et je suis loin d'en avoir les moyens
JM
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager