Quel est l'intérêt d'utiliser Hibernate ?

Bonjour,

Je souhaiterais que des personnes puissent m'éclairer et m'aider à trouver des arguments concernant l'intérêt d'Hibernate.

J'ai intégré une équipe utilisant Sybase, Java et entre les deux Hibernate. Je suis un peu en conflit avec ce dernier. En effet, sur une application légère, Hibernate pose plus de problème qu'autre chose. C'est un petit site avec pas plus d'une dizaine de règles de gestion, pas plus de 5-8 utilisateurs connectés en même temps, moins de 10 tables SQL, BlazeDS et Java et Hibernate qui semblent mal implémentés.

De ce que j'ai vu pour l'instant, avec Hibernate on perd complètement la main sur la base de données, dans le sens où je ne peux pas optimiser les tables, placer des vues, proposer des procédures stockées où il y a une requête propre. En effet, le métier n'est pas côté base mais Java. J'ai mal à la tête lorsque je vois ce que fait faire Hibernate à la base de données concernant les requêtes SQL.
Là ou je me pose beaucoup de questions concernant les performances sur la base de données, au vu de ce que je vois passer, si jamais je fais un test de monté en charge, j'ai l'impression que les performances vont lâcher d'un coup.
Les arguments qu'on a tenté de me vendre concernant le choix d'Hibernate sont :
- Il n'y a pas besoin de créer des méthodes/fonctions dans la base de données c'est Hibernate qui gère tout, donc gain de temps et c'est lié au développement objet de l'application.
- c'est utilisé dans beaucoup d'entreprises - mmmh mouais :?

Jusqu'à présent l'inconvénient principal que j'ai remarqué c'est la performance et la sécurité côté base de données.

J'aimerais connaitre votre avis car je pense que ceux qui m'en parlent n'ont pas de réel d'argument convainquant, pour moi qui a mal pour notre SGBD, dont j'ai plus la main à cause d'Hibernate. :roll:
De plus, je ne voudrais pas trop critiquer Hibernate sans savoir.

Merci

L'avantage d'hibernate c'est clairement de masquer la logique relationelle aux développeurs objets et/ou d'interconnecter "facilement" des objets avec une base de données "business" existante.
La partie relationelle étant laissé aux experts en base de données (écriture des fichiers de mapping notemment).

