moi je dirais qu'une DB est faite pour plusieurs clients,Citation:
Envoyé par B.AF
donc je me poserais la question en premier lieu, et j'essaierais de normaliser l'acces aux données par des stored procedures.
moi je dirais qu'une DB est faite pour plusieurs clients,Citation:
Envoyé par B.AF
donc je me poserais la question en premier lieu, et j'essaierais de normaliser l'acces aux données par des stored procedures.
@B.AF
Je suis bien conscient de tout ça, ce n'est pas pour autant que ce n'est pas utilisable.
Et puis si c'est un problème pour l'architecture visée et bien tu ne te sers pas de ce cache de niveau 2 et tu te contentes de celui de niveau 1.
Excuses moi mais c'est un peu vert comme architecture. Tu ne peux pas utiliser un outil par la contrainte. Même le cache de niveau supporte les risques d'intégrité, les problèmes de versioning.Citation:
Envoyé par fr1man
On ne peut pas concevoir un dal qui passe son temps à se préoccuper de ce que les autres dal accédant aux mêmes données risquent de faire ou de ne pas faire.
L'ORM n'est pas la silver bullet.
epsilon68 je te déconseille fortement de laisser à ton SGBDR le loisir de gérer lui même l'accès concurrentiel, à moins que tu ne souhaite avoir du côté de tes n instances clientes, des bugs pour le moins incongrus et pas toujours très facile à repérer, et ce même avec des transactions en niveau d'isolation maximum (sérialisation)
l'isolation maximum, risque de créer des cas de famines, et un niveau moindre des incohérences de données, et je ne te parle même pas d'accès désordonnés à des ressources pouvant conduire à des étreintes mortelles.
certes les SGBDR détecte cela très bien... ce n'est parce qu'ils le détectent et que selon le SGBDR ils font des choix pour le moins arbitraire, que c'est bien pour autant de laisser ce genre de cas se produire... et l'accès concurrentiel à une base de données, mène tôt ou tard à ce genre de dérive, car tu n'est pas obligatoirement maître de tous les accès.
Si demain on doit accéder à ta base pour synchroniser les données avec un autre milieu, les risques de dead-locks et famines vont se multiplier encore plus... d'où la réponse cohérente de B.AF... il est préférable d'envisager une architecture de services.
Après tout est question de grandeur... si ta 2 instances du même client, qui généralement ne travail même pas sur la même zone du domaine des données, alors oui... passer par des services, c'est un peu comme chasser le moustique au canon... mais sur des projets de plus grosses amplitude...
B.AF toi qui a l'air de connaître... Entity Framework a pour chaque entité une option que l'on peut activer, qui est "accès concurrentiel"... à priori elle a pour effet, de désactiver un cache, mais est-ce comme dans Hibernate juste la désactivation d'un cache de niveau 2, ou EF ne possède pas 2 niveaux de caches ?
Personne n'a dit que l'ORM était la silver bullet.
Le cache de niveau 1 étant censé avoir une durée de vie courte, contrairement à celui de niveau 2, le risque d'avoir des données périmées est bien plus faible.
Les problèmes d'intégrité et de versionning ne sont pas liés qu'aux ORM.
Le problème n'est pas à la portée de l'ORM en fait ou d'une de ses fonctionnalités.
Quant 5 socles, ORM ou pas, accèdent de façons concurrente et cloisonnée à la même base, si les transactions et l'intégrité ne sont pas posé au niveau de la db, le risque de dysfonctionnement est inévitable et garanti.
Quand bien même je fais du short session dans une application, si pendant mon traitement une application lambda force la maj des données, j'aurai une stale state exception et ce sera normal.
J'aurai plutôt tendance à dire qu'il faut plutôt dans ce cas raisonner sur des techno comme ADO.NET Data Services si on veut vraiment utiliser un ORM.
En fait, l'important est peut-être de savoir, avant d'écrire l'application si ce qui est important, c'est l'application ou la base de donnée.
Je m'explique, dans le cadre le plus courant, ce qui est important, c'est l'application. Ici l'ORM va permettre (s'il est bien écris) d'avoir une indépendance entre l'application et la base de données, et d'utiliser le même code quelque soit la base de données choisie, au finale, pour l'application. Vois même, en fonction de l'évolution, de changer de base de données, sans pour autant avoir à retoucher le code. Au prix d'une petite perte de performance.
Il arrive que les performances et la base de donnée soit plus importante que le développement, la couche ORM à alors moins d'intérêt, et pourrait, peut-être, être abandonné... Dans un cas pareil, l'utilisation intensive de procédures stockées pour la gestion et la récupération des données est assurément un plus important.
Dans le cadre d'un accès à la base de données par deux (ou plus) applications différentes, il est évident qu'il faut considérer la deuxième option. Voir une troisième qui serait une couche intermédiaire d'accès et de vérification, mais les bases de données actuelles couvre, en générale, ces besoins.
C'est bien dommage car les SGBDR font ça très bien et de manière redoutablement efficace ...Citation:
Envoyé par cinemania
Les problèmes de gestion de la concurrence sont connus depuis longtemps et ont donné lieu à beaucoup de travaux théoriques dès les les années 70 avec des implémentations réussies même dans des SGBD "pré-relationnels".
Je ne vois pas en quoi une architecture de service (c'est quoi d'ailleurs ?) peut apporter de neuf ou de magique sur ce sujet.
Je parle bien sûr d'un SI un peu significatif, et pas d'une malheureuse application intranet avec 2 utilisateurs et qui a été développée par le stagiaire d'été qui passait par là ...
SOA(architecture orienté service). Vous ne connaissez pas rpc et les web service ?Citation:
Envoyé par Luc Orient
Il n'y a rien de magique non plus dans un SBGDR ou une procédure stockée.
Mettre un composant informatique entre le client et un système de base de données est également un pattern d'architecture qui s'applique bien à SOA.
Justement les SI sont souvent composés d'une somme d'applications hétérogénes du fait de la taille, de la technologie, de l'utilité.Citation:
Envoyé par Luc Orient
Ce qui fait que fut une période ou l'informatique d'entreprise était à plus de 70% concernée par les problèmatiques d'intégration (qui n'a pas entendu le néologisme "transcodage").
Une architecture de service serait une logique de bus où le SI est un composé de fonction métier. C'est à dire que le service encapsule les questions d'intégration et de technologie.
Chaque service étant par définition interopérable avec les autres, cela facilite la création de processus verticaux par l'utilisation de points uniques.
C'est très proche du principe du design pattern facade et c'est plutôt une bonne chose.
C'est en tous cas un raisonnement plus fiable que d'avoir des cron qui font des ftp et qui lancent des korn shell qui eux même déclenchent du C++ qui appellent une sp de la base de donnée x.
Ca ne réinvente pas la roue, c'est juste un raisonnement plus industriel et moins bidouille et surtout beaucoup plus maintenable.
Ou vers MyBatis + un cache quelconque style memcached.Citation:
Envoyé par dingoth
Au final, d'après quelques expériences lues ici:
- Hibernate à un coût non négligeable en perfs (ce que je corrobore avec des mesures extensives pour des opérations CRUD). MyBatis, a contrario, a un coût minimal / JDBC.
- la génération auto de requêtes peut créer des requêtes lentes qu'il faut optimiser ensuite à la main, ce qui fait que l'avantage initial en terme de dev (on a vite un prototype qui fonctionne) est perdu par la suite en optimisation. Par contre, l'optimisation de requêtes nécessite des outils et/ou des connaissances que le développeur Java moyen n'ont pas. Un ORM comme Hibernate permet d'obtenir des requêtes correctement formées dans la plupart des cas.
- il n'y a pas besoin de connaître SQL. Cet argument est un voeu pieux. Il n'est simplement pas possible de développer un soft basé sur un SGBD SQL sans connaitre un minimum de SQL, ne serait-ce que pour débugger. On a tjrs besoin de faire des requêtes à la main, requêtes qui sont d'ailleurs à peu près les mêmes que celles du programme.
- l'ORM permet de s'affranchir des particularités du SGBD. SQLPro dit que c'est inexact. Je n'ai pas suffisamment d'expérience pour avoir mon avis la-dessus, mais ce qui me parait certains, c'est que les entreprises qui basent leurs gros devs sur une solution Oracle ne risquent pas de changer de SGBD de sitôt. Pour une banque ou une administration, par exemple, cet argument me parait donc relativement mineur. Mais pour d'autres applications, il est plus pertinent.
Après, pour ce qui est du développement, vu qu'on utilise majoritairement des langages objet en entreprise (Java, C#), vouloir garder un modèle objet est loin d'être déconnant, bien que le mapping soit fastidieux à la main, mais relativement automatisable (ce que font Hibernate, MyBatis et d'autres).
Le vrai avantage d'un ORM apparait, comme il a été rappelé, quand on part d'une base vierge et qu'on fait du MDA. On crée son modèle objet, et le schéma de base est créé en fonction. La modification du modèle, qui peut être importante dans les premières itérations du projet et/ou que les spécifications fonctionnelles ne sont pas fixées, est alors quasi instantanée, et on ne se retrouve pas avec des bugs de mapping en permanence. Mais quand il s'agit de mapper un schéma déjà existant, un outil comme Hibernate est probablement une perte de temps plus qu'autre chose (Mybatis est plus adapté).
Il se trouve que les langages fonctionnels sont probablement plus adaptés à la manipulation du SQL que le Java. Peut-être qu'avec l'adoption de paradigmes fonctionnels, les ORM disparaitront.
Le syndrome du "si ça passe à la télé, c'est forcément un bon produit"Citation:
Envoyé par Patriarch24
le syndrome de la confiance des experts ...
EDIT : ou celui de déterrage de topic.
Toujours les mêmes désespérantes idioties...
Un SGBDR ne choisit pas de lui même le niveau d'isolation. Il est par défaut à un niveau que le développeur doit monter en fonction de ses besoins et des traitements à faire... Problème : rare sont les développeurs qui savent réellement ce qu'est l’isolation et peu savent la modifier. Pire, un certain nombre d'ersatz de SGBDR comme MySQmerde ne permettent pas grand chose en cette matière, voir rien ! (pas de transactions dans MyISAM).Citation:
Envoyé par cinemania
Quand à piloter l’isolation au niveau du code c'est mathématiquement impossible. je m'amuse à le démontrer quotidiennement la chose dans toutes les formations que je donne !
A +
Ca c'est aussi parfaitement stupide :
Expliquez moi un peu ce que vous pouvez faire avec votre programme mais sans les données ?Citation:
Envoyé par Michel Rotta
Maintenant pouvez vous faire quelques chose avec les données sans votre programme ?
la question est donc stupide. L'important dans le SI c'est TOUJOURS les données !
malheureusement peu de gens en ont conscience hélas...
A +
Oulala, beaucoup de bêtise et en plus on me prête des propos que je n'ai jamais dit !
Pour en avoir vu de multiples fois en audit, les requêtes pissées par Hibernate sont en général le summum du crétinisme... Exemple 185 requête avec WHERE toto = 245 puis WHERE toto = 851 etc, au lieu de WHERE toto IN (245, 851...) générant des round-trip en pagaille pendant une transaction... les verrous étant maintenant pendant tout ce process on constatait 99% du temps consacré au réseau pour 1% de réel traitement de la part du SGBDR !!! Bravo hibernateCitation:
Envoyé par el muchacho
Parlons de la méthode de pagination d'Hibernate qui consiste pour chaque page à afficher de reparcourir toutes les données : Superbe !!!
Parlons aussi des jointures spaghetti qu'Hibernate génère à outrance....
Pour ma part en 15 ans d'audit, j'ai vu deux entreprises faire faillite à cause des mefaits d'Hibernate...
je n'ai pas dit que c'était inexact.. j'ai dit que c'était utopique et d'ailleurs une même requête dans Hibernate provoque des résultats différents dans les différentes SGBDR, ne serait-ce qu'à cause de la gestion des collations...Citation:
- l'ORM permet de s'affranchir des particularités du SGBD. SQLPro dit que c'est inexact.
Mais c'est justement là, que les entreprises font faillite. tant que les données sont peanuts, alors le système crache... Dès que le volume arrive les performances chutent dramatiquement et l'un (le dev) accuse l'autre (la prod) de pas avoir pris le bon serveur... (bataille du muscle contre l'intelligence comme dirait rudi...). Le problème est que c'est inégal. Un bon schéma (cela n'arrive jamais avec hibernate) avec de bon index (Hibernate n'en pose jamais) c'est un facteur 100 à 10000 au niveau des performances. Rien à voir avec le doublement des cœurs ou de la RAM !Citation:
Le vrai avantage d'un ORM apparait, comme il a été rappelé, quand on part d'une base vierge et qu'on fait du MDA. On crée son modèle objet, et le schéma de base est créé en fonction. La modification du modèle, qui peut être importante dans les premières itérations du projet et/ou que les spécifications fonctionnelles ne sont pas fixées, est alors quasi instantanée, et on ne se retrouve pas avec des bugs de mapping en permanence.
A +
@SQLpro
Je peux aussi vous dire qu'en 11 ans d'expérience avec Hibernate, sur des petits projets comme des gros, je n'ai pas rencontré de problèmes liés à son utilisation.
Les problèmes étaient plutôt dus à une méconnaissance du framework ou plus généralement, de la base de données utilisée, et ils ont été résolus sans entraîner de dépôt de bilan...
Vous êtes tellement orientés contre les ORM que vous perdez toute objectivité....dommage...
Citation:
Envoyé par SQLpro
- DB2 est plus performant en requête séparée qu'avec un IN
- Hibernate ne fait que ce qu'on lui demande. Si tu écris une boucle infinie, il faut pas incriminer le langage ou le compilateur ...
- Certaines routines ETL ne consomment qu' 1% de traitement SGBDR et 99% de trafic réseau ;)
Je connais pas tous les SGBD mais au moins pour MySQL, Oracle et Postgres, il utilise les mécanismes de pagination proposé par leurs moteurs.Citation:
Envoyé par SQLpro
Après il est reconnu que la pagination par position n'est pas la plus optimale : http://blog.jooq.org/2013/10/26/fast...e-seek-method/
Les jointures sont celles demandées, là-dessus Hibernate ne fait qu'une seule supposition : par défaut il jointe par clé (ce qui est logique ...)Citation:
Envoyé par SQLpro
En bien moins d'expérience, j'ai rarement vu un ingénieur qui maitrisait un minimum correctement Hibernate. C'est généralement un outil imposé qui semble magique et donc personne ne veut investir dessus, bien à tord !Citation:
Envoyé par SQLpro
+1:ccool:Citation:
Envoyé par SQLpro
En général le problème c'est le développeur. Celui-ci considère que tant que ca compile et éventuellement que ca s'exécute, il a fait son job. Or c'est faux. Tant que la communication inter/intra système ne correspond pas aux exigences du système (temps de réponse, conso CPU/RAM, volume réel, concurrence, etc.), le boulot n'est pas terminé et il y a un bug. Ce problème n'est pas spécifique à l'utilisation d'Hibernate.Citation:
Envoyé par SQLpro
S'il le développeur ne veut pas comprendre ou qu'il n'y a personne pour lui faire comprendre, le problème n'est pas Hibernate mais ailleurs.
Le but d'Hibernate (ou de tout ORM) étant au final de stocker des objets dans une base relationnelle, le schéma idéal est donc celui qui permet de contenir des objets. Il y a quelques règles mais aucune qui ne pose de difficulté à un SGBDR.Citation:
Envoyé par SQLpro
Seulement, au final (de mon expérience), Hibernate est souvent utilisé sur une base dite legacy. Ce qui donne naissance à un certain nombre de contorsion.
La pose des index c'est souvent du ressort du DBA ou du développeur (dans une certaine limite). Les indexes sont des objets qui peuvent grandement améliorer les performances mais il ne faut pas oublier qu'ils peuvent être ignorés et plomber les perfs (si le coût de leur maintien est trop important).Citation:
Envoyé par SQLpro
De plus, avoir de bons indexes demandent une bonne connaissance du SGBDR retenu et de l'utilisation des données par l'application. Donc rien qu'Hibernate puisse évaluer.
Après plusieurs années au travail à utiliser l'architecture logicielle "classique" (Spring, Hibernate, JPA etc.), j'ai testé cette approche à la maison sur un projet personnel assez conséquent...
Elle a un inconvénient: il faut bien connaitre SQL (pas un souci dans mon cas). Pour le reste, c'est tout simplement "une tuerie" :ccool:, le plus bluffant étant l'amélioration des performances!
Je vais tenter dans mon entreprise d'en vanter les mérites sur un projet test, et propager la bonne parole. Je sais que les résistances vont être forte, la faute aux habitudes bien ancrées et à la méconnaissance du SQL et des SGBD en général. :(
Merci de m'avoir fait (re)découvrir cette approche, frappée du sceau du bon sens ! :)
Bonjour à tous,
Je suis tombé par hasard sur ce commentaire tellement vrai, je n'ai jamais compris l'intérêt de ces ORMs...ça doit satisfaire une catégorie de "développeur" qui ne pensent qu'a pondre dans un temps record des "applications" pour s'attirer les grâces d'un management qui ne comprend toujours pas que le développement est un vrai métier et que sans une approche "bottom-top" le projet est voué à l'échec...ha non j'oubliais, il suffit de mettre en place des "caches misères" et des WebServer avec 16CPU et 100Giga de RAM pour résoudre les problèmes de montée en charge...
On pourrait se dire que le pire est passé, car beaucoup sont revenus sur l'utilisation de se genre de Framework et ont finalement compris qu'il fallait un vrai travail d'analyse au niveau du modèle et de l'accès aux données à travers des Stored Procedure, mais non les bases No-SQL sont maintenant là !!!! C'est tellement pratique de ne pas avoir à réfléchir à Modèle Relationnel de Données et de stoker "as-it-is" ce que l'on a à l'écran et là aussi en cas de problèmes de performance on rajoute juste des Nodes et l'affaire est dans le sac !!!
Tout cela fait le bonheur des fabriquant de matériel et de hosting !!! Pourquoi normaliser un modèle de données, il faut réfléchir et ça prend du temps !!! En plus il faut écrire des SP et pondre des object POCO/DTO alors qu'une boiboite fait tout ça en coup de cuillère à pot !!! Quel temps perdu...
Bref, j'attends le moment où l'on aura tellement de data non structurées que même les plus grosses infra ne pourront plus les traiter...
Cela fait des années que je travaille sur l'optimisation de DB de plusieurs tera et comme par magie des requêtes qui prenaient plusieurs dizaines de minutes ce sont soudainement exécutées en quelques secondes !!!
Les vrai SGBDR ont encore de beaux jours et les DBA sont encore au chaud pour quelques temps !!!
Florian