- Google utilise JPA comme système pour leur cloud computing. Je crois qu'ils s'en sortent en terme de scalabilité
- Quand je change quelque chose dans ma table, mon ide détecte la plupart des contraintes liées. Comme mon code est bien organisé, je n'ai pas de mal à trouver les requêtes qui nécessitent du travail.
Bref, pas moyen de revenir à SQL. Tu ne me convainc pas d'un quart de poil.
Je n'essaie nullement de convaincre : j'entends ça et là des préjugés sur le "développement à l'ancienne", j'y réponds.
Google utilise JPA, mais pas vraiment de bases de données pour le Cloud Computing ( pour l'instant DB et Cloud Computing ne sont pas encore compatibles).Citation:
Envoyé par nicorama
Pour son Cloud Google ( mais aussi Amazon & Co ) Utilise des algo tels que MapReduce et Bigtable.
Bigtable est l'équivalent des DB pour le Cloud. On trouve régulièrement des articles sur Bigtable pour penser que c'est une régression par rapport aux systèmes relationnel.
Pour en revenir au débat ORM or Not.
Sur des projets importants, la phase d'optimisation de l'ORM reste indispensable, en particulier tout les plans de fetch. Il n'est pas rare non plus de devoir optimiser en passant directement par Jdbc et du SQL natif.
Dans cette phase d'optimisation l'étroite collaboration des deux mondes ( expert SQL / Expert OO) reste un facteur clé.
Dans le cas d'une interface de recherche multi-critère...
Formater ses requêtes en pur SQL en ajoutant à la demande des AND dans une clause WHERE, des colonnes dans un ORDER et des JOIN de tous les côtés puis ensuite binder les paramètres à leur valeur finale alors que leur nombre dépend du contexte, c'est pénible.
Ca fait une sacré plomberie qui atteint facilement la bonne centaine de lignes de code et dans laquelle on a vite fait de se gourrer (tant malin qu'on soit).
Puis ensuite vient la conversion du resultSet en objet ou à nouveau on est bon pour faire du copier-coller et oublier de modifier le nom d'une colonne sur les 20-30 propriétés de l'objet qui doivent être affectés.
Les tests unitaires peuvent supprimer une partie des erreurs dus a la syntaxe, mais difficilement une faute style affectation d'une colonne à la mauvaise propriété.
Plus de tâches répétitives et ingrates à faire à la main, c'est parfois plus de code, plus de chance de se gourrer, plus de difficulté en cas d'évolution.
Mais que font vos procédures stockées? Sont elles plutôt orientées "métier" ou font elles surtout de la manipulation de données.Citation:
Envoyé par dingoth
Par exemple est-ce qu'une opération CRUD est une procédure stockée? Avez-vous des exemples de choses que vous faites en procédure stockée que souvent les développeurs tenderaient à faire coté client?
Il ne faut pas oublier non plus que les ORMs permettent de faire des requêtes. J'ai vu plus haut comment calculer un max (fonction d'aggrégat) en bouclant sur une liste d'objet. Si l'idée vient à un développeur utilisant Hibernate, je lui conseille de lire sérieusement la doc.
Hibernate permet d'écrire des requêtes (HQL), de choisir les stratégies de fetch (eager, lazy), de gérer les relations entre objets via les cascades, de paramétrer correctement les caches, et... d'utiliser des procédures stockées ou des requêtes personnalisées si nécessaire (du moins pour Hibernate) !
S'il est évident qu'il ne faut pas utiliser à tort et à travers les ORMs, ils restent de précieux outils pour le développement d'applications. N'oublions pas non plus qu'on développe quasiment toujours une couche DAO et donc un "ORM" perso (c'est discutable, mais je le vois ainsi) avec dbutils ou jdbc, et que ceci s'appelle réinventer la roue (carrée bien souvent).
En résumé, il ne faut pas être extrémiste, ni dans un sens, ni dans l'autre.
Je pense que Patriarch24 a bien résumé ma pensée.
Ne partez pas uniquement de votre expérience ou d'un article trouvé sur Internet pour tirer des conclusions sur la qualité d'un produit.
Pour ce qui est de l'indépendance de base de données, ce n'est pas un mythe.
Si l'on respecte certaines règles, on peut avec un minimum de modifications passer d'une base à une autre. Ca peut être pratique pour le développement et éviter l'achat de licences de BD ou pour une application utilisable chez différents clients étant sur des SGBD différent.
Comme l'a dit Patriarch24, ne soyez pas extrémiste, car vous perdez toute crédibilité. Ceci s'adresse en particulier à SQLPro.
Elles font tout ce qu'un DAO typique fait : les CRUD, les find spécifiques (cependant, à chaque find sa stored proc ; cela pourrait être amélioré, mais pour l'instant, on garde ça comme ça). Nous avons toujours le concept de DAO, mais il sert effectivement à accéder aux stored procedures. Les statistiques sont également gérées directement par les stored procedures, ainsi que tout ce qui est la gestion des vues (au sens Java, non SQL).Citation:
Envoyé par _skip
Par exemple, nous entrons également des valeurs business en input et le peuplement des tables est géré sur base de ces valeurs business et non directement avec un INSERT INTO ... (<fields>) VALUES (<values>), parce qu'il est nécessaire de faire tel insert si l'on reçoit business value input et tel autre insert pour tel autre input. En gros, les PK ne sortent que très rarement de la base de données, et les requêtes sont optimisées et profilées, ce qui est plus difficile à réaliser (mais certes pas impossible) dans un cadre purement Java.
Ah oui, si on utilise Java, on effectue souvent plusieurs INSERT l'un derrière l'autre. Ici, nous interdisons cela. Toutes les données sont transférées à une seule stored proc, et celle-ci s'occupe de faire les différents inserts.
Afin de donner un exemple plus concret, nous avons un processus qui doit mettre à jour des informations et calculer les nouvelles valeurs dans une base de données et transmettre cette information à un web-service externe. La mise à jour des informations, le calcul et le renvoi de la réponse de calcul est géré par la base de données dans une seule (grosse) stored procedure (qui fait appel à d'autres procédures en interne, évidemment). L'exemple le plus typique est l'application de la TVA en fonction du type de client (particulier ou entreprise), géré en interne dans la base de données.
On dirait que vous avez créé une abstraction du schéma de base de données à base de stored procedures.
En tout cas avec mon expérience (limitée) des stored procedures, ceci me paraît extrêmement difficile à réaliser. Avez-vous des outils spécifiques ou des stratégies de tests unitaires pour arriver à tenir ça en tas? Et c'est quel SGBD?
Par ailleurs est-ce qu'il est fréquent dans ces procédures stockées que vous soyez amené à générer dynamiquement du SQL en fonctions de paramètres (recherche ou statistiques multi-critères)?
Et pensez-vous que cette approche d'effectuer des calculs métier au niveau de la DB serait possible dans le cas d'une application très orientée GUI, le genre ou les calculations doivent être présentés à l'utilisateur au fur et à mesure de sa saisie, avant qu'il ne valide le tout pour l'insertion définitive dans la base?
Perso j'aurai peur de me retrouver à *dédoubler* certaines parties du code entre le client et la DB.
Et pas d'offenses hein, je cherche juste à comprendre cette approche. :ccool:
J'ai relancé la discussion dans un post ci avant avec la totalité de l'article en lien !
A +
Une partie de mon argumentation sur les ORM est inverse. En lisant l'article entier, vous y trouverez la mention suivante :Citation:
Envoyé par notia
Cependant, je crois fermement en l’avenir de l’ORM. Pas de ceux qui existent de nos jours. Mais de celui qui sera capable de tirer parti des possibilités des SGBDR. Je rêve d’un ORM capable de créer automatiquement les vues correspondant aux objets modélisés, les procédures stockées de synthèse pour la mise à jour globale des tables relatives au mapping de l’objet au modèle relationnel, et finalement d’implémenter les déclencheurs INSTEAD OF adéquats pour assurer la correspondance entre vues et procédures … Ce n’est certes pas pour bientôt, mais c’est sans aucun doute vers cet avenir meilleur qu’il faut tendre. En attendant, c’est encore à la main que les choses se passent
C'est pour cela que MS a intégré dans SQL Server des web services et SQL CLR (création d'objet .net vue sous forme de types SQL avec les méthodes associées, comme par exemple le SIG de 2008)Citation:
Envoyé par Jester
A +
Là aussi je suis internenu dans mon article complet publié sur le monde informatique en disant ceci :Citation:
Envoyé par dingoth
[...] il est navrant de constater que de nombreux architectes croient naïvement qu'un objet tiers transactionné constitue une transaction parfaite pour une base de données. Il n'en est évidemment rien, et une transaction manipulant des objets n'a rien à voir avec une transaction de données, nécessitant notamment de piloter le niveau d'isolation en fonction des anomalies transactionnelles pouvant potentiellement découler du traitement. Et surtout, en utilisant une transaction dans une procédure stockée et non dans du code client, on minimise la durée de la pose des verrous sur les objets, puisqu'aucun temps mort relatif au transit par le réseau ne sera comptabilisé, ce qui contribue naturellement à une plus grande fluidité de l'application et par conséquent une meilleure montée en charge.
[...]
Enfin, peu de gens savent qu’une transaction applicative(30) n’est pas l’équivalent d’une transaction de données. Mais c'est après tout très logique... Christian Soutou, professant à l'université de Toulouse le Mirail, me montrait un tutorial de Serge Tahé pour apprendre la persistance dans Java : près de 305 pages pour décrire le fonctionnement du système et les problèmes potentiels... Vous avez dit RAD ? Il est vrai qu'en SQL on ne dispose que de quelques instructions pour faire la même chose avec la rapidité et la performance en plus...
---
(30) Il y a d’ailleurs souvent confusion dans l’esprit des informaticiens sur la notion de transaction qui ne s’applique qu’aux données. Selon les travaux de Gray et Bernstein une transaction doit posséder quatre propriétés : Atomicité, Cohérence, Isolation et Durabilité (ACID) et font passer un ensemble de données d’un état de cohérence à un autre en interdisant pendant la phase transitoire que les données momentanément incohérentes, puissent être utilisées d’une quelconque manière que ce soit. Trop de développeurs confondent les transactions informatiques avec les workflow de process, comme par exemple l’attente de la certitude du paiement par carte bancaire pour l’expédition d’une marchandise dans le cadre d’un site web marchand…
A +
Allez quelques extraits de l'article pour vous répondre :Citation:
Envoyé par _skip
4 - Les concepts et techniques du développement base de données épais
Tous les concepts et toutes les techniques du développement base de données épais existent depuis une dizaine d'années. C'est le temps qu'il aura fallu pour s'en rendre compte et commencer enfin à voir apparaître des compétences sur le sujet.
L'essentiel reposant sur les données, voici les différentes composantes à mettre en oeuvre pour parvenir à ce résultat.
[...]
Dans tous les cas, le SGBD relationnel22 utilisé doit permettre :
ode créer des vues;
ode coder des procédures stockées, des déclencheurs et des fonctions SQL;
ola mise à jour des vues simples, directement, et celles plus complexes par le biais de triggers INSTEAD OF;
odes requêtes récursives, pas exemple à l'aide des Common Table Expression (CTE);
Il devrait en outre être capable :
ode factoriser le code SQL par le biais de la CTE;
ode mettre en oeuvre les schémas SQL.
Tout le reste n'est que culture et formation.
A +
Utilisant pas mal les ORM je ne trouve pas que SQLPro à tout tord, les ORM trouvent une grande utilité dans les applications d'entreprises (faible nombre d'utilisateurs) mais lorsqu'il s'agit d'application générant un fort trafic ça devient plus délicat
il existe cependant une solution alternative pour toujours utilisé un ORM sur un site à forte fréquentation http://www.terracotta.org/web/displa...Implementation
mais depuis quelques temps je me penche plus sur des implémentations du côté du concept des big table élaboré par google et repris par hbase http://hadoop.apache.org/hbase/ ou encore hypertable http://www.hypertable.org/
Ca ne veut rien dire.Citation:
Utilisant pas mal les ORM je ne trouve pas que SQLPro à tout tord, les ORM trouvent une grande utilité dans les applications d'entreprises (faible nombre d'utilisateurs) mais lorsqu'il s'agit d'application générant un fort trafic ça devient plus délicat
Tout dépend de ton architecture matérielle, logicielle, la manière dont tu utilises ton ORM etc...
Vous faites des généralités à partir de rien.
C'est du beau, ça :mrgreen:Citation:
Envoyé par fr1man
tu veux des benchmarks c'est ca ? :mrgreen: désolé j ai pas le droit de les publier ...Citation:
Envoyé par fr1man
mais http://www.terracotta.org remplis largement la plupart des cas ...
Terracota est une solution intéressante pour répartir à peu de frais une application, avec la mise en partage des couches basses (notamment de l'orm et du modèle métier) et ceci selon différentes stratégies. Le gain de perf nait alors du passage en architecture distribuée.Citation:
Envoyé par *alexandre*
Mais ca ne répond pas à la question,pour un modèle architectural donnée (et selon un usage admissible), un orm plombe-t-il les perfs ? Et si oui, dans quelle proportion ?
Déjà le sujet du débat est erroné. L'auteur compare le code exécuté côté serveur d'application à du code exécuté directement dans la base à partir de procédures stockées. Donc ce qu'il critique peut aussi être reproché à du JDBC classique.
Ensuite, l'auteur veut opposer un ORM à une base de données, mais il oublie que les deux sont complémentaires. Comme cela a été dit, un ORM est configurable.
Il peut exécuter du code SQL pur, faire appel à des vues, des procédures stockées, etc...
On peut très bien utiliser les avantages de chaque solution plutôt que d'essayer de faire croire à tout le monde, que c'est soit blanc, soit noir.
Je lisais un de ces jours derniers, un article sur l'architecture du site eBay.
De ce que j'ai retenu, ils n'utilisent pas de transaction (chaque instruction SQL est suivie d'un commit).
Je vois déjà certains gourous s'arracher les cheveux, pourtant cette solution leur permet d'atteindre leurs objectifs de performances.
Pour moi ce débat est du même niveau que "Java c'est lent" ou encore "C++ est plus rapide par que j'ai fait un bench qui le prouve (ou le contraire)".
Entièrement d'accord, perso je suis parti de l'idée que ce qu'il pouvait raisonnablement reprocher à un ORM c'est la *magie* (lazy loading, lecture update) qui peut induire le développeur à profiter de facilités qui se paient en performance. Mais encore une fois c'est seulement les cas ou l'utilisation est inadéquate.Citation:
Envoyé par fr1man
J'ai cité quelques cas ici :
http://www.developpez.net/forums/d76...s/#post4429778
Je pense que c'est exactement ce qui doit conclure ce point du *débat*.Citation:
Envoyé par fr1man
En revanche, la discussion sur l'utilisation des bases de données épaisses reste ouverte.
Voir ici
http://www.developpez.net/forums/d76...baisser-couts/