Hibernate étant une surcouche, il y a forcément un coût en ressource. En revanche il offre une gestion (optimale ?) de cache, qui te fait gagner en performance (c'est également à prendre en compte pour les montées en charge).

Ensuite Hibernate ne te prive pas d'utiliser des vues/procédures stockées/SQL.

Quoi qu'il arrive, il faut faire un pont entre le monde relationnel de la base de données et le monde objet de Java.
La question est donc qu'est-ce qui coûte le moins en mémoire, CPU, temps de développement, robustesse du produit (les bugs ca coutent cher en argent et en image à une boîte), qualité/complexité du code, etc.

Citation:

---

Envoyé par Nemek

L'avantage d'hibernate c'est clairement de masquer la logique relationelle aux développeurs objets et/ou d'interconnecter "facilement" des objets avec une base de données "business" existante.
La partie relationelle étant laissé aux experts en base de données (écriture des fichiers de mapping notemment).

Hibernate étant une surcouche, il y a forcément un coût en ressource. En revanche il offre une gestion (optimale ?) de cache, qui te fait gagner en performance (c'est également à prendre en compte pour les montées en charge).

Ensuite Hibernate ne te prive pas d'utiliser des vues/procédures stockées/SQL.

Quoiqu'il arrive, il faut faire un pont entre le monde relationnel de la base de données et le monde objet de Java.
La question est donc qu'est-ce qui coûte le moins en mémoire, CPU, temps de développement, robustesse du produit (les bugs ca coutent cher en argent et en image à une boîte), qualité/complexité du code, etc.

---

Merci pour ton intervention. En effet, je sais que lors du démarrage du serveur, il y a une monté en charge des données. Je précise bien que hibernate est mal implémenté chez nous. Lorsque je vois que le principal problème c'est hibernate, je fais le rapport coût, indisponibilité, ressource (nous allons faire venir un architecte java dont j'avais posté une annonce ici >500€/j) et la taille du site. :?
Tu me rassure sur le faite que je peux utiliser quand même des procédures et, je suppose, qu'hibernate, peut s'appyer dessus pour faire appelle à des données ou écrire dans la base. Je pensais qu'hibernate n'avait pas la possibilité de faire cela et donc qu'il a pas d'autre possibilité que de faire les commande select, insert, delete.

Une chose importante, c'est d'activer les logs Hibernate pour voir les requêtes SQL générées et ensuite jouer avec la config, les mappings pour minimiser les requêtes.
Hibernate, s'il est bien utilisé, ne doit pas être un frein aux performances.

Si tu restes dans le monde purement objet, effectivement hibernate ne génère du SQL que pour faire des recherches et de la "synchronisation".

En revanche tu peux utiliser le HQL pour faire des requêtes relativement complexes et même mapper les résultats vers une (ou plusieurs) autre(s) entité(s).

Ensuite tu peux, comme pour le HQL, exécuter une requête SQL que tu pourras mapper vers une (ou plusieurs) entité(s).
Avec Hibernate tu as toujours accès aux objets JDBC.

Sinon je vois pas bien l'intérêt des procédures stockées si tu as implémentes toute ta logique métier dans ton code Java ?

Les procédures stockées sont souvent là pour des raisons de performance. Ensuite, ça veut dire que ta logique métier est éventuellement découpée (Java / BDD), et donc que tu dois avoir pour la maintenance une double compétence disponible.

De mon expérience d'Hibernate (ou autres ORM), j'ai tendance à penser qu'il est souvent mal utilisé ou trop.
Il faudrait (souvent) le restreindre au modèle métier des données, de ce point de vue, c'est un gros avantage.
Pour ce qui est des requêtes de recherche ou pour la constitution de liste de soutien, il est souvent plus performant d'utiliser une requête SQL taillée sur mesure et de créer des DTO pour l'utilisation dans l'application. On peut utiliser les indexes appropriés, utiliser les agrégats ou les fonctions SQL judicieusement etc...

je dois avoir de la chance, je n'ai jamais eu besoin de faire des procédures stockée, en général j'arrive au même résultat avec une seule requete SQL :p

Les avantages d'hibernate pour moi:
Pas de SQL dans le code (de outils plus léger comme ibatis le font aussi)
Un modèle purement objet pour la manipulation de données, ce qui est bien pratique
HQL qui permet des requetes objet, similaire à SQL
Un système de session garantissant unicité et cohérance des objets, accompagné d'un système transactionnel
Toujours la main (mais c'est déconseillé) pour faire du SQL pur et dur
Le cache de données
Les requêtes optimisées pour la plupart des cas buisness


Maintenant si chez vous, Hibernate "pompe" énormément (trop par rapport à la demande buisness émettrice) sur la DB, le problème est au niveau du code qui utilise ces données, pas d'hibernate dans 50% des cas. Dans 49.9% restant, c'est le mapping mal réalisé (oubli de mettre les collection en lazy et on pompe tout la DB d'un coup). Exemple, si on a une table de 10 colonnes "utilisateur" et que, pour avoir le nombre d'utilisateurs de l'application, on a mis comme un cochon dans le code session.createQuery("from Utilisateur").list().size(), forcément, on viens de transférer l'intégralité de la table sur le réseau. C'est exactement la meme chose que si en JDBC on avait fait "select * from table_user" puis qu'on avait parcouru les résultat pour compter :D.

Faites des tests, identifiez ce qui est lent ou consommateur, corrigez les requetes :). Dans le cas présent, meme résultat mais sans le problème de perfs, avec
session.createQuery("select count(*) from Utilisateur").uniqueResult() qui recois juste un long sur le réseau :)

Bonjour,
Merci pour votre intervention, en effet, de notre coté c'est un peut mal implémenté ce qui fait que nous devons gérer beaucoup d'erreur. Néanmoins, j'ai compris que hibernate s'intègre difficilement avec une base existante car elle a sa propre logique qui est différente de celle d'une logique base de données. En faite, tout dépend de la complexité de la base de données.

oui, c'est souvent une erreur de vouloir utiliser hibernate pour attaquer une base de donnée legacy dont on a pas le droit d'adapter le schema. Hibernate nécessite certaines structure (en tout cas est pensé avec elles en tête) qui ne s'accomodent pas toujours de l'existant ;)

