> beh pour moi, quand on développe en objet, on doit etre indépendant de la bd.
C'est là que tu ne comprends pas...
SQL est indépendant de la bd. La base de donnée peut-être en mémoire vive ou n'importe où ailleur, ça ne change rien.
Tout ce que tu proposes, c'est de remplacer un standard par un autre. C-à-d remplacer SQL par ejb. Or l'objectif de SQL n'est pas celui de ejb (tel que le je comprend) et les deux peuvent cohabiter.
Par exemple SQL vérifie les données (ce que ne doit pas faire normalement l'applicatif ou ejb) et ton objet ejb indique que les ventes du mois ont été minables par rapport aux objectifs fixés par le patron (ce que ne fait pas SQL).
Déplacer ce qui doit être fait par le SGBD dans ejb (ou ailleur) car le SGBD est "insuffisant" n'est pas LA solution. C'est un workaround.
Si ton objectif est de dire qu'SQL n'est pas suffisament implémenté (ce qui est un problème pour l'intéropérabilité des bases de donnée (nb : je ne fais pas de hors-sujet)), et que ejb peut -être une solution pour contourner ce problème, alors je suis d'accord. Mais faut pas tout mélanger.
Ton "mapping", abstraction de donnée, etc... (avec ejb) est hors sujet. Cette problématique se pose pour les fichiers txt (gestion de named), exploitation du bus pci, etc...
[^] # Re: Et mysql
Posté par Ayrton . En réponse à la dépêche Première bêta de PostgreSQL 8. Évalué à 3.
C'est là que tu ne comprends pas...
SQL est indépendant de la bd. La base de donnée peut-être en mémoire vive ou n'importe où ailleur, ça ne change rien.
Tout ce que tu proposes, c'est de remplacer un standard par un autre. C-à-d remplacer SQL par ejb. Or l'objectif de SQL n'est pas celui de ejb (tel que le je comprend) et les deux peuvent cohabiter.
Par exemple SQL vérifie les données (ce que ne doit pas faire normalement l'applicatif ou ejb) et ton objet ejb indique que les ventes du mois ont été minables par rapport aux objectifs fixés par le patron (ce que ne fait pas SQL).
Déplacer ce qui doit être fait par le SGBD dans ejb (ou ailleur) car le SGBD est "insuffisant" n'est pas LA solution. C'est un workaround.
Si ton objectif est de dire qu'SQL n'est pas suffisament implémenté (ce qui est un problème pour l'intéropérabilité des bases de donnée (nb : je ne fais pas de hors-sujet)), et que ejb peut -être une solution pour contourner ce problème, alors je suis d'accord. Mais faut pas tout mélanger.
Ton "mapping", abstraction de donnée, etc... (avec ejb) est hors sujet. Cette problématique se pose pour les fichiers txt (gestion de named), exploitation du bus pci, etc...