ah dès que tu rajoutes une couche, tu perds forcement un peu de temps... mais je coute plus cher à la journée qu'une barrete de ram alors si ca me fait gagner 3 j de dev par mois, ca vaut le coup...
Mais je suis d'accord avec toi sur beaucoup de points.
d'accord... moi, ce que je vois, c'est que si on veut programmer en objet, on a pas à utiliser un SGBDO... car c'est une couche ou on a pas besoin d'aller.
Une classe hibernate toute bete est gérée dans ton appli et hibernate se charge de la mettre dans la base.
et comme les sgbd sont de supers produits, je ne vois pas un seul avantage à utiliser un SGBDO.
en fait, ce qui me gene et je me repete, c'est de faire :
- des objets au nivo applicatif
- des requetes sql pour faire communiquer ces objets avec le sgbdr.
je préfère juste :
- faire des objets au nivo applicatif
et le support de sauvegarde des données, je m'en fous mais comme les SGBDR sont les plus rapides et les plus utilisés... je préfère m'en servir non ?
C'est du discours de marketeux à la petite semaine.
Bon, beh je laisse tomber, si tes arguments, c'est "Je connais pas mais c'est pas possible", c'est pas la peine, la discution était quand même interessante.
Renseigne toi sur J2EE ou sur hibernate et JTA...
tu verras que beaucoup de gens ont développé des solutions très propre, qui sont en production et qui font une abstraction de la base de données.
quand tu crées un utilisateur par exemple, il va falloir lui créer une adresse par défaut et tout un tas d'autres trucs... et à mon avis, c'est une grosse erreur de mettre la logique métier dans les triggers.
en fait, je pars du principe qu'un SGBD est le plus performant outil de gestion des données qui existent et qu'ils écrasent en performance les SGBDO et de plus, on sait tous se serveir des SGBD et pas des SGBDO alors pkoi les utiliser ces SGBDO ?
Vu qu'on travaille en objet, on ne voit pas la base, autant que ce soit la meilleur mais j'ai pas envie de la voir.
Bon, en effet, tu ne connais pas les ejbs et les serveurs d'applications J2EE.
Les ejb ne font pas de transactionnel, ne sont pas des serveurs qui supporte plusieurs requête en parallèle et doivent gérer le conflit, etc...
Les EJB tournent dans des serveurs d'applications J2EE comme Websphere, Weblogic, Oracle 9i AS, Sun One application serveur, JBoss ou JOnAS, ils sont transactionnels, gèrent les requêtes en parralèle, supporte le clustering....
Pour finir, je dirais qu'on peut développer sans se soucier de la base de données, c'est possible.
L'utilisateur final peut utilise psql ou MS-Access, ou faire un script php, il n'y aura pas de problème côté donnée
beh je suis pas d'accord avec toi... désolé mais l'intégrité des données ne se gère pas seulement avec des contraintes.
Pour moi, les données seront bonnes si et seulement si on met la logique métier à un endroit centralisé et qu'elle est testée avec des test unitaires.
Il faut créer des fonctions creerCommande(idClient, date)... et c'est ainsi que les données seront cohérentes car on sera sur que chacun aura pas fait sa sauce dans son coin.
Je rajoute juste quelques trucs :
- J'utilise aussi les procédures stockées
- Hibernate permet de voir les requêtes SQL executées et je ne l'ai jamais vu faire de trucs "inutiles", je l'ai plutot défois vu utiliser le cache judiciseusement.
Je répète que mon fil de discution n'avait pour but à la base que de dire que dans certains cas ( le cas par exemple d'une appli utilisant un outil de mapping O/R ) la base de données MySQL avec sa vélocité peut être une bonne solution
Meme si perso, j'utilise Firebird au cas où on ai besoin de procédure stockées ou d'autres trucs évolués.
mmm on a du mal à se comprendre mais c'est interessant :)
Ce que je veux dire, c'est que mon but dans le dev est de le rendre plus simple et indépendant de la base de données ce qui est tout à fait possible...
Exemple de code :
Transaction tx = null;
Keyword kw = new Keyword( 1,"red" );
tx = session.beginTransaction();
session.save( kw );
tx.commit();
Et voila, j'utilise une transaction, je sauve des données sans taper une ligne de SQL et sans avoir de code de connexion à la base de données.
Je ne veux pas utiliser de code spécifique à une base de données et ainsi pouvoir en changer suivant les besoins.
et avec ça, je voulais dire au début que la base de données MySQL peut très bien convenir dans de très nombreux devs et si le besoin s'en fait sentir... on change de base en changeant juste un fichier de config.
tu ne comprends pas. le SQL et les bases de données sont des outils géniaux qui sont parféitement complet.
Mais quand tu fais un site web avec des utilisateurs, tu vas permettre, par exemple, d'administrater les utilisateurs.
Alors tu vas écrire un objet Utilisateur avec ton insert, ton delete et ton update sql... beh je trouve ça répétitif et intutile.
Quand je crée un utilisateur, je fais :
Utilisateur u = new Utilisateur();
u.setNom("TRAUMAT");
u.setPrenom("Stéphane");
et c'est tout, je vais pas me connecter à une base, je vais pas faire les requetes de select, update, insert et delete pour gérer les utilisateurs... j'ai envie que quelqu'un d'autre s'en charge ! et que les données soient stockées dans un SGBD !
Je ne propose pas de standard, je dis juste qu'il est mieux d'utiliser des objets et de laisser quelque chose style hibernate se charger des stocker les données dans la base ( faire les requêtes )
Mon but etait juste de dire que Les SGBD sont les meilleurs endroits pour stocker les données mais que le développeur ne devrait plus avoir a se taper toutes les requetes sql bidons update, insert et delete par exemple pour gérer les données.
Juste pour t'expliquer pour les ejbs ( mais il y avait d'autres solutions ), sont des objets "classique" et le conteneur se charge de gérer la persistence.
Les ejbs font parti de l'applicatif. A aucun moment, tu n'as pas de code qui se connecte à une bd ou tu n'as de requetes sql d'update, insert ou delete....
Je ne suis pas hors sujet car le sujet dont on parlait au début etait que, pour moi, on devait pouvoir changer de base comment ou voulait d'où l'utilité de l'abstraction et du mapping O/R.
Quand au multi plateforme, les ejbs facade sont automatiquement exportable en webservices donc tu as ton multi platforme de cette façon et c'est normalisé.
Donc idéalement, il faut laisser au SGBD le rôle de gérer (et pas seulement stocker) les données. Ou tu considères que SQL n'est pas un standard d'accès aux données et que tu considère que ejb est le standard des systèmes d'accès aux SGBD. Mais il n'y a pas que Java.
Ce n'est pas ça que je dis,
je dis que le SGBD doit gérer les données et qu'il doit y avoir entre le SGBDR et tes objets une couche qui te masque la persistence.
je ne parle pas spécifiquemnt de java, les outils de mapping O/R existent dans tous les langages, mon idée était qu'il fallait mieux utiliser une couche de mapping O/R pour arriver à devenir indépendant de la base de données.
Quand on développe un site en PHP, on est indépendant du serveur web non ? beh pour moi, quand on développe en objet, on doit etre indépendant de la bd.
merci :) j'ai toujorus un avis de 18/20 donc ça va ;)
Je n'ai pas mis d'arguments car je voulais pas lancer de débat, je voulais juste que les gens qui connaissent pas aille voir ce produit et se rende compte que Firebird est une merveilleuse alternative.
Je voulais pas de débat, juste attiser la curiosité, j'en ai payé le prix :)
je te parle d'utiliser des objets... forcement, si tu as une appli qui fait n'importe quoi sur ta base, ton application objet n'y peut rien, c'est bein évident.
l'intégrité des données dont je parle ne réside pas dans les clients mais dans la logique métier qui doit etre centralisée.
imagine maintenant une appli normale avec des ejb cmp pour gérer la persistance, des ejb de facade pour contenir la logique métier. (logique métier testé via tests unitaires)
toutes les applis qui seront développés font appel à la logique métier des ejbs.
j'ai lu et toi ? il parlait des bases de données objet.
et pour avoir regarder un peu comment bossait hibernate et le cache hibernate, je peux te dire que ca doit pas etre beaucoup plus lent que sql pur et le gain de temps de dev est appréciable
Je ne parle pas de vieilles haches de guerre....
je te parle de ce qui se passe aujroud'hui et je ne parle pas des bases de données objets..
Je parle des outils de mapping Objet/relationnel tel que les EJB CMP, JDO ou hibernate et ce n'est pas du domaine du reve, c'est utilisé tous les jours et de plus en plus.
Et ca gère les jointures sauf qu'on a un concept plus "parlant", les Collections... un client a une Collection de Factures par exemples et un client.getFactures() équivaut à une jointure.
C'est ce qui se passe aujourd'hui et meme microsoft pépare son objectspace je crois ? non ?
en tout cas, dans notre société, nous utilisons l'abtrasction JDBC et on a pas de code spécifique aux bases de données, on développe avec HSQBD et on change de bd au besoin.
Je ne suis pas d'accord.. je pense que les applications devraient seulement manipuler les objets et ces objets devraient juste etre sauvegarder dans une base de données.
L'intégrité peut etre gérer dans les objets... et les backups, sauvegardes... c'est bien entendu une fonctionnalité des bases de données.
Je ne dis pas que les bases de données ne servent à rien, je dis juste qu'on devrait pouvoir en changer comme de chemise :)
Après tout, le SQL étant "standard" et les logiciels étant pour beaucoup orienté objet... pkoi s'inquieter de la base de données choisie ?
on peut meme faire des clusters de bases de données différentes et de manière transparente avec des produits comme C-JDBC alors pourquoi se focaliser tant dessus ?
MySQL est simple a mettre en oeuvre et pour beaucoup d'applications, la base de données ne sert qu'à stocker des données et MySQL est très fort pour ça :)
et je pense d'ailleurs que la base de données ne devrait servir qu'à stocker des données ;)
En fait, je pense qu'on devrait pouvoir changer des base de données comme de chemise...
Quand je développe une appli, autant la développer avec hsqldb par exemple et au moment du déploiement, en fonction des besoins, l'utilisateur choisit une base de données.
Essayez le :)
Plus simple à installer, bons outils de devs dispo, leger et facile à aborder !
et il y a aussi la disponibilité pour s'en servir en embedded, je sais pas si postgreSQL permet ça ?
[^] # Re: Et mysql
Posté par Stéphane Traumat (site web personnel) . En réponse à la dépêche Première bêta de PostgreSQL 8. Évalué à 2.
http://java.sun.com/j2se/1.3/docs/api/java/io/Serializable.html(...)
D'ailleurs les objets hibernate sont des classes simples qui n'implémente pas l'interface serialization..
http://about.me/straumat
[^] # Re: Et mysql
Posté par Stéphane Traumat (site web personnel) . En réponse à la dépêche Première bêta de PostgreSQL 8. Évalué à 3.
Mais je suis d'accord avec toi sur beaucoup de points.
http://about.me/straumat
[^] # Re: Et mysql
Posté par Stéphane Traumat (site web personnel) . En réponse à la dépêche Première bêta de PostgreSQL 8. Évalué à 3.
Une classe hibernate toute bete est gérée dans ton appli et hibernate se charge de la mettre dans la base.
et comme les sgbd sont de supers produits, je ne vois pas un seul avantage à utiliser un SGBDO.
http://about.me/straumat
[^] # Re: Et mysql
Posté par Stéphane Traumat (site web personnel) . En réponse à la dépêche Première bêta de PostgreSQL 8. Évalué à 2.
http://about.me/straumat
[^] # Re: Et mysql
Posté par Stéphane Traumat (site web personnel) . En réponse à la dépêche Première bêta de PostgreSQL 8. Évalué à 2.
- des objets au nivo applicatif
- des requetes sql pour faire communiquer ces objets avec le sgbdr.
je préfère juste :
- faire des objets au nivo applicatif
et le support de sauvegarde des données, je m'en fous mais comme les SGBDR sont les plus rapides et les plus utilisés... je préfère m'en servir non ?
http://about.me/straumat
[^] # Re: Et mysql
Posté par Stéphane Traumat (site web personnel) . En réponse à la dépêche Première bêta de PostgreSQL 8. Évalué à 2.
Bon, beh je laisse tomber, si tes arguments, c'est "Je connais pas mais c'est pas possible", c'est pas la peine, la discution était quand même interessante.
Renseigne toi sur J2EE ou sur hibernate et JTA...
tu verras que beaucoup de gens ont développé des solutions très propre, qui sont en production et qui font une abstraction de la base de données.
http://about.me/straumat
[^] # Re: Et mysql
Posté par Stéphane Traumat (site web personnel) . En réponse à la dépêche Première bêta de PostgreSQL 8. Évalué à 2.
quand tu crées un utilisateur par exemple, il va falloir lui créer une adresse par défaut et tout un tas d'autres trucs... et à mon avis, c'est une grosse erreur de mettre la logique métier dans les triggers.
http://about.me/straumat
[^] # Re: Et mysql
Posté par Stéphane Traumat (site web personnel) . En réponse à la dépêche Première bêta de PostgreSQL 8. Évalué à 2.
Vu qu'on travaille en objet, on ne voit pas la base, autant que ce soit la meilleur mais j'ai pas envie de la voir.
http://about.me/straumat
[^] # Re: Et mysql
Posté par Stéphane Traumat (site web personnel) . En réponse à la dépêche Première bêta de PostgreSQL 8. Évalué à 2.
http://about.me/straumat
[^] # Re: Et mysql
Posté par Stéphane Traumat (site web personnel) . En réponse à la dépêche Première bêta de PostgreSQL 8. Évalué à 3.
Les ejb ne font pas de transactionnel, ne sont pas des serveurs qui supporte plusieurs requête en parallèle et doivent gérer le conflit, etc...
Les EJB tournent dans des serveurs d'applications J2EE comme Websphere, Weblogic, Oracle 9i AS, Sun One application serveur, JBoss ou JOnAS, ils sont transactionnels, gèrent les requêtes en parralèle, supporte le clustering....
Pour finir, je dirais qu'on peut développer sans se soucier de la base de données, c'est possible.
L'utilisateur final peut utilise psql ou MS-Access, ou faire un script php, il n'y aura pas de problème côté donnée
beh je suis pas d'accord avec toi... désolé mais l'intégrité des données ne se gère pas seulement avec des contraintes.
Pour moi, les données seront bonnes si et seulement si on met la logique métier à un endroit centralisé et qu'elle est testée avec des test unitaires.
Il faut créer des fonctions creerCommande(idClient, date)... et c'est ainsi que les données seront cohérentes car on sera sur que chacun aura pas fait sa sauce dans son coin.
http://about.me/straumat
[^] # Re: n'oublions pas les perfs
Posté par Stéphane Traumat (site web personnel) . En réponse à la dépêche Première bêta de PostgreSQL 8. Évalué à 2.
- J'utilise aussi les procédures stockées
- Hibernate permet de voir les requêtes SQL executées et je ne l'ai jamais vu faire de trucs "inutiles", je l'ai plutot défois vu utiliser le cache judiciseusement.
Je répète que mon fil de discution n'avait pour but à la base que de dire que dans certains cas ( le cas par exemple d'une appli utilisant un outil de mapping O/R ) la base de données MySQL avec sa vélocité peut être une bonne solution
Meme si perso, j'utilise Firebird au cas où on ai besoin de procédure stockées ou d'autres trucs évolués.
http://about.me/straumat
[^] # Re: n'oublions pas les perfs
Posté par Stéphane Traumat (site web personnel) . En réponse à la dépêche Première bêta de PostgreSQL 8. Évalué à 2.
http://about.me/straumat
[^] # Re: Et mysql
Posté par Stéphane Traumat (site web personnel) . En réponse à la dépêche Première bêta de PostgreSQL 8. Évalué à 2.
Ce que je veux dire, c'est que mon but dans le dev est de le rendre plus simple et indépendant de la base de données ce qui est tout à fait possible...
Exemple de code :
Transaction tx = null;
Keyword kw = new Keyword( 1,"red" );
tx = session.beginTransaction();
session.save( kw );
tx.commit();
Et voila, j'utilise une transaction, je sauve des données sans taper une ligne de SQL et sans avoir de code de connexion à la base de données.
Je ne veux pas utiliser de code spécifique à une base de données et ainsi pouvoir en changer suivant les besoins.
et avec ça, je voulais dire au début que la base de données MySQL peut très bien convenir dans de très nombreux devs et si le besoin s'en fait sentir... on change de base en changeant juste un fichier de config.
http://about.me/straumat
[^] # Re: C'est pas pour troller mais...
Posté par Stéphane Traumat (site web personnel) . En réponse à la dépêche Première bêta de PostgreSQL 8. Évalué à 1.
http://about.me/straumat
[^] # Re: Et mysql
Posté par Stéphane Traumat (site web personnel) . En réponse à la dépêche Première bêta de PostgreSQL 8. Évalué à 3.
Mais quand tu fais un site web avec des utilisateurs, tu vas permettre, par exemple, d'administrater les utilisateurs.
Alors tu vas écrire un objet Utilisateur avec ton insert, ton delete et ton update sql... beh je trouve ça répétitif et intutile.
Quand je crée un utilisateur, je fais :
Utilisateur u = new Utilisateur();
u.setNom("TRAUMAT");
u.setPrenom("Stéphane");
et c'est tout, je vais pas me connecter à une base, je vais pas faire les requetes de select, update, insert et delete pour gérer les utilisateurs... j'ai envie que quelqu'un d'autre s'en charge ! et que les données soient stockées dans un SGBD !
Je ne propose pas de standard, je dis juste qu'il est mieux d'utiliser des objets et de laisser quelque chose style hibernate se charger des stocker les données dans la base ( faire les requêtes )
Mon but etait juste de dire que Les SGBD sont les meilleurs endroits pour stocker les données mais que le développeur ne devrait plus avoir a se taper toutes les requetes sql bidons update, insert et delete par exemple pour gérer les données.
http://about.me/straumat
[^] # Re: C'est pas pour troller mais...
Posté par Stéphane Traumat (site web personnel) . En réponse à la dépêche Première bêta de PostgreSQL 8. Évalué à 1.
http://about.me/straumat
[^] # Re: Et mysql
Posté par Stéphane Traumat (site web personnel) . En réponse à la dépêche Première bêta de PostgreSQL 8. Évalué à 3.
Les ejbs font parti de l'applicatif. A aucun moment, tu n'as pas de code qui se connecte à une bd ou tu n'as de requetes sql d'update, insert ou delete....
Je ne suis pas hors sujet car le sujet dont on parlait au début etait que, pour moi, on devait pouvoir changer de base comment ou voulait d'où l'utilité de l'abstraction et du mapping O/R.
Quand au multi plateforme, les ejbs facade sont automatiquement exportable en webservices donc tu as ton multi platforme de cette façon et c'est normalisé.
Donc idéalement, il faut laisser au SGBD le rôle de gérer (et pas seulement stocker) les données. Ou tu considères que SQL n'est pas un standard d'accès aux données et que tu considère que ejb est le standard des systèmes d'accès aux SGBD. Mais il n'y a pas que Java.
Ce n'est pas ça que je dis,
je dis que le SGBD doit gérer les données et qu'il doit y avoir entre le SGBDR et tes objets une couche qui te masque la persistence.
je ne parle pas spécifiquemnt de java, les outils de mapping O/R existent dans tous les langages, mon idée était qu'il fallait mieux utiliser une couche de mapping O/R pour arriver à devenir indépendant de la base de données.
Quand on développe un site en PHP, on est indépendant du serveur web non ? beh pour moi, quand on développe en objet, on doit etre indépendant de la bd.
http://about.me/straumat
[^] # Re: C'est pas pour troller mais...
Posté par Stéphane Traumat (site web personnel) . En réponse à la dépêche Première bêta de PostgreSQL 8. Évalué à 1.
Je n'ai pas mis d'arguments car je voulais pas lancer de débat, je voulais juste que les gens qui connaissent pas aille voir ce produit et se rende compte que Firebird est une merveilleuse alternative.
Je voulais pas de débat, juste attiser la curiosité, j'en ai payé le prix :)
http://about.me/straumat
[^] # Re: Et mysql
Posté par Stéphane Traumat (site web personnel) . En réponse à la dépêche Première bêta de PostgreSQL 8. Évalué à 1.
l'intégrité des données dont je parle ne réside pas dans les clients mais dans la logique métier qui doit etre centralisée.
imagine maintenant une appli normale avec des ejb cmp pour gérer la persistance, des ejb de facade pour contenir la logique métier. (logique métier testé via tests unitaires)
toutes les applis qui seront développés font appel à la logique métier des ejbs.
http://about.me/straumat
[^] # Re: Et mysql
Posté par Stéphane Traumat (site web personnel) . En réponse à la dépêche Première bêta de PostgreSQL 8. Évalué à 1.
et pour avoir regarder un peu comment bossait hibernate et le cache hibernate, je peux te dire que ca doit pas etre beaucoup plus lent que sql pur et le gain de temps de dev est appréciable
http://about.me/straumat
[^] # Re: Et mysql
Posté par Stéphane Traumat (site web personnel) . En réponse à la dépêche Première bêta de PostgreSQL 8. Évalué à 1.
je te parle de ce qui se passe aujroud'hui et je ne parle pas des bases de données objets..
Je parle des outils de mapping Objet/relationnel tel que les EJB CMP, JDO ou hibernate et ce n'est pas du domaine du reve, c'est utilisé tous les jours et de plus en plus.
Et ca gère les jointures sauf qu'on a un concept plus "parlant", les Collections... un client a une Collection de Factures par exemples et un client.getFactures() équivaut à une jointure.
C'est ce qui se passe aujourd'hui et meme microsoft pépare son objectspace je crois ? non ?
en tout cas, dans notre société, nous utilisons l'abtrasction JDBC et on a pas de code spécifique aux bases de données, on développe avec HSQBD et on change de bd au besoin.
http://about.me/straumat
[^] # Re: Et mysql
Posté par Stéphane Traumat (site web personnel) . En réponse à la dépêche Première bêta de PostgreSQL 8. Évalué à 2.
L'intégrité peut etre gérer dans les objets... et les backups, sauvegardes... c'est bien entendu une fonctionnalité des bases de données.
Je ne dis pas que les bases de données ne servent à rien, je dis juste qu'on devrait pouvoir en changer comme de chemise :)
Après tout, le SQL étant "standard" et les logiciels étant pour beaucoup orienté objet... pkoi s'inquieter de la base de données choisie ?
on peut meme faire des clusters de bases de données différentes et de manière transparente avec des produits comme C-JDBC alors pourquoi se focaliser tant dessus ?
http://about.me/straumat
[^] # Re: Et mysql
Posté par Stéphane Traumat (site web personnel) . En réponse à la dépêche Première bêta de PostgreSQL 8. Évalué à 5.
et je pense d'ailleurs que la base de données ne devrait servir qu'à stocker des données ;)
En fait, je pense qu'on devrait pouvoir changer des base de données comme de chemise...
Quand je développe une appli, autant la développer avec hsqldb par exemple et au moment du déploiement, en fonction des besoins, l'utilisateur choisit une base de données.
http://about.me/straumat
[^] # Re: C'est pas pour troller mais...
Posté par Stéphane Traumat (site web personnel) . En réponse à la dépêche Première bêta de PostgreSQL 8. Évalué à 1.
http://about.me/straumat
[^] # Re: C'est pas pour troller mais...
Posté par Stéphane Traumat (site web personnel) . En réponse à la dépêche Première bêta de PostgreSQL 8. Évalué à 2.
Plus simple à installer, bons outils de devs dispo, leger et facile à aborder !
et il y a aussi la disponibilité pour s'en servir en embedded, je sais pas si postgreSQL permet ça ?
http://about.me/straumat