Citation:

---

Envoyé par tchize_

oui, c'est souvent une erreur de vouloir utiliser hibernate pour attaquer une base de donnée legacy dont on a pas le droit d'adapter le schema. Hibernate nécessite certaines structure (en tout cas est pensé avec elles en tête) qui ne s'accomodent pas toujours de l'existant ;)

---

J'ai l'impression que tu travailles sur le même projet que moi :mouarf:

Plus sérieusement je pense qu'on utilise souvent Hibernate dans des projets parce que les "décideurs" ont entendu dire que c'était devenu la norme mais sans que tout le monde en comprenne les tenants et les aboutissants.
Je serai curieux de savoir qu'elle est la proportion de développeurs connaissant Hibernate et qui comprennent vraiment la notion de session et d'objets attachés ou détachés.

Je crois qu'un ORM reste quand même le moins mauvais des systèmes en attendant la disparition des SGBDR (un jour peut être, si tous les DBA se retrouvent à la retraite, donc pas pour demain :lol:)

Je ne suis pas fan d'hibernate pour les raisons évoqués dans les messages su dessus, je lui reconnais certains avantages néanmoins, évoqués aussi au dessus.

Un autre avantage, non mentionné ici, est de pouvoir structurer les entités selon ses besoins et ses scénarios de mise à jour. Je vais prendre un exemple simple, certaines entités mapperont les tables à plat (pas de champs liés pas de Set), des entités légèrement différentes chargeront les mêmes tables avec des Set en lazy par exemple ... dans la même idée ou peut avoir des mises à jour en cascade sur des entités et d'autres entités sur les même table non, ...

Cet aspect est pratique.

Bonjour,

On ne peux comprendre que quand on a subit.
Comme toute solution ou brique logiciel, il faut être prudent.

Un ORM, cela facilite la vie mais est souvent mal utiliser par manque de connaissance. Il faut tester avec des test unitaires ses objets métiers pour en avoir le coeur net ( SQL activé )

Après sur mes applications, pour les parties "dites sensibles" et pour des raisons, un bon PL/SQL y a pas photo, d'ailleurs j'oblige les SSII à le faire
car si je change de techno, la base reste. je m'a permis de de corriger
des problèmes de deadlocks sur Oracle.
En étant pervers, on peux faire du java en PL/SQL ;)

Les ORM, doivent être utilisé pour des standards, pour gagner du temps,
et avoir une standardisation dans le code, par contre, il m'arrive de pervertir le système car il y a des limitations quand on utilise des objets sgbd particuliers (BLOB spécifiques).
Il m'arrive ainsi d'utiliser une connexion directe JDBC avec un DAO ou DTO.

Rien n'est bon ou mauvais, l'expertise seule permet de choisir la bonne solution.
C'est souvent lié à la méconnaissance.

Rmq pertinente : Tchize à raison, tous les ORM, n'aime pas les bases existantes, par expérience c'est souvent lié à la maturité de l'ORM.
Olivier

Citation:

---

Envoyé par nathieb

Après sur mes applications, pour les parties "dites sensibles" et pour des raisons, un bon PL/SQL y a pas photo, d'ailleurs j'oblige les SSII à le faire
car si je change de techno, la base reste. je m'a permis de de corriger
des problèmes de deadlocks sur Oracle.

---

Bah si tu préfères dépendre pour ton "code critique" d'un langage à part, d'une plateforme propriétaire difficilement transposable contrairement à un énième langage objet ; sans compter la dépendance aux bugs Oracle.
Je dis juste que chacun a sa conception de la gestion des risques.

Citation:

---

Envoyé par nathieb

