Ou alors on utilise des bases de données avec à la fois un accès SQL, no-SQL et objet natifs.
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
Discussion :
Ou alors on utilise des bases de données avec à la fois un accès SQL, no-SQL et objet natifs.
+1000Envoyé par fsanti
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..
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" ...
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 ?
@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é.
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.
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...
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.
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'échecChaque 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.
Assez marrant car c'est l'un des principaux de problèmes des vieilles applications pensées en MERISE
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.
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).
Répondre avec citation
Partager