Discussion :

[MaitrePylos]

Tout n'est pas tout blanc ou tout noir.
SQL est mon quotidien, pourtant, je travaille également avec les outils fournis par nos choix de développement.
Je pense que pour le CRUD , le Dbal de Doctrine ou Eloquent de Laravel, sont des outils puissant et intéressant.
Une fois que l'on rentre dans le DQL, la question se pose, jusqu'où allons nous ? Souvent pas loin.
Des fonctions Eloquent comme updateInsert() est bien plus facile pour un dev qui travaille avec MySQL/MariaDB, puisque la commande Merge ou Upsert n'est pas implémenté dans tous les moteurs SQL.
Il m'arrive très souvent, de créer des fonctions dans la DB, pour faciliter le travail des mises à jour et update (c'est mon job).
Perso, j'essaie de relier les deux mondes et non pas un seul, car quand un ORM plante, il faut savoir pourquoi et le palier, exemple jamais réglé par le créateur d'un ORM :

Lors d'un delete sur PostgreSQL, il me mettait un LIMIT (sur lequel je n'avais pas la main), ce qui n'a aucun sens dans aucune DB d'ailleurs (je me trompe peut-être à ce sujet);

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
 
 
if ($this->_limit !== NULL && substr($db->_db_type, 0, 6) !== 'sqlite')
		{
			// Add limiting
			$query .= ' LIMIT '.$this->_limit;
		}
 
		return $query;

Malgré que le bug à été signalé, il n'a jamais été résolu, il fallait donc étendre cette classe.
Connaître les deux est un bien

[Sodium]

Oui, dans votre tête d'admin db il ne faut pas générer de requêtes SQL... mais moi je te parle de la vraie vie, dans des applications concrètes

Explique-moi donc comment dans une application web, tu fais pour récupérer certaines colonnes (ou pas), certaines colonnes de certaines jointures (ou pas), le tout trié par n'importe quelle colonne de tous ces résultats en fonction de cases cochées par un utilisateur par exemple ? Pour rigoler, ajoutons également un champ recherche qui fasse des matchs sur (et seulement sur) des colonnes choisies par l'utilisateur.

