Discussion :

[el_slapper]

Ou alors on utilise des bases de données avec à la fois un accès SQL, no-SQL et objet natifs.

[Mat.M]

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..

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" ...

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 ?

[fr1man]

@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é.

[_skip]

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.

[Pill_S]

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...

[Logan Mauzaize]

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.

ç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.

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

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.

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).