Le projet Ozone a pour but principal d'offrir aux développeurs une base de données purement objet et purement Java. On peut noter certaines contributions du projet Apache dans la distribution d'Ozone, à savoir Xerces-J et Xalan-J.
Aller plus loin
- Le site d'Ozone (23 clics)
- La page de download (2 clics)
- XML Apache projects (1 clic)
- Apache Xerces-J (1 clic)
- Apache Xalan-J (2 clics)
# Yeah ... Pas mal :)
Posté par Anonyme . Évalué à 0.
Au passage, maintenant que plus personne n'oserais renier l'interet d'utiliser de la programation Objet : Pourquoi encore utiliser des base de données relationelles pour les NOUVEAUX projets (sans existants)? le temps pass à faire la mise en table et le mapping O/R pourrait etre pasé sur bien d'autres choses ...
Merci Ozone :)
LM.
[^] # Re: Yeah ... Pas mal :)
Posté par G. R. (site web personnel) . Évalué à 1.
Parce-que la base installée en relationnelle est gigantesque.
De plus, l'absence rélle de normes sur les protocoles d'échanges et sur les langages de manipulation est un frein quant à l'implantation des bases objet.
Dernier point, les gains en service restent à démontrer, et le relationnel est une excelente abstration (ce qu'une base objet n'arrive pas toujours à réaliser).
[^] # T'as pas du bien lire :
Posté par Anonyme . Évalué à 0.
Donc le coup du parc installé, meme si c'est une des raisons globales, dans ce cas particulier, c'est plutot raté.
"Norme de protocole d'echange" de quel echange tu parles ? les DBMS/R en on un ? j'ai du rater un episode ...
"language de manipulation" pourquoi justement rechercher un truc de ce style, une hierarchie objet se satisfait entierement d'un traversal de relationship dans 99% des cas et pour le restant une requete OQL conclut !
Les gains en service ? moi je parle simplement de gains en temps de dev ! on passe son temps à faire la mise en table puis à faire la mapping ... c'est purement ridicule : tu modelise, puis demodelise puis re-remodelise ... vraiment c'est tout de meme assez deroutant pour un neophite non ?
Le relationel une excelent abstraction? si tu suis les formes normales et dans des cas simple je veux bien te l'accorder ... Mais je peux te garantir que le nombre de dev. qui modelisent et passent en Forme Normale leur shema de SGDB/R ne sont pas legions !
L'un des concept novateurs des SGBD/O est la migration de schema, cela signifie qu'un stockage de données peut evoluer de forme dans le temps. C'est tres puissant, et extremement pratique car cela permet d'eviter les longues sequences de : savegarde, drop, create, modification, rechargement des SGDB/R .
Pour moi les freins sont seulement psychologiques et plus du tout technique (ceux qui n'on jamais vu une demo de versant ne seront certainement pas OK avec mes propos ...) ...
Ainsi, bcp de personnes preferent rester dans un etat de fait : le bricolage , plutot que de rationaliser leur stockage de données une fois pour toute !
Pourquoi ? tout simplement encore et encore par peur ;) et oui c'est la peur qui fait dire au techniciens, je vais pas prendre de risque, c'est encore la peur qui fait prendre aux responsables le choix d'utiliser Oracle, et c'est encore la peut qui fait prendre Windows pour les postes clients !
Ah la peur ....
Un jour ou l'autre, sous sa forme actuelle ou sous une forme idoine, la base de données à structuration objet vaincra, de la meme façon que les languages objets on maintenant surplantés les autres ;)
"I have a dream ..."
3hck.
[^] # Re: T'as pas du bien lire :
Posté par Rozé Étienne . Évalué à 1.
Mais il est vrai que quand on sait faire quelque chose de fonctionnel, il n'est pas évident de changer de technique...( temps de formation, paresse naturelle, ...) sans en plus être sur que cela donnera quelque chose de mieux.
Personnellement je suis fort intéressé par les SGBD/O et serait ravi que tu donnes des liens vers des documentations qui aideraient à faire le saut...merci d'avance
[^] # Tu as 100% raison ;)
Posté par Anonyme . Évalué à 0.
Le cout de formation !!!
Pour moi la paresse dont je suis doté me laisse tout naturellement pencher vers l'objet, car je sais qu'il me sera plus simple (et donc moins de truc à faire) par une methode objet que pas une methode relationelle.
Mais la formation, oui c'est bien LE probleme !
Je me suis interessé depuis longtemps aux base de données objets, que j'ai decouvert lors de mes etudes. Aujourd'hui, je suis confronté à des murs lorsque j'essaye de positioner un SGBD/O chez un client.
Dernierement encore j'ai eut une discussion avec un gros client (grosse boite). Il m'expliquait qu'ils etaient de plus en plus interessés par les SGBD/O mais qu'ils ne trouvaient pas de competances !
Moi, je lui est expliqué que faute de petit projet, la monté en compétance n'ayant jamais été effectué par les ingenieurs de la boite ou je suis, il n'etait pas question pour nous de partir sur un gros projet.
En effet, aujourd'hui les seuls projets en france utilisants des SGBD/O sont des projets tentaculaires (principalement FT, EDF). Ils ont leur propre filiere de formation, leur propre filiere de support (en partenariat direct avec les editeurs type versant).
Tout fonctionnant en vase clos, il est impossible pour les autres d'avoir un retour d'experience :(
Donc avant de donner un cout à la formation, il faut trouver les formateurs ... et la : NADA :(
Pour JDO, OQL et API ODMG
http://www.odmg.org/(...)
Des articles
http://www.odbmsfacts.com/(...)
Je pense que ozonedb est une bon depart. Si Versant ce decide à faire une version Foundation gratuite alors le test par toi meme serait le plus pertinent.
Une derniere remarque, bcp de vendeurs de SGBD/O ont modifié leur offre en : moteur B2B, ou conteneur J2EE ... ca change pas grand chose au noyau, mais evite l'effet "has been" du SGBD/O ;)
@+
3hck
# Re: Ozone: la première version stable disponible
Posté par Enti . Évalué à 1.
J'ai besoin de cette information si qq'un peut m'aider!!!
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.