On peut encore aller un peu plus loin en se disant que certains champs (tant qu'à faire) sont créés dynamiquement par l'utilisateur dans une autre table. L'utilisateur peut rajouter un champ "adresse", "plat préféré", "animal de compagnie", ce qu'il veut, et ensuite il choisit d'afficher dans son tableau certaines de ces colonnes, avec une recherche, en faisant un tri sur celle (ou celles) qu'il veut.

Allez, balance-moi la fonction sql, procédure stockée ou peu importe le nom barbare qui fait tout ça. Bien entendu, il faut que ça tourne sur n'importe quel SGBD géré par Doctrine sans avoir à réécrire une ligne de code, sinon c'est un peu facile.

Je m'auto-quote car je ne voudrais pas que mon message passe (probablement volontairement) inaperçu, j'attends une réponse de nos gus SQLophiles

Mais bon, la réponse je la vois venir de loin : "ouéééé mais on devrait pas avoir besoin de faire ça !"
Oui, dans la tête de l'informaticien de base, les choses sont toujours simples, l'utilisateur ne devrait avoir accès qu'à ce qu'on veut bien lui donner, quand on veut bien lui donner, pour qu'il puisse forger ses jolies requêtes sql optimisées à la main, même que c'est bio ma bonne dame

[CinePhil]

Une remarque que j'ai oubliée aussi dans ma précédente réponse...

Je me suis mis à la POO assez récemment. Une classe est comme une boîte noire qui présente à l'extérieur des méthodes dont certaines permettent d'accéder aux attributs de la classe (accéder directement aux attributs, c'est mal ! ). Certaines méthodes exigent des attributs en entrée et délivrent des valeurs en sortie.

Pourquoi les développeurs ne considèreraient-ils pas la base de données comme une sorte de bibliothèque présentant des vues interrogeables (comme le font les méthodes de classes qui délivrent des listes en sortie, genre public static function getListeCouleurs()) et des procédures (similaires à des méthodes de classes) exigeant des paramètres en entrée et délivrant des valeurs en sortie ?

La maîtrise des données est le boulot de la base de données qui peut être interrogée ou mise à jour par plusieurs applications. Si le développeur a besoin d'une personne physique avec ses adresses, ses adrels et ses numéros de téléphone, il n'a à la limite pas à savoir comment sont réparties ces données dans la BDD (table de référence des civilités, table des personnes, table d'héritage des personnes physiques, table des adresses postales, table des adrels, table des numéros de téléphone et peut-être d'autres tables de référence pour qualifier les adresses, adrels et téléphones). La BDD lui présente une vue qui rassemble ces informations et les procédures qui permettent d'enregistrer une personne, la modifier ou la supprimer. Le prochain programme qui aura besoin de la même chose réutilisera la même vue et les mêmes procédures, tout comme on peut réutiliser des classes d'une application à l'autre via des bibliothèques (ou pas).

Avec une telle architecture, je ne vois pas l'intérêt d'un ORM, sinon la nécessité de devoir apprendre une syntaxe propre à l'ORM et de moins avoir la main sur les requêtes générées.

Nota : On peut très bien gérer les exceptions dans les procédures stockées et donc les récupérer en sortie et les traiter dans le programme applicatif.

[CinePhil]

Explique-moi donc comment dans une application web, tu fais pour récupérer certaines colonnes (ou pas)...

Je n'ai plus les programmes sous la main mais il y a plus de dix ans, je travaillais à l'INRA sur une application web qui présentait des résultats de statistiques sur la carte de France.
L'application permettait d'enregistrer des fichiers plats en BDD et de décrire en métadonnées la composition des fichiers plats importés. Le statisticien pouvait ensuite piocher les données qui l'intéressait dans les différents jeux de données à sa disposition, via l'interface du logiciel, un peu à la manière de ce que tu décris, avec donc des requêtes plus ou moins complexes générées par le programme.
Et tout ça était programmé en PHP procédural... sans ORM !

De toute façon, ta mécanique, ORM ou pas, il faut bien la programmer quand même. Ce n'est pas parce que tu as un ORM que l'utilisateur final va pouvoir magiquement interroger les données dans tous les sens. D'ailleurs, sur le plan de la confidentialité des données, i ne vaut mieux pas !

[Sodium]

Le statisticien pouvait ensuite piocher les données qui l'intéressait dans les différents jeux de données à sa disposition, via l'interface du logiciel, un peu à la manière de ce que tu décris, avec donc des requêtes plus ou moins complexes générées par le programme.

On est donc bien d'accords qu'à un moment ou l'autre, il faut bien générer des requêtes sql dynamiquement dans l'application. Et que tant qu'à faire, ça serait pas mal que le code qui génère ces requêtes soit propre, factorisé et réutilisable. Donc, il faut au minimum un query-builder. Donc autant utiliser directement un ORM open-source au code testé et robuste.

Ca ne répond de plus absolument pas à la question. Nos deux "experts" prétendent que toute la logique devrait se trouver côté BDD et que les requêtes sql ne devraient donc jamais être générées dynamiquement. L'application web ne devrait faire qu'exécuter des procédures stockées et récupérer des vues. J'attends qu'ils me démontrent, du haut de leur expertise, comme on fait ce que j'ai décrit en gardant 100% de la logique côté BDD.

Et tout ça était programmé en PHP procédural... sans ORM !

Ah mais on peut toujours tout faire en PHP procédural hein, je ne dis pas le contraire. C'est ce que les programmeurs de Wordpress ont fait. Le code contient un bon gros paquets de fichiers de milliers de lignes, avec des fonctions de centaines de lignes totalement dégueulasses et il sont aujourd'hui dans la merde pour faire évoluer ce code vers quelque chose de propre... mais on peut... on peut toujours tout faire. La question c'est, est-ce une bonne idée de le faire ? Non...

De même, il y a quelques siècles on bâtissait des cathédrales juste avec des échafaudages et des grues manuelles. Le boulot prenait littéralement 50 ans, mais encore une fois, c'est faisable...

[CinePhil]

Et que tant qu'à faire, ça serait pas mal que le code qui génère ces requêtes soit propre, factorisé et réutilisable.

Et bien c'était le cas. C'était bel et bien une partie du code de l'application qui générait les requêtes en fonction de ce que l'utilisateur choisissait comme données et opérations à effectuer à l'écran. Certaines opérations étaient même automatiquement confiées à R (logiciel de statistiques).

Ah mais on peut toujours tout faire en PHP procédural hein

J'ai précisé que c'était il y a plus de dix ans. De mémoire, il commençait à y avoir quelques classes dans l'application. J'imagine que depuis, ils ont dû améliorer pas mal le code.

Pour la petite histoire, mon boulot là bas (stage CNAM) a consisté à re-modéliser la BDD et modifier les programmes PHP en conséquence.
Lors de la génération de la carte (donc lancement de l'extraction et des calculs sur les données puis génération de la carte), une opération était tellement longue que le développeur de l'époque avait ajouté un "Veuillez patienter..." qui était visible généralement pas loin d'une minute, voire plus.
Grâce à ma re-conception de la BDD, on pouvait supprimer ce message parce que le temps de réponse était de l'ordre de la seconde (traitement parfois de millions de lignes sur MySQL avec un petit serveur de l'époque). Et là encore, pas d'ORM !

[Cincinnatus]

De même, il y a quelques siècles on bâtissait des cathédrales juste avec des échafaudages et des grues manuelles. Le boulot prenait littéralement 50 ans, mais encore une fois, c'est faisable...

Mais c'était du solide. Maintenant dès que quelqu'un y touche, ça brûle...

[Sodium]

Et bien c'était le cas. C'était bel et bien une partie du code de l'application qui générait les requêtes en fonction de ce que l'utilisateur choisissait comme données et opérations à effectuer à l'écran. Certaines opérations étaient même automatiquement confiées à R (logiciel de statistiques).

Donc vous avez codé un début query builder quoi... ce qu'un ORM fait (entre-autres)...

[escartefigue]

On ne rapprochera définitivement pas des points de vue inconciliables.
Ne serait-ce que parceque c'est trop tard, chaque camp s'est retranché dans sa position depuis déjà plusieurs pages d'argumentaire parfois bien construit et parfois teinté de mauvaise foi, mais peu importe.
Ce qui joue sans doute en défaveur des ORM dans ce débat, c'est aussi que les informaticiens sont des techniciens avant tout, des gens qui aiment comprendre comment les choses fonctionnent et en maîtriser les tenants et aboutissants. Ll'ajout d'une couche logicielle qui masque l'accès aux données est de ce point de vue sans doute mal perçu.
Pour ma part, je ne suis pas utilisateur d'ORM, je n'argumenterai donc pas sur ce sujet particulier, toutefois, j'ai connu de nombreux générateurs de langage et tous produisaient du code au mieux très médiocre et au pire désastreux à la fois en termes de lisibilité et de performances. C'est la raison pour laquelle j'ai un a priori plutôt défavorable.

Pour ceux qui, comme moi, ne maîtrisent pas ce sujet, voici ce qu'en dit Wikipédia ici https://fr.wikipedia.org/wiki/Mapping_objet-relationnel
Pièce jointe 502855

[mermich]

Ca fait bien 10 pages que le forum s'est apercu que c'etait une batialle de tranchees, sans ouverture d'esprit.

On peut donc bien partir pour quelques pages de plus, non ?

Sinon, histoire de vous reconcilier, vous pouvez ecrire des proc stockees et l'orm va les lire et transformer ca en belle methodes retournant des objets types.

[StringBuilder]

Ca ne répond de plus absolument pas à la question. Nos deux "experts" prétendent que toute la logique devrait se trouver côté BDD et que les requêtes sql ne devraient donc jamais être générées dynamiquement. L'application web ne devrait faire qu'exécuter des procédures stockées et récupérer des vues. J'attends qu'ils me démontrent, du haut de leur expertise, comme on fait ce que j'ai décrit en gardant 100% de la logique côté BDD.

Ah bon ?
Ta vue, elle récupère TOUTES les données possibles et imaginables, et dans le code, tu n'as qu'à implémenter :
- La liste des colonnes à récupérer
- Quelques conditions d'égalité pour implémenter les filtres
- Une jolie clause order by

Soit un code qui tiens en quelques lignes, simple, factorisé, ET REUTILISABLE. Si j'ai besoin des mêmes informations à un autre endroit de mon programme, ou à l'extérieur de mon programme, dans un autre langage, j'ai toujours ma vue sous la main qui fait 99% du boulot.

De même, il y a quelques siècles on bâtissait des cathédrales juste avec des échafaudages et des grues manuelles. Le boulot prenait littéralement 50 ans, mais encore une fois, c'est faisable...

Le point Godwin arrive à grands pas...

[rawsrc]

Pourquoi les développeurs ne considèreraient-ils pas la base de données comme une sorte de bibliothèque présentant des vues interrogeables (comme le font les méthodes de classes qui délivrent des listes en sortie, genre public static function getListeCouleurs()) et des procédures (similaires à des méthodes de classes) exigeant des paramètres en entrée et délivrant des valeurs en sortie ?

Mais c'est déjà considéré plus ou moins comme tel.
Le souci de cette approche c'est tu va manquer de flexibilité. Tu va rigidifier tes appels. Si demain par exemple, tu as besoin de la liste des couleurs mais triée par ordre décroissant et limitée qu'au dix premières couleurs, tu vas faire comment ? Recréer une nouvelle ressource ?

[Sodium]

Ah bon ?
Ta vue, elle récupère TOUTES les données possibles et imaginables, et dans le code, tu n'as qu'à implémenter :
- La liste des colonnes à récupérer
- Quelques conditions d'égalité pour implémenter les filtres
- Une jolie clause order by

Yep, donc une vue obèse, qui répond à UN besoin à UN instant T, impossible à maintenir... et il faut tout de même implémenter une requête select côté PHP.... donc générer du code SQL... donc un query-builder pour faire les choses proprement (et donc autant partir sur un ORM)

Ce que tu proposes est l'inverse absolu d'un code factorisé. A chaque nouvelle entité récupérée ou modifications des colonnes, il faudra faire appel à un dbadmin pour adapter la BDD.

Perdu, essayez encore

Je n'en reviens même pas de l'absurdité de la réponse, "suffit de faire une vue qui récupère tous les trucs possibles et imaginables"... et on te paye pour faire des trucs de ce genre ?

Une vue qui peut renvoyer toutes les tables et colonnes possibles en fonction de ce qu'on lui demande... ça ne s'appelle pas une base de données justement ?

[champomy62]

Yep, donc une vue obèse, qui répond à UN besoin à UN instant T, impossible à maintenir... et il faut tout de même implémenter une requête select côté PHP.... donc générer du code SQL... donc un query-builder pour faire les choses proprement (et donc autant partir sur un ORM)

Ce que tu proposes est l'inverse absolu d'un code factorisé. A chaque nouvelle entité récupérée ou modifications des colonnes, il faudra faire appel à un dbadmin pour adapter la BDD.

Perdu, essayez encore

Tu peux juster passer les colonnes demandees par l'utilisateur a une procedure stockee qui va generer le SQL, l'executer et renvoyer le jeux de donnees! Au plus près des donnees

[rawsrc]

Personnellement, je vous avouerai que je suis plutôt opposé aux ORM.
Pour moi, ils sont trop gros, veulent faire trop de choses et au final terminent dans la case usine à gaz.

De mon côté après avoir bien dégusté sur Doctrine (tant les perfs n'étaient pas au niveau), j'avais décidé de changer d'approche tout en m'inspirant du fonctionnement d'un ORM.
J'ai codé un petit moteur qui rend le SQL dynamique à très petite échelle.
Vous définissez une structure de ressource, vous indiquez ce qui est dynamique et le moteur complète le SQL selon le paramétrage dynamique tout en validant les données automatiquement au passage.
La structure est déjà figée. Cela permet d'avoir des cadors en SQL qui pondent du code et le développeur n'aura plus qu'à le paramétrer à l'exécution.
Bref, ça tourne très bien. Vous avez un dépôt de ressources paramétrables et assez flexibles pour des manipulations standard sur toutes les clauses : SELECT FROM WHERE GROUP BY ORDER BY LIMIT HAVING

[wallas00]

Wao,

J'ai lu la majeure partie des commentaires, et ai remis en question ma vision des chose.
J'ai découvert la notion de "base de données épaisse", dont je n'avais JAMAIS entendu parlé.
Et l'ensemble de la discussion m'a fait comprendre qu'en réalité, peu de développeurs ont eu la chance de rencontrer de véritables professionnels de la gestion des données, au cours de leur carrière.


Je conseille vivement à tous mes "copins", fans des ORM de lire cela, puis de lire la phylosophie d'enseignement sur sqlpro, pour se faire une idée plus "propre" de la situation.

Je me permet donc de poser une question à nos expérimentés ici présent(CinePhil, Champomyl62, StringBuilder, ...).
D'après ce que j'ai lu jusqu'à maintenant sur la réelle utilité des SGBD, nos implémentations de la "clean/ognion/hexagonal architecture" sont remises en question. Car, il semble finalement plus efficace d'exporter les entités métiers et leurs règles sous formes de Vues et de Procédures Stockées(1), et de se servir du backend UNIQUEMENT pour faire appel à ces "objets". Y a-t-il des "opérations métiers" qui ne doivent pas être gérés par le SGBD? L'unique exemple qui me vient en tête sont des opérations scientifiques.
Si c'est le cas, cela implique que l'industrie actuelle est en décadence, compte tenu du fait que le dénie de la qualité et de l'importance des BDDs relationnelles soit devenu un VRAI culte(dont je faisais partie).

En outre, comment gérez-vous l'évolution du modèle conceptuel de données au fil du temps?
En effet, l'une des cause du l'abandon du relationnel est son apparente rigidité, ou plus concrètement l'exigence d'avoir un modèle parfait d'entrée de jeu. Que se passe-t-il concrètement lorsque:
- j'ai une table Client, avec pleins d'attributs.
- et je me rends compte qu'il faut rajouter un autre attribut?
- aujourd'hui, ce genre d'opération génère de la frustration chez les développeurs comme moi, car on a l'impression d'être "sale" en créant une table pour le nouvel attribut, ou même en mettant à jour la table Client, car cela bouscule les fonctions logiques métiers côté backend.


Enfin, si (1) est vraie, cela légitimerai encore plus l'utilisation d'un curseur pour parcourir le résultat d'une requête, à la place du mapping fait par les ORMs. Et à quel point les optimisations statistiques faites par les SGBD sont-elles fiables? En termes de CI/CD, comment procédez-vous? Utilisez vous les outils de migrations des librairies(builder SQL) que vous injectez dans le pipeline de déploiement? Ou bien procédez-vous autrement?

[Sodium]

Tu peux juster passer les colonnes demandees par l'utilisateur a une procedure stockee qui va generer le SQL, l'executer et renvoyer le jeux de donnees! Au plus près des donnees

Alors déjà ça ne répond pas à tous les besoins exprimés, juste au premier d'entre eux (déjà la compatibilité multi-bdd...), ensuite on ne fait que déporter le problème de la génération du SQL ailleurs

[Pyramidev]

Ah bon ?
Ta vue, elle récupère TOUTES les données possibles et imaginables, et dans le code, tu n'as qu'à implémenter :
- La liste des colonnes à récupérer
- Quelques conditions d'égalité pour implémenter les filtres
- Une jolie clause order by

Soit un code qui tiens en quelques lignes, simple, factorisé, ET REUTILISABLE. Si j'ai besoin des mêmes informations à un autre endroit de mon programme, ou à l'extérieur de mon programme, dans un autre langage, j'ai toujours ma vue sous la main qui fait 99% du boulot.

Les vues sont adaptées pour faire des jointures, des filtres, etc. qui sont connus à l'avance, avant l'exécution du programme. C'est bien, mais ça ne répond pas à l'avantage des ORM que Sodium et moi mettons le plus en avant : la génération de requêtes SQL qui dépendent du runtime.

En informatique de gestion, dans une application normale, il y a plein de requêtes SQL qui dépendent du runtime. En fonction de ce que l'utilisateur coche et sélectionne ou écrit, on n'aura pas les mêmes critères de filtres, ni les mêmes critères de tri, ni les mêmes champs retournés. Donc, quelque part dans le code, il faut faire un lien entre des données qui dépendent du runtime et la requête SQL à générer.

Dans mon message du 07/09/2019, j'ai écrit un exemple simpliste qui passe par l'ORM de Django (en Python) et qui a deux entiers optionnels country_population_min et country_population_max.
Juste après, SQLpro a répondu par un exemple simpliste qui passe par une procédure stockée avec deux entiers obligatoires @MIN et @MAX.
Après, pour gérer le cas d'entiers optionnels, tu as proposé une solution avec pMin.Value = min.OrDefault(0); et pMax.Value = max.OrDefault(int.MAX_VALUE);.

Dans des exemples plus réalistes, la position des pro-ORM est que la génération de requêtes SQL qui dépendent du runtime sera plus maintenable en passant par un ORM que par des procédures stockées.

[MaitrePylos]

Explique-moi donc comment dans une application web, tu fais pour récupérer certaines colonnes (ou pas), certaines colonnes de certaines jointures (ou pas), le tout trié par n'importe quelle colonne de tous ces résultats en fonction de cases cochées par un utilisateur par exemple ? Pour rigoler, ajoutons également un champ recherche qui fasse des matchs sur (et seulement sur) des colonnes choisies par l'utilisateur.

En gros tu parles de PhpMyAdmin avec les bons grant sur le user.....ça doit faire le taf

[Sodium]

En gros tu parles de PhpMyAdmin avec les bons grant sur le user.....ça doit faire le taf

La question n'est pas de savoir comment programmer et déployer la solution

SqlPro et Stringbuilder prétendent que générer des requêtes côté application ne devrait pas arriver, que tout devrait être géré côté DB et que l'application ne devrait que faire appel à des vues ou procédures stockées. Eh bien j'attends qu'ils me le prouvent.

Pour le moment, la réponse que j'ai eue c'est "suffit de faire une vue qui récupère toutes les valeurs possibles et imaginables", ce que je trouve moyennement convainquant

PHPmyadmin est d'ailleurs un très bon exemple (de type d'application, pas le code, il est pourri). Comment on fait un PHPmyadmin sans générer de requêtes sql côté PHP ?