Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Débats sur le développement - Le Best Of Discussion :

Les frameworks de persistance (ORM) sont-ils dangereux pour les performances ?


Sujet :

Débats sur le développement - Le Best Of

  1. #201
    Expert éminent sénior
    Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
    1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
    2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
    3)le temps de comprendre toutes les exigences, le projet est terminé
    4)le temps de terminer le projet, les exigences ont changé
    Et le serment de non-allégiance :
    Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.

  2. #202
    Expert éminent sénior
    Citation Envoyé par fsanti Voir le message
    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...
    +1000
    je partage totalement cet avis...
    pour ce qui est de pondre des applications en temps record là c'est parce que les entreprises n'ont pas le budget et le temps matériel pour faire quelque chose de correct et structuré c'est l'éternel problème.
    Ensuite pour ce qui est d'utiliser des caches-misères plutôt que d'optimiser que va-t-il se passer quand une majorité de webserver vont être saturés ?
    Surtout que des traitements non optimisés ça pompe pas mal niveau ressources matérielles,consommation électrique etc..

    Citation Envoyé par fsanti Voir le message

    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...
    euhh c'est le but du Big Data dont on nous rabâche sans arrêts les mérites...mais si on balance des données non structurées là encore une fois on a affaire à de belles usines à gaz bref rien de nouveau en somme


    curieux que Mr el_slapper ne nous rappelle pas la problèmatique de la "dette technique" ...

    Citation Envoyé par fsanti Voir le message

    C'est tellement pratique de ne pas avoir à réfléchir à Modèle Relationnel de Données
    bien d'accord et qui de nos jours fait l'ébauche d'un MCD ? Ne serait-ce que sous Access qui utilise les liaisons entre tables ?
    La théorie, c'est quand on sait tout et que rien ne fonctionne.
    La pratique, c'est quand tout fonctionne et que personne ne sait pourquoi.
    ( A Einstein)

  3. #203
    Expert confirmé
    @fsanti
    Vous mélangez un peu tout.
    Personne ne vous interdit de faire de l'analyse et de pondre un beau modèle de données et d'ensuite utiliser un ORM.
    Personne ne vous interdit non plus d'utiliser des procédures stockées dans le cas où l'avantage serait conséquent.
    Personne ne vous interdit de travailler de concert avec les DBA pour optimiser votre modèle de données et vos requêtes si besoin.
    De plus, au niveau des coûts, certains préféreront ajout de la RAM ou un serveur, plutôt que de payer des journées de développements.
    Aucun raisonnement n'est stupide s'il est argumenté.

  4. #204
    Expert éminent
    Merci fr1man d'apporter un peu de nuance là dedans car franchement ça fout la trouille ce qu'on lit comme généralisation.

    Il y a des cas d'utilisation parfaitement valides pour tout type de solution. Devoir gonfler un serveur pour supporter la charge ça peut être un choix plus avisé que de passer des jours à optimiser un système sans garantie de résultat et en prenant le risque de casser. Oui c'est moche, mais c'est la vie . Les applications légères et élégantes à leur début mais auxquelles on a fait avaler n'importe quoi par la suite, où les compétences se sont éparpillées et perdues en route, ça devrait pas exister mais ça existe.

    Un ORM est un outil, un moyen, s'il expédie n'importe quoi comme requête à la DB, c'est que la personne qui s'en servait ne savait pas ce qu'elle faisait. Marrant d'attribuer systématiquement l'outil la responsabilité d'un boulot mal fait. Mais bon on voit ça tout le temps.

    Pour le noSQL, faut voir le contexte, si c'est pour faire des modélisations qui demanderaient à un SGBDR traditionnel un modèle en EAV comme certaines solutions eCommerce. Ca peut tout à fait faire du sens.

  5. #205
    Membre expert
    Citation Envoyé par _skip Voir le message
    Merci fr1man d'apporter un peu de nuance là dedans car franchement ça fout la trouille ce qu'on lit comme généralisation.
    Tout à fait d'accord. Vous êtes quand même tous en train de vous plaindre que votre marteau "automatique" tape moins vite que votre marteau manuel. Personne ne se dit à un moment que le marteau automatique était peut-être plus complexe, et donc nécessitait un poil plus de réflexion avant d'être efficace?

    Avec des raisonnements pareils, on se remettrait tous à l'assembleur sous prétexte que c'est plus perfo...
    "Le plug gros problème des citations trouvées sur internet, c'est qu'on ne peut jamais garantir leur authenticité"

    Confucius, 448 av. J-C

  6. #206
    Rédacteur/Modérateur

    Citation Envoyé par fsanti Voir le message
    je n'ai jamais compris l'intérêt de ces ORMs...
    je pense que cela a déjà été décrit précédemment. Mais des solutions à base d'ORM peuvent être bien plus efficaces aussi bien en termes de temps de développement qu'en temps d'exécution. Les frameworks d'ORM sont des solutions éprouvées qui savent générer du code optimisé pour la plupart des SGBD. Sans compter également sur une bonne gestion du cache. Et avec surement moins de bugs que ce que tu pourrais produire toi-même.

    Car soyons francs de l'ORM tu en auras obligatoirement besoin. Sauf si tu considères toutes tes données sous forme d'enregistrement linéaire, même en cas de jointure N-N !

    Les solutions type jOOQ ou QueryDSL offrent aujourd'hui de bon compromis si tu veux rester proche de ton modèle relationnel.

    Citation Envoyé par fsanti Voir le message
    ç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...
    Ce n'est pas très lean ou même très agile, pourtant certains pensent que c'est sans ces dernières que les projets sont voués à l'échec Chaque approche/méthode a ses qualités et ses défauts, et c'est l'adéquation entre le projet et les personnes qui les utilisent qui fait qu'un projet peut fonctionner ou pas.

    Nombreuses sont les personnes ici qui seront t'expliquer qu'il n'y a pas de recettes miracles.

    Citation Envoyé par fsanti Voir le message
    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 !!!
    Assez marrant car c'est l'un des principaux de problèmes des vieilles applications pensées en MERISE

    Citation Envoyé par fsanti Voir le message
    Pourquoi normaliser un modèle de données, il faut réfléchir et ça prend du temps
    Un modèle normalisé est quasiment l'opposé d'un modèle optimisé ! La normalisation vise à optimiser la redondance mais l'éviction de celle-ci tend à minimiser les performances. Bien comprendre ses outils (ORM ou design) c'est essentiel pour faire une bonne application. Ce n'est pas l'outil en lui-même qui est mauvais.

    Citation Envoyé par fsanti Voir le message
    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 !!!
    Tout comme tu pourrais mettre à genoux un SGBD avec bien moins de données si l'approche relationnelle n'est pas adaptée. D'ailleurs tu pourras pas manipuler des To de données sur une seule machine, sauf si tes transactions concernent toujours un même petit lot de données (données chaudes/froides).

    Pas plus que ton modèle relationnelle et pré-construit ne peut stocker toutes les données aux entrées de ton SI et qu'énormément de valeurs peuvent être créées à termes en transformant ces données froides. Que ce soit par analyse manuelle ou automatique (ex : machine learning).
    Java : Cours et tutoriels - FAQ - Java SE 8 API - Programmation concurrente
    Ceylon : Installation - Concepts de base - Typage - Appels et arguments

    ECM = Exemple(reproduit le problème) Complet (code compilable) Minimal (ne postez pas votre application !)
    Une solution vous convient ? N'oubliez pas le tag
    Signature par pitipoisson

###raw>template_hook.ano_emploi###