Discussion :

[guetlaur]

A mon sens, un ORM est une aide précieuse pour le développeur après une bonne conception :
- les opérations CRUD peuvent être réalisées avec l'ORM ;
- cependant, il faut mettre le maximum de logique métier dans le SGBD sous forme de procédures stockées ou de packages.

[pachot]

Tout comme le code devient du binaire, personnellement je préfère utiliser un code propre et compréhensible plutôt que du binaire

Sql est un peu l'assembleur des BDDs tout comme JavaScript est l'assembleur du web côté client.

Un peu de hiérarchie des languages de programmation:

L1G: Language de 1ère génération: binaire
L2G: Language de 2ème génération: assembleur
L3G: Language de 3ème génération: langage procédural (Java par exemple)
L4G: Language de 4ème génération: langage déclaratif (SQL)

De même, les structures hiérarchiques (Object, XML, JSON,...) sont les plus vieilles (IMS) et ont été supplantées par le relationnel (SQL) il y a longtemps. Revenir à ces structures en leur mettant de nouveaux noms et de nouvelles syntaxe n'a rien de plus moderne.

ORM, Object,... tout ça c'est un retour en arrière pour les structures de données s'un système d'information. C'est ça qui est vieux. SQL est un language au dessus des languages procéduraux: le SQL est compilé par l’optimiseur en language procédural (le plan d'exécution). L'optimiseur SQL passed de L4G à L3G tout comme le compilateur Java passe de L3G à L2G.

Si on n'aime pas las syntaxe SQL, il y a des DSL qui génèrent du SQL, mais en restant au même niveau (L4G déclaratif), comme https://www.jooq.org/

[StringBuilder]

J'avoue ne pas comprendre quand certains préconisent un ORM pour faire du CRUD et des PS pour faire les traitements.

Rien de plus simple que le CRUD… même un pogo qui a appris le SQL avec MySQL saura écrire les requêtes.
Quel intérêt de passer par un ORM ?

Ensuite, l'ORM, dès qu'on va commencer à faire des traitements plus complexes, va être à la rue.
Et dans tous les cas, si le DBA et les devs "BDD" ont fait leur boulot, il y aura toutes les vues et PS nécessaires pour répondre à toutes les problématiques.

Vous semblez oublier qu'avec votre ORM, si le modèle de données évolue (split d'une table en deux, modification d'une clé primaire, passage d'une colonne d'énumération en une table de référence, etc.) il faut repasser dans tous le code, et tout recompiler… dommage quand même quand il s'agit simplement de faire un CRUD sur une table !
Si vous travaillez avec des vues, une simple évolution de ces dernières permettra de ne rien toucher au code applicatif ! Très pratique si vous avez plusieurs applications impactées par la modification de la base…

Un petit rappel de cet article sur le sujet :
https://www.developpez.net/forums/bl...-base-donnees/

[Sodium]

Rien de plus simple que le CRUD… même un pogo qui a appris le SQL avec MySQL saura écrire les requêtes.
Quel intérêt de passer par un ORM ?

On l'a expliqué en long, en large et en travers, un ORM permet du code beaucoup plus propre et concis. On peut générer en une commande les objets modifiables, les tables qui vont avec et les actions et formulaire permettant de les modifier. Le code d'un CRUD va donc souvent, très schématiquement ressembler à ça :

Code PHP :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
 
function add($request) {
    $product = new Product();
 
    $form = new ProductForm($product);
 
    $form->handleRequest($request);
 
    if ($form->isValid()) {
        $this->entitiyManager->save($product);
    } 
}
 
function update($product, $request) {
    $form = new ProductForm($product);
 
    $form->handleRequest($request);
 
    if ($form->isValid()) {
        $this->entitiyManager->save($product);
    } 
}

Le formulaire est capable de mapper tout seul les informations de la bdd de l'objet avec ses champs et vérifie la validité des données, l'ORM est capable d'interpréter tout seul données du formulaire, le programmeur a juste à faire un peu de paramétrage dans beaucoup de cas.

Et encore une fois le code SQL est une plaie à générer dynamiquement par programmation, quand on est un minimum organisé on finit toujours par un moins écrire un query-builder, soit un ORM en moins bien.

Et dans tous les cas, si le DBA et les devs "BDD" ont fait leur boulot, il y aura toutes les vues et PS nécessaires pour répondre à toutes les problématiques.

Toutes les boîtes n'ont pas un DBA et n'en ont de toute façon pas besoin. Pour des traitements simples, il est beaucoup plus intelligent que la personne gérant l'application soit capable de l'écrire de A à Z.

Vous semblez oublier qu'avec votre ORM, si le modèle de données évolue (split d'une table en deux, modification d'une clé primaire, passage d'une colonne d'énumération en une table de référence, etc.) il faut repasser dans tous le code, et tout recompiler… dommage quand même quand il s'agit simplement de faire un CRUD sur une table !

Ca démontre juste que tu ne connais pas les ORM, leur intérêt est justement entre autres qu'il est très facile de s'adapter à un changement de la structure des données.

[Pyramidev]

Vous semblez oublier qu'avec votre ORM, si le modèle de données évolue (split d'une table en deux, modification d'une clé primaire, passage d'une colonne d'énumération en une table de référence, etc.) il faut repasser dans tous le code, et tout recompiler… dommage quand même quand il s'agit simplement de faire un CRUD sur une table !

On ne repasse pas dans tout le code, on ne repasse que dans la partie qui implémente l'accès aux bases de données, qui doit normalement être isolée du reste du code. Si elle ne l'est pas, alors il y a un problème d'architecture.
Concernant la quantité de code à recompiler, ça dépend du langage et du programme. Dans un langage compilé, si on veut vraiment que la partie qui implémente l'accès aux bases de données puisse être recompilée et redéployée indépendamment du reste, on peut l'isoler dans ce que l'on appelle une bibliothèque dynamique (DLL).

Si vous travaillez avec des vues, une simple évolution de ces dernières permettra de ne rien toucher au code applicatif ! Très pratique si vous avez plusieurs applications impactées par la modification de la base…

Ce n'est vraiment utile que si ces applications sont développées dans des langages différents. Si c'est dans le même langage, alors le code qui accède à la base de données doit être commun. Sinon, c'est qu'il y a un problème d'architecture.

Il ne faut pas croire que les programmes qui appellent la BDD sont obligés d'être de grandes boules de boue immaintenables dans lesquelles il faut modifier un paquet de code dès qu'il y a un changement simple. Ça arrive, car beaucoup de développements sont faits n'importe comment, mais ce n'est pas une fatalité.

[deltree]

J'avoue ne pas comprendre quand certains préconisent un ORM pour faire du CRUD et des PS pour faire les traitements.

Rien de plus simple que le CRUD… même un pogo qui a appris le SQL avec MySQL saura écrire les requêtes.
Quel intérêt de passer par un ORM ?

Ensuite, l'ORM, dès qu'on va commencer à faire des traitements plus complexes, va être à la rue.
Et dans tous les cas, si le DBA et les devs "BDD" ont fait leur boulot, il y aura toutes les vues et PS nécessaires pour répondre à toutes les problématiques.

Vous semblez oublier qu'avec votre ORM, si le modèle de données évolue (split d'une table en deux, modification d'une clé primaire, passage d'une colonne d'énumération en une table de référence, etc.) il faut repasser dans tous le code, et tout recompiler… dommage quand même quand il s'agit simplement de faire un CRUD sur une table !
Si vous travaillez avec des vues, une simple évolution de ces dernières permettra de ne rien toucher au code applicatif ! Très pratique si vous avez plusieurs applications impactées par la modification de la base…

Un petit rappel de cet article sur le sujet :
https://www.developpez.net/forums/bl...-base-donnees/

Au contraire ça rend toute les modifications de base plus fiable: ça plante à la compil au lieu de planter au runtime sur serveur: en DEV si on teste pas en local, en PROD si on teste nulle part (ok la ça doit pas arriver)

IL faut peut-être rappeler la base d'un projet objet bien structuré:
- Toute la création de la base est scriptée: flyway liquibase ou autre
- Au moins un TU permet de tester le mapping objet sur la base => dès le build ça plante.

Dès lors les modification sont plus sereine:
- on modifie le mapping objet et les scripts (il y a moyen d'automatiser la génération entre les deux référentiels dans un sens ou dans l'autre, mais c'est un autre débat)
- on résoud les TU, (si les test de non reg avaient une couverture complète, on aurait finit, mais on sais comment ça se passe)
- on remonte des objets mappés, les IDE nous aident, on a directement l'analyse d'impact, en automatique.

On parlait de repasser dans tout le code: quand tes requetes SQL sont des string non testées par TU, il faut repasser dans tous le code, faire un recherche full-text pour faire la même analyse d'impact.
A la limite, je veux bien entendre que toutes les requetes SQL sont testées par des TU mais dans le cas du CRUD, c'est autant de requetes et de test à code (déjà travaillé sur un BDD à 500 tables? boom 500*4 = 2000 requetes et T à maintenir ... pour rien)

[deltree]

...
Si on n'aime pas las syntaxe SQL, il y a des DSL qui génèrent du SQL, mais en restant au même niveau (L4G déclaratif), comme https://www.jooq.org/

Alors désolé mais jooq, s'il y a bien un truc que je ne conseillerais pas c'est ça! (et j'ai pratiqué) c'est un wrapper de SQL qui n'apporte rien de plus que SQL, autant coder en pur SQL.

Pou moi soit on fait du SQL sans surcouche au langage, et on peut utiliser myBatis qui permet quand même de "ranger" ses requetes SQL et de supprimer la partie fastidieuse de fetch à la main, soit on préfère le tout objet pour les raisons évoquées par ailleurs et on passe en JPA, qui est normé, permet d'utiliser Hibernate, Eclipse link ou autre.
Ne pas oublier aussi JTA qui apporte la partie transactionelle.

[vertex.3F]

beaucoup d'échanges passionnés, je n'ai pas tout lu, désolé
je vais juste essayer de donner mon avis à la question initiale [ sondage: Êtes-vous pour l'utilisation d'un ORM (mapping objet-relationnel) ? Pourquoi ? Partagez vos avis ]

je suis développeur java coté "back-end" depuis plusieurs années et je suis vraiment satisfait d'utiliser JPA natif (Hibernate ou EclipseLink) ou Spring-Data JPA (Hibernate).

Pourquoi ?

Parce que cela facilite grandement la structuration et la clarté de mon code (...et le temps passé ! dans Spring on peut s'appuyer sur l'interface Repository pour la mise en place du pattern DAO, voire utiliser directement JpaRepositoryImplementation / SimpleJpaRepository https://www.baeldung.com/spring-data...epository-save => les méthodes pour un CRUD sont dispo en qques minutes).
Parce que je peux aussi très facilement ajouter des accès "custom" dès que le besoin s'en fait sentir : jointures, règles d'accès spécifiques, besoin de performance, ...
Je code ces accès custom le plus souvent en JPQL / HQL (et rarement en Criteriabuilder, faudra que je m'y penches davantage car l'update/delete est dispo depuis JPA 2.1 ...)
Lorsque je n'ai plus le choix avec la techno JPA, je code aussi en SQL natif naturellement (NB : je m'efforce d'eviter le SQL natif car j'ai eu plusieurs applis a migrer et ça continue... en ce moment mes clients délaissent les databases Oracle pour les petites et moyennes applications).
Je dois préciser qu'en phase de mise au point de mon code (et en phase d'optimisation des perfos lorsque necessaire) j'active systémétiquement l'affichage du SQL généré par JPA.

Au final, je dois comprendre et maitriser JPA, 2 langages (JPQL + SQL), la conversion (JPQL vers SQL), les particularités des implémentations de JPA (la config par ex.), etc...
Ce n'est donc pas vraiment facile. J'accepte cet effort car le bénéfice au niveau lisibilité (maintenabilité) du code de l'appli me parait considérable et essentiel.

Il m'est arrivé de tomber sur des applis java dont la couche de persistence était réalisée exclusivement en jdbc sans pattern DAO ni autre organisation du code... ben quelle galère ! la duplication de code, son volume, sa non standardisation => illisible et non-maintenable, c'est dans ces moments là que j'apprécie les ORM !

[marc.collin]

j'ajouterais que moindrement que tu dois ajouter une particularité du bd, tu vas être obligé de faire quelques tour de passe passe en jpa si c'est possible... sinon directement avec le orm


tu as spring data jdbc qui donne accès au requête de base: save, delete, find... requête par nom d'attribut, transaction et il n'y aurait pas eu tous ces défauts

le défaut de jpa, hibernate c'est le non support de reactive... obligé de passer par Spring Data R2DBC

[SQLpro]

SQL est un reliquat d'une autre époque et il est très compliqué de faire un code compréhensible et réutilisable.

C'est peut être votre cerveau qui est obsolète !
Mais c'est surtout un manque de formation qui est à l'origine du rejet du SQL auprès de développeurs...
Or le SQL est bien entré dans le 21e siècle depuis longtemps avec le norme SQL:1999 permettant les types objets, le récursif, les déclencheurs, les fonctions fenêtrées, etc.
Le NoSQL qui voulait d'abord dire "Plus de SQL" est passé au N O SQL c'est à dire "Not Only SQL" puis maintenant au New SQL !

Donc ORM à 100%, il serait temps que les bases de données évoluent en rentrent dans le 21e siècle.

N'oubliez jamais ce que disait Ted Neward : "ORM is the Vietnam of computer sicience". Autrement dit tout le monde s’embourbera dans cette merde et y pataugeras longtemps...

Une de mes études, d'il y a plus de 10 ans et toujours d'actualité :
http://sqlpro.developpez.com/cours/b...s-epaisses.pdf

A +

[SQLpro]

... Apprendre plusieurs langage de programmation c'est stimulant. Apprendre des langage de structuration comme le HTML ou langage base de données comme le SQL nettement moins, on le fait parce que l'on en a besoin mais il y a nettement moins de satisfaction intellectuelle derrière...

Vous venez de confirmer ce que je soupçonnais de votre part. Votre but est de vous faire plaisir dans la vie. Donc, vous n'aimez pas le SQL, comme vous pourriez ne pas aimer les fraises. Donc, les fraises, c'est de la merde...

Quand on travaille il y a des choses que l'on aime faire et d'autres moins. Le problème c'est qu'on a pas le choix. mais vous pourriez avoir l'intelligence d'essayer de l'aimer !

A +

[SQLpro]

Je vous propose d'alimenter/voter pour chaque propositions du tableau suivant (1 ligne = 1 argument/proposition).

Je te renvoi a mon article pour compléter le tableau :
http://sqlpro.developpez.com/cours/b...s-epaisses.pdf

A +

[SQLpro]

toujours obligé de dénigrer?

tu enseignerais plutôt avec microsoft sql server?

Ou IBM DB2, qui sont le plus proche des normes SQL. Oracle en étant toujours très très loin avec un dialecte non portable (TO_CHAR, TO NUMBER.... au lieu de CAST, NVL au lieu de COALESCE, des jointures externe (+) au lieu de OUTER...)

A +

[SQLpro]

Ça existe en Transact-SQL et en PL/SQL.

Ça existe même dans la norme SQL qui n'est pas limitée aux simples requêtes, mais aussi depuis 1992 aux "PSM", "Persistant Stored Module". J'en parle dans tous mes livres sur SQL...

Extraits :


Le PSM (et le CLI) norme SQL :





les structures de bouclage (norme SQL) :




Donc, formation à prévoir !

A +

[SQLpro]

D'ailleurs, pour ma culture générale, à propos des UDF (User Defined Functions), est-ce que SQL supporte la notion de fonction de première classe ? Par exemple, est-ce qu'une UDF peut elle-même prendre une UDF en paramètre et retourner une UDF ?

NON, pour des raisons évidentes d'optimisation.

Si oui, est-ce qu'une fonction peut avoir un état qui dépend du runtime, ou bien est-ce que les fonctions sont toujours sans état, comme les pointeurs de fonction en C ?

NON, pour des raisons évidentes d'optimisation.

S'il n'y a pas de fonctions de première classe, y a-t-il quelque chose qui s'en rapproche, comme les fonctions virtuelles de la programmation orientée objet ?

NON, pour des raisons évidentes d'optimisation.

Si oui, aurais-tu un exemple de bout de code pour illustrer cela ? Existe-il un SGDB gratuit qui supporte ce genre de chose, ou bien est-ce limité à des SGDB payants ?

NON, pour des raisons évidentes d'optimisation.

Quelles sont ces raisons ?

Le langage SQL n'est pas objet du tout, même s'il admet pouvoir stocker des objets. C'est un langage de requête pour lequel on ne décrit pas les instructions à exécuter, mais un langage avec lequel on pose au système une question dont on attend la réponse (le synonyme de requête étant demande).

La question que l'on pose peut être posée de différentes manière. Et l'optimiseur construira une séquence d'instruction (plan d'exécution) qui, une fois exécutée, délivrera la réponse attendue. Il n'est pas rare que les différentes manières de poser la question, conduise strictement au même plan de requête... car les SGBDR fonctionnent selon des concepts sémantiques et non procéduraux. En d'autres termes ils s'intéressent aux sens des données et non pas à la "technique"...
Cela était bien connue avant l'informatique. Molière avait basé une de ses pièces de théâtre sur le sujet... Je vous laisse la découvrir...

De ce fait ce que vous écrivez, UDF compris, n'est pas ce qui va être réalisé ! Des transformation sont effectuées pour abolir les effets itératifs des fonctions afin d'améliorer les performances. Dans SQL Server cela s’appelle "inlining function"
https://docs.microsoft.com/fr-fr/sql...esqldb-current

Autrement dit, le choix de SQL est basé sur les performances au détriment des aspects de réutilisation, généricité, encapsulation et autres concepts propre aux langages objets... et c'est tant mieux, car les langages objets sont réputés lents, bien plus lent que les langages strictement procéduraux...

A +

[Pyramidev]

Ça existe même dans la norme SQL qui n'est pas limitée aux simples requêtes, mais aussi depuis 1992 aux "PSM", "Persistant Stored Module".

Je ne connaissais pas SQL/PSM. Merci pour l'info.

Autrement dit, le choix de SQL est basé sur les performances au détriment des aspects de réutilisation, généricité, encapsulation et autres concepts propre aux langages objets... et c'est tant mieux, car les langages objets sont réputés lents, bien plus lent que les langages strictement procéduraux...

La réutilisation, la généricité et l'encapsulation ne s'opposent pas forcément aux performances. Il existe plusieurs manières de faire de l'abstraction sans coût. Dans l'industrie, le langage le plus connu pour ça est le C++ dont les fonctions constexpr n'ajoutent pas de coût au runtime et dont les templates permettent de faire du polymorphisme sans coût au runtime, donc sans passer par une table virtuelle ou autre forme de tableau associatif parcouru au runtime. Il y a aussi les macros du C et du C++ qui ont beaucoup de défauts, mais qui sont un exemple connu d'abstraction sans coût au runtime.

[blbird]

Il m'est arrivé de tomber sur des applis java dont la couche de persistence était réalisée exclusivement en jdbc sans pattern DAO ni autre organisation du code... ben quelle galère ! la duplication de code, son volume, sa non standardisation => illisible et non-maintenable, c'est dans ces moments là que j'apprécie les ORM !

Comparer une solution qu'on aime au pire du pire pour démontrer qu'elle est mieux, c'est pas très probant je trouve quand même.

Les ORM sont bien souvent des usines à gaz, qui nécessites des couches supplémentaires, des apprentissages supplémentaires, beaucoup de configurations suplémentaire, pour au final peu de gain pour les développeurs et encore moins pour les utilisateurs. Et l'argument principal qui est de pouvoir changer la source de données, n'est utilisé que dans très peu de cas voir jamais (jamais vu pour ma part, pourtant j'en ai vu des projets avec ORM, de toutes tailles).

La maintenance est un faux problème : quelque soit la technologie, quand c'est mal architecturé et/ou mal codé, ce n'est pas maintenable.

Un ORM bien fait comparé à un SQL en procédures stockées bien fait, que ce soit en maintenance ou en rapidité d'exécution, le SQL gagne selon moi à tout les coups.

Encore plus dans le cas où tu as des "développeurs" qui ne veulent pas comprendre le SQL car l'ORM fait tout : catastrophes en vue.

[Sodium]

@SQLpro oui, ça valait bien la peine de déterrer le topic pour ça...

[SQLpro]

La réutilisation, la généricité et l'encapsulation ne s'opposent pas forcément aux performances. Il existe plusieurs manières de faire de l'abstraction sans coût. Dans l'industrie, le langage le plus connu pour ça est le C++ dont les fonctions constexpr n'ajoutent pas de coût au runtime et dont les templates permettent de faire du polymorphisme sans coût au runtime, donc sans passer par une table virtuelle ou autre forme de tableau associatif parcouru au runtime. Il y a aussi les macros du C et du C++ qui ont beaucoup de défauts, mais qui sont un exemple connu d'abstraction sans coût au runtime.

Rien à voir avec une optimisation SQL basées sur 2 axes :
1) l'indexation
2) le parallélisme
Je ne connais pas de langage permettant de faire du parallélisme automatiquement sans que l'on écrive la moindre ligne de code...
Ni de langage capable d'utiliser un index ou pas dans une collection en décidant tout seul la meilleure approche