En étant pervers, on peux faire du java en PL/SQL ;)

---

A mon avis c'est à proscrire, vu comment sa fonctionne :

• Oracle crée un fichier source Java à partir du code de la procédure.
• Oracle compile la classe avec son JDK
• A l'appel, Oracle prépare la "zone d'échange".
• Oracle instancie une JVM
• Oracle exécute la classe dans la JVM en passant les informations via la "zone d'échange" qui côté Java se fait via un pseudo driver JDBC.

Je suis sûr que sur beaucoup de procédure c'est plus long que de le faire côté applicatif et d'échanger via le réseau.

Citation:

---

Envoyé par nathieb

Rien n'est bon ou mauvais, l'expertise seule permet de choisir la bonne solution.
C'est souvent lié à la méconnaissance.

---

Pourvu que le débat de la solution et les raisons du choix soient marqués noir sur blanc.
Sur les applications qui commencent à vivre on passe un temps fou à maintenir des librairies sans même savoir si c'est encore pertinent de faire tout ça ...

Citation:

---

Envoyé par nathieb

Rmq pertinente : Tchize à raison, tous les ORM, n'aime pas les bases existantes, par expérience c'est souvent lié à la maturité de l'ORM.

---

C'est le problème de toutes choses qui n'ont pas été faites pour. Hibernate a essentiellement transposé l'objet dans le monde relationnel. Mais l'inverse est beaucoup moins pertinent.

Après le problème vient-il du fait que c'est plus complexe ou moins utile dans ce sens là ?

Bonjour,

Bugs Oracle, pourquoi Java n'en a pas ?
C'est un peu démago .. non ?:mouarf:
Je suis désolé mais,

Citation:

---

Bah si tu préfères dépendre pour ton "code critique" d'un langage à part, d'une plateforme propriétaire difficilement transposable contrairement à un énième langage objet ; sans compter la dépendance aux bugs Oracle.
Je dis juste que chacun a sa conception de la gestion des risques.

---

Je ne suis pas partisan Oracle, cela aurait été du Postgres, même combat.
Pour ce qui est de la robustesse du code vu le nombre de versions des JDKS et des frameworks, je ne suis pas sûr que la pérénité des applications soient pour vous une priorité. Mais je me dois de me projeter à long terme.

La gestion des risques n'est pas un point de vue personnel, justement, par expérience tout miser sur une couche Java, pour des opérations critiques me semble illusiore.
En règle général, l'appel d'un simple insert avec un ORM c'est un appel à au moins trois couches ;), et bilan de l'histoire derrière c'est toujours du SQL ou PL/SQL.

J'utilise un GED sur base Intermedia Oracle, j'aurais tout fais coder en Java cela aurait été un crime d'utilise un ORM (trop de bugs Java) par contre la base supporte nativement le PL/SQL et les objets spécifiques, que fais-tu ?
C'est un exemple, on pourrait prendre de la carto aussi, mais c'est là où tu te dois faire de l'architecture, tu dois rester critique.

Il y a dans un Linux Mag, un auteur qui a poussé un cri "trop de couches" tuent les applis.
Avec l'expérience, je pense, et pour maintenir certaines applis, je crois qu'il faut faire la part des choses.

De toute façon, découper un .jar métier + packages java, c'est pas pire que faire appel à du PL/SQL. Et pour avoir fait des benchmarks, sur des vues reportings, je crois qu'il n'y a pas photo.

Par ailleurs, je n'aime ce genre de raccourci "il faut tout faire côté applicatif", c'est une hérésie. L'utilisation d'un dogme mène à une réflexion unidirectionnelle. 8O

Combien de deadlocks applicatifs, j'ai contourné par un PL/SQL gérant correctement la partie transactionnelle. Les plus grosses bourdes applicatives, sont faites par des personnes qui occultent, par méconnaissance, ou par fainéantise intellectuelle, la partie données en faisant aveuglément confiance à leur code Java ou PHP.
D'ailleurs la notion de transaction est souvent bafouée, voir ignorée.:ccool:

Je ne dis pas que Java + briques logicielles c'est mal, au contraire, mais un Hibernate mal utilisé c'est la "kata".