A +

[vertex.3F]

Comparer une solution qu'on aime au pire du pire pour démontrer qu'elle est mieux, c'est pas très probant je trouve quand même.

Les ORM sont bien souvent des usines à gaz, qui nécessites des couches supplémentaires, des apprentissages supplémentaires, beaucoup de configurations suplémentaire, pour au final peu de gain pour les développeurs et encore moins pour les utilisateurs. Et l'argument principal qui est de pouvoir changer la source de données, n'est utilisé que dans très peu de cas voir jamais (jamais vu pour ma part, pourtant j'en ai vu des projets avec ORM, de toutes tailles).

La maintenance est un faux problème : quelque soit la technologie, quand c'est mal architecturé et/ou mal codé, ce n'est pas maintenable.

Un ORM bien fait comparé à un SQL en procédures stockées bien fait, que ce soit en maintenance ou en rapidité d'exécution, le SQL gagne selon moi à tout les coups.

Encore plus dans le cas où tu as des "développeurs" qui ne veulent pas comprendre le SQL car l'ORM fait tout : catastrophes en vue.

salut,
sorry, STP relis en globalité je ne veux rien démontrer mais simplement donner mon avis :-)
Et je ne dis pas le contraire concernant le reste des elements de ton message; je ne dénigre pas le SQL, outil difficilement contournable pour interroger un SGBDR, au contraire je cherche à l'apprendre pour essayer de maitriser les resultats obtenus (directement en JDBC ou via des couches tq ORM); et un ORM représente pour moi un allié afin d'apporter une structure/clarté au code avec gain de temps evident (reecrire son propre ORM est difficile et long ... pourquoi résister ?)
a+