Parfois, il vaut mieux rester aux bases que de répondre au chants des sirènes ...

Enfin, j'accepte la critique, car c'est un point de vue.

Olivier

Citation:

---

Envoyé par nathieb

Bugs Oracle, pourquoi JAVA n'en a pas ?
C'est un peu démago .. non ?:mouarf:

---

Ce qui est démago c'est de transposer "énième langage objet" par "Java" ...
Ce n'est pas parce que je suis intervenant Java et que je fais du Java (les deux étant liés) que je rêve Java. Il doit bien y avoir 3-4 langage/plateforme/techno que je place au-dessus.

Les chefs de projets verraient-ils les développeurs comme des nerds addictes aux langages qu'ils utilisent ? Ca ne serait pas plutôt le commercial qui donne tout le temps la même bouffe à manger ?

Pour en revenir à Java et Oracle, c'est la même boîte maintenant ! Et j'ai jamais rencontré de problèmes bloquants en Java contrairement à Oracle où j'ai déjà une petite liste de bugs qui nous pourrissent l'existence. Chaque semaine on vient me voir sur pourquoi on fait comme-ci et comme-ça et pas simplement comme-cela. Ca devient tellement horrible qu'on en est venu à se demander s'il faudrait pas joindre cette liste et les contournements aux templates des fiches d'analyses !

Citation:

---

Envoyé par nathieb

Je suis désolé mais,
Je ne suis pas partisan Oracle, cela aurait été du postgres, même combat.
Pour ce qui est de la robustesse du code vu le nombre de versions des JDKS et
des frameworks, je ne suis pas sûr que la pérénité des applications soient pour vous une
priorité. Mais je me dois de me projeter à long terme.

---

Qui te dit que je change de version de Java et/ou de framework tous les matins ? D'ailleurs sur les applications sur lesquels je bosse on en change que très rarement (bugs, besoin d'une nouvelle fonctionnalité déjà présente dans une version plus récente mais pas la dernière).

Citation:

---

Envoyé par nathieb

La gestion des risques n'est pas un point de vue personnel, justement, par expérience
tout miser sur une couche "JAVA" , pour des opérations critiques me semble illusiore.
En règle général, l'appel d'un simple insert avec un ORM c'est un appel à au moins trois
couches ;), et bilan de l'histoire derrière c'est toujours du SQL ou PL/SQL.

---

je dois dire que la gestion des risques c'est assez nouveaux pour moi mais je vois les choses comme ceci :
je prends le plus de "section critique" sur les technos où il y a de la matière grise et celles qui sont transposables.
Et trouver une nouvelle plateforme basé sur le paradigme objet qui dispose d'une fonctionnalité ORM, de la matière grise me semble plus aisé que de trouver un autre SGBDR qui supporte correctement les procédures stockées et avec suffisamment de matière grise sur cette fonctionnalité.

Citation:

---

Envoyé par nathieb

J'utilise un GED sur base Intermedia Oracle, j'aurais tout fais coder en "JAVA"
cela aurait été un crime d'utilise un ORM ( trop de bugs JAVA ) par contre la base
supporte nativement le PL/SQL et les objets spécifiques, que fais tu ?
C'est un exemple, on pourrait prendre de la carto aussi, mais c'est là ou tu te dois de faire de l'architecture, tu dois rester critique.

---

Et qu'en aurait-il été en C++ ?
En revanche les temps de traitements côté base de données sont imbattables mais c'est pas vraiment ce à quoi je faisais allusion.

Citation:

---

Envoyé par nathieb

Il y a dans un Linux Mag, un auteur qui a poussé un cri "trop de couches" tuent les applis.
Avec l'expérience, je pense, et pour maintenir certaines applis, je crois qu'il faut faire la part des choses.

---

La limite est toujours dans le raisonnable. Il faut juste comparer le cout d'avoir une couche et celle de ne pas l'avoir.

Citation:

---

Envoyé par nathieb

de toute façon, découper un .jar métier + packages java, c'est pas pire que faire appel à du PL/SQL. et pour avoir fais des benchmarks, sur des vues reportings, je crois que y a pas photo.

---

En Java le découpage n'influe pas beaucoup sur la vitesse d'exécution au final.
Là tu fais entrer un critère supplémentaire celui de l'efficacité d'exécution face à la rentabilité par exemple. Si tu arrives à vendre la charge supplémentaire (que ce soit parce qu'il te faut une ressource spécifique, que ca prenne plus de temps en implémentation et en maintenance) c'est que ton client est prêt à payer plus et donc estime que c'est plus rentable ! Ou c'est ce que le commercial aura réussi à lui faire avaler.

Citation:

---

Envoyé par nathieb

Par ailleurs, je n'aime ce genre de raccourci "il faut tout faire côté applicatif", c'est une hérésie. L'utilisation d'un dogme mène à une réflexion unidirectionnelle. 8O

---

Mon raccourci c'est surtout éviter d'utiliser Oracle ... Le choix applicatif ou embarqué en base de données, ca dépend de contraintes supplémentaires.

Citation:

---

Envoyé par nathieb

Combien de deadlocks applicatifs, j'ai contourné par un PL/SQL gérant correctement la partie transactionnelle. Les plus grosses bourdes applicatives, sont faites par des personnes qui occultent, par méconnaissance, ou par fainéantise intellectuelle, la partie données en faisant aveuglément confiance à leur code JAVA ou PHP.
D'ailleurs la notion de transaction est souvent bafouée, voir ignorée.:ccool:

---

Finalement ce ne sont pas les bibliothèques qui sont buggés mais ton propre code ... J'avoue que la capacité des développeurs à insérer du code buggé fait partie de la gestion des risques. En général c'est le rôle de l'architecture logicielle/concepteur de mettre en place des "normes" (ie snippet) pour limiter ce risque.

Citation:

---

Envoyé par nathieb

Je ne dis pas que JAVA + briques logicielles s'est mal, au contraire, mais un hibernate mal utilisé c'est la "katRINa"

---

:mouarf:

Citation:

---

Envoyé par nathieb

Enfin, j'accepte la critique, car c'est un point de vue.

---

C'est bien un point de vue et non une critique. En tout cas je voulais pas que en paraisse ainsi ! Désolé si j'ai été maladroit.
Je constate qu'on fait surtout avec ce qu'on a plutôt que ce qui devrait être !

Bonjour,

C'est rigolo cette discussion, car je pilote des boîtes privées, elles sont donc mes clientes.
Effectivement, je me méfie du discours des commerciaux, mais c'est un autre sujet.

Je comprends ton désarroi, car je sens un légère frustration dans le ton employé ... je me trompe ?

Comme tu dis si bien, on fait avec ce qu'on peut (délais, calendrier, urgence, technos imposées, ...).
J'avoue Oracle = galère (PHP, Java) mais il y a du bon aussi.
J'étais pour le tout Framework, mais avec le temps je réalise que pour faire la même chose il faut parfois 1 mois de monter en compétence. D'où le dilemme...

Bilan : Hibernate ou pas ? à toi de voir 8O

Quand je sais plus, je fais un tableau
Positif/négatif, j'écris les choses, et je me questionne sur chaque point ...

Olivier

Citation:

---

Envoyé par Nemek

Oracle où j'ai déjà une petite liste de bugs qui nous pourrissent l'existence.

---

Toi aussi tu as la transposition

Code:

---

where champ = :valeur

---

deviens

Code:

---

where (champ = :valeur) or ( (champ is null) and (:valeur is null))

---

en haut de ta liste? :mrgreen:

Plus connu sous le terme: Oracle au prix où ça coute est incapable de faire la différence entre une chaine vide et un null!

Citation:

---

Envoyé par nathieb

C'est rigolo cette discussion, car je pilote des boîtes privées, elles sont donc mes clientes.
Effectivement, je me méfie du discours des commerciaux, mais c'est un autre sujet.

Je comprends ton désarroi, car je sens un légère frustration dans le ton employé ... je me trompe ?

---

Si tu parles de Java, non je suis pas frustré car c'est mon gagne-pain. A force de ne faire que du Java, je suis devenu "bon" (je dirais plutôt "connaisseur" mais hélàs la moyenne est en dessous de "connaisseur") et on me propose des activités diverses et un salaire honorable pour cela !

Si tu parles d'Oracle, par contre là, oui je suis frustré. Car je perds en performance, en maintenabilité, etc. C'est un cout pour tout le monde : mon employeur, mon client, mes collègues et moi-même. Quand on voit le prix des licences c'est limite abusé. Bon ca reste moins cher que de l'IBM mais c'est aussi beaucoup moins bien, donc c'est à calcul à faire !

Citation:

---

Envoyé par nathieb

Comme tu dis si bien , on fait avec ce qu'on peut ( delais, calendrier, urgence, technos imposées, ... ).
J'avoue Oracle = galère ( PHP, JAVA) mais il y a du bon aussi.
J'étais pour le tout Framework, mais avec le temps je réalise que pour faire la même chose
il faut parfois 1 mois de monter en compétence. D'ou le dilemne ...

---

C'est clair que si tes ressources ne sont pas calés dans un framework, il vaut mieux le mettre de côté. Car ce qui arrive généralement c'est que le framework est mal utilisé et devient vite une épine !

Citation:

---

Envoyé par nathieb

Bilan : Hibernate ou pas ? à toi de voir 8O

---

Souvent c'est m'est imposé. Ensuite ca reste bien pratique pour faire la conversion RowSet <-> objet. Et gérer la cascade.
Je reste sceptique sur le gain si je devais coder tout ça à la main. Sans compter la gestion du cache (surtout pour les objets en lecture seule).

Citation:

---

Envoyé par nathieb

Quand je sais plus, je fais un tableau
Positif/négatif, j'écris les choses, et je me questionne sur chaque point ...

---

Je vois qu'on a tous les mêmes méthodes de travail ^_^ En général les colonnes sont : id, label, priorité, criticité, compléxité, etc.

Citation:

---

Envoyé par tchize_

Toi aussi tu as la transposition

Code:

---

where champ = :valeur

---

deviens

Code:

---

where (champ = :valeur) or ( (champ is null) and (:valeur is null))

---

en haut de ta liste? :mrgreen:

Plus connu sous le terme: Oracle au prix où ça coute est incapable de faire la différence entre une chaine vide et un null!

---

C'est un "documented feature" cf. documentation officielle de la 8i. Qui dit également qu'il ne faut pas considérer une chaîne vide comme équivalante à la valeur NULL car cela va changer dans les versions futures. Aujourd'hui on en est à la 11g et aucune différence -_-' malgré les dix années d'écart ...

Citation:

---

Envoyé par Nemek

C'est un "documented feature" cf. documentation officielle de la 8i. Qui dit également qu'il ne faut pas considérer une chaîne vide comme équivalante à la valeur NULL car cela va changer dans les versions futures. Aujourd'hui on en est à la 11g et aucune différence -_-' malgré les dix années d'écart ...

---

C'est marrant j'ai des document de oracle qui disent le contraire: on ne corrigera jamais car c'est bien comme ça et de toutes façon ca briserais la retro compatibilité :roll:

Bonjour,

En fait, null ou pas null, c'est une subtilité des SGBD, null <> est vide au sens ''pas de valeur". C'est pénible mais c'est comme cela.
C'est historique avec la notion de CHAR, la colonne qui prend la tête.

Olivier

source

Citation:

---

However, this may not continue to be true in future releases, and Oracle recommends that you do not treat empty strings the same as NULLs

---

Citation:

---

Envoyé par tchize_

Toi aussi tu as la transposition

Code:

---

where champ = :valeur

---

deviens

Code:

---

where (champ = :valeur) or ( (champ is null) and (:valeur is null))

---

en haut de ta liste? :mrgreen:

Plus connu sous le terme: Oracle au prix où ça coute est incapable de faire la différence entre une chaine vide et un null!

---

Tu viens de me résoudre une anomalie sur mon projet :ccool: