Discussion :

[StringBuilder]

salut,
reecrire son propre ORM est difficile et long ... pourquoi résister ?
a+

Bonjour,

Je pense que ton analyse est biaisée à cause de cette phrase.
Évidement, que ne pas utiliser un ORM au profit de l'écriture de son propre ORM, ça n'a aucun sens. C'est comme dire "on ne peut pas se passer de voiture, car si on veut construire sa propre voiture c'est trop compliqué".

Un ORM n'a de sens qu'au niveau du développeur qui ne maîtrise rien de la couche de données : c'est un moyen de piloter la couche d'accès aux données sans avoir la moindre notion de SQL.

Cependant, pour le programme dans sa globalité, mise à part sur des projets très volumineux avec de nombreux développeurs qui ne maîtrisent pas tous la couche d'accès aux données, c'est plus un handicap qu'autre-chose :
- La plupart des opérations seront bien plus lentes
- Le code lui-même peut se trouver largement alourdi : là où une vue, requête SQL ou procédure stockée pourrait apporter un résultat complexe en une seule interrogation, un ORM peut demander une usine à gaz (par exemple interroger une table récursive)
- La méconnaissance de la couche de données des développeurs (qui sont souvent concepteurs) va souvent résulter en un modèle de données complètement bancal et des usines à gaz mise en places pour gérer des fonctionnalités pourtant simples à gérer en SQL

[Invité]

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

Récemment, j'ai récupéré le projet d'une boîte externe. C'est un shop avec pas mal de complexité, fait sous Symfony, respectant les standards de Symfony. Je n'ai eu aucun soucis à comprendre le schéma de la base de données et à reprendre le code source. Donc si, les ORM ont un intérêt, ne pas l'admettre démontre un total manque de bon sens.

À côté de ça, notre BDD interne est totalement incompréhensible si l'on n'a pas été formé pour et il faut au moins quatre personnes pour être capable de répondre aux demandes, savoir quelle information se trouve où, ce que les noms de tables et de champs veulent dire etc.

Mais bon, si une expertise auto-proclamée en bases de données vous permet de briller en base de données, tant mieux hein

Un ORM n'a de sens qu'au niveau du développeur qui ne maîtrise rien de la couche de données : c'est un moyen de piloter la couche d'accès aux données sans avoir la moindre notion de SQL.

On ne peut pas utiliser un ORM si l'on ne sait pas comment fonctionne une base de données. Il faut toujours déclarer les types de champs, les relations etc à la main. La base de données ne va pas se construire toute seul par magie.

La méconnaissance de la couche de données des développeurs (qui sont souvent concepteurs) va souvent résulter en un modèle de données complètement bancal et des usines à gaz mise en places pour gérer des fonctionnalités pourtant simples à gérer en SQL

Oui, d'ailleurs c'est pour ça qu'autant de développeurs utilisent des ORM et que Symfony est la compétence principalement demandée en PHP. C'est pour ça que Magento, le CMS e-commerce PHP le plus adapté à des très grosses applications utilise un ORM. Les chefs de projet veulent une usine à gaz bancale, c'est dans leur cahier des charges.

[Pyramidev]

Débattons sur du code concret. Je vais encore prendre pour exemple l'ORM de Django (en Python).

Dans un premier temps, je vais récupérer deux extraits de l'article : https://simpleisbetterthancomplex.co...y-queries.html

Code Python :

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

1
2
3
4
5
6
7
class Country(models.Model):
    name = models.CharField(max_length=30)
 
class City(models.Model):
    name = models.CharField(max_length=30)
    country = models.ForeignKey(Country)
    population = models.PositiveIntegerField()

For example, let’s say we want to see the total population by country, but only those countries where the total population is greater than 50,000,000:

Code Python :

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

1
2
3
4
5
6
7
8
9
10
11
City.objects.values('country__name') \
  .annotate(country_population=Sum('population')) \
  .filter(country_population__gt=50000000) \
  .order_by('-country_population')
 
[
  {'country__name': u'China', 'country_population': 309898600},
  {'country__name': u'United States', 'country_population': 102537091},
  {'country__name': u'India', 'country_population': 100350602},
  {'country__name': u'Japan', 'country_population': 65372000}
]

And finally the SQL query:

Code SQL :

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

1
2
3
4
  SELECT "core_country"."name", SUM("core_city"."population") AS "country_population"
    FROM "core_city" INNER JOIN "core_country" ON ("core_city"."country_id" = "core_country"."id")
GROUP BY "core_country"."name" HAVING SUM("core_city"."population") > 50000000
ORDER BY "country_population" DESC

Pour l'instant, il s'agit d'un exemple de code simple qui génère toujours la même requête SQL.

Mais, dans un vrai programme, la requête que l'on va générer dépendra souvent du code appelant. Par exemple, admettons que l'on veut paramétrer le filtrage à partir de deux critères de filtres optionnels : country_population_min et country_population_max.

Le code de la fonction qui construit la requête contiendra alors la portion de code :

Code Python :

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

1
2
3
4
5
6
7
query_set = City.objects.values('country__name') \
  .annotate(country_population=Sum('population'))
if country_population_min is not None:
    query_set = query_set.filter(country_population__gte=country_population_min)
if country_population_max is not None:
    query_set = query_set.filter(country_population__lte=country_population_max)
query_set = query_set.order_by('-country_population')

Dans l'exemple ci-dessus, la variable que j'ai appelée query_set stocke les informations qui permettront de construire plus tard la requête SQL. Les méthodes values, annotate et filter permettent d'ajouter de telles informations.
En fonction des conditions country_population_min is not None et country_population_max is not None, la requête SQL qui sera construite aura une forme différente.

Avec l'ORM, on peut aussi automatiser des tests indépendants du SGBD sous-jacent, mais je n'ai pas le temps d'écrire des exemples dans le message présent.

Le code est concis, flexible et testable. Est-ce que faire la même chose avec des procédures stockées en SQL aurait vraiment été mieux ?

[Invité]

En doctrine ça serait encore plus simple, déjà je ferais des méthodes dans le repository réutilisable en chaînage là où nécessaires, ex :

Code :

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

1
2
3
4
5
6
7
8
$query = $cityRepo->initQuery();
$datas = $query
   ->getBasicInfos()
   ->getCountry()
   ->getPopulationSum()
   ->wherePopulationOver($x)
   ...
   ->fetchAll()

[SQLpro]

... Le code est concis, flexible et testable. Est-ce que faire la même chose avec des procédures stockées en SQL aurait vraiment été mieux ?

Avec un UDF "table en ligne", c'est aussi extrêmement simple...

Code :

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

1
2
3
4
5
6
7
CREATE FUNCTION F_CITY_POPULATION (@MIN INT, @MAX INT)
RETURNS TABLE
AS RETURN(SELECT core_country.name, SUM(core_city.population) AS country_population
          FROM   core_city 
                 INNER JOIN core_country ON core_city.country_id = core_country.id
          GROUP  BY core_country.name 
          HAVING SUM(core_city.population) BETWEEN @MIN AND @MAX);

Une fonction table étant l'équivalent d'une vue paramétrique, elle en possède les mêmes propriétés. Par exemple on peut mettre à jour les données de la base à l'UDF table en ligne dans les mêmes conditions que les vues.

A +

[Invité]

Il ne demande pas comment faire un select avec des variables, il demande comment adapter une requête facilement une requête en fonction des besoins du code...

[Pyramidev]

Avec un UDF "table en ligne", c'est aussi extrêmement simple...

Code :

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

1
2
3
4
5
6
7
CREATE FUNCTION F_CITY_POPULATION (@MIN INT, @MAX INT)
RETURNS TABLE
AS RETURN(SELECT core_country.name, SUM(core_city.population) AS country_population
          FROM   core_city 
                 INNER JOIN core_country ON core_city.country_id = core_country.id
          GROUP  BY core_country.name 
          HAVING SUM(core_city.population) BETWEEN @MIN AND @MAX);

En fait, dans mon exemple, les deux paramètres n'étaient pas des entiers obligatoires, mais des entiers optionnels, d'où mes deux if.
D'ailleurs, dans le vrai code auquel je pense, il y a aussi des tris optionnels qui ne sont pas toujours dans le même sens.

[StringBuilder]

La fonction UDF, ça tombe bien, est requêtable.

Pas conséquent, on peut parfaitement gérer le order by lors de la construction du select final.
Quant au @min / @max, on peut parfaitement soit utiliser between isnull(@min, 0) and isnull(@max, 99999999999) directement dans l'UDF, ou plus proprement je pense, passer au paramètre des valeurs renseignées de ma même manière directement dans le code du programme :

pMin.Value = min.OrDefault(0);
pMax.Value = max.OrDefault(int.MAX_VALUE);

Bref, rien de plus compliqué.

Par contre, avec vos solutions ORM, on va rigoler quand il va falloir faire ce genre de comptages :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
select 
     country.continent,
     country.name pays,
     sum(city.population) * case when city.type = 'village' then 1 else 0 end paysans,
     sum(city.population) * case when city.type = 'village' then 1 else 0 end citadins,
     sum(city.population) population_totale,
     sum(city.population) over (partition by country.continent) population_continent
from 
country
inner join city on city.country_id = country.id
group by country.name

Et là on est dans du très simple.

[Invité]

Pas conséquent, on peut parfaitement gérer le order by lors de la construction du select final.
Quant au @min / @max, on peut parfaitement soit utiliser between isnull(@min, 0) and isnull(@max, 99999999999) directement dans l'UDF, ou plus proprement je pense, passer au paramètre des valeurs renseignées de ma même manière directement dans le code du programme :

Donc on en revient toujours à la même chose : si ta requête doit pouvoir répondre à X cas, il faut inclure X cas dedans, donc avoir un code dégeulasse impossible à maintenir. Avec un ORM, je peux créer un objet requête de base et lui greffer à la volée ce que je veux. Si j'ai une requête qui dans 99% de cas me renvoie juste une liste de voiture par marque et que d'un coup j'ai besoin de récupérer uniquement les voitures rouges ayant plus de 150k km possédées par des unijambistes, il me suffit d'ajouter une fonction qui fait ça dans mon repository et de l'ajouter à la requête. Donc oui, tu peux sans doute créer une fonction sql avec 50 paramètres qui est capable de rajouter des where, select, order by, join, count et tout ce que tu veux. Sauf qu'on appelle ça une usine à gaz impossible à maintenir et qui va nécessiter de gros tests avant chaque déploiement de fonctionnalité

Quant au @min / @max, on peut parfaitement soit utiliser between isnull(@min, 0) and isnull(@max, 99999999999) directement dans l'UDF, ou plus proprement je pense, passer au paramètre des valeurs renseignées de ma même manière directement dans le code du programme :

Ou plus proprement, on n'utilise pas quoi que ce soit quand on n'en a pas besoin. Là tu es déjà en train de polluer la compréhension de ton code avec des trucs inutiles. "Pourquoi il a mis 99999999 là ? Ah oui, c'est au cas où il n'y aurait pas de paramètres xy passé à la fonction". Bref, exactement ce qu'on apprend à ne pas faire quand on apprend à pondre du code propre. Une fonction doit idéalement avec un paramètre, deux ça reste bien, trois exceptionnellement.

Par contre, avec vos solutions ORM, on va rigoler quand il va falloir faire ce genre de comptages :

Je ne vois pas bien l'intérêt de l'exemple, dans tous les cas tout ça se gèrera très côté serveur au moment de la génération de la vue. Vous pensez BDD alors qu'il faut penser application. On code une application qui a besoin de récupérer des données, on ne remplit pas un tableau Excel. Si à partir de x personnes, un village devient une ville, ça me semble une très mauvaise idée d'aller mettre ça dans la base de données, là ou personne n'ira jamais changer l'info et ne comprendra pas pourquoi sa vue lui renvoie ça.

Par ailleurs, tes trucs à base de case c'est exactement ce qu'on évite en programmation moderne, c'est du code beaucoup trop verbeux et chiant à remplacer lorsque ça devient nécessaire.

Mais oué, je suis d'accord, le SQL pur c'est très bien pour renvoyer un fichier Excel, quand un vendeur demande combien de clients localisés dans le 57 ont commandé plus de 2000 dindes farcies d'un fournisseur moldave entre le 21 et le 23 décembre et quel a été le taux de retour. Et encore une fois, dans ma boîte il y a des gens spécialement payés pour ça. Moi je suis payée pour faire des applications rapides et maintenables et facile à comprendre quand une nouvelle personne intervient sur le code. Chacun son taf encore une fois...

[StringBuilder]

Justement, c'est là que les utilisateurs d'ORM n'ont rien compris.

Ce qui coûte cher dans un programme, c'est pas la construction des requêtes, c'est pas non plus le temps d'exécution de ces dernières, mais avant tout le temps nécessaire à déclencher la requête et attendre le retour.
Tout échange entre le programme et la base de données est extrêmement consommateur, autant au niveau CPU, mémoire que réseau... mais avant tout, temps !

Ainsi, quand on peut faire en une seule requête ce qu'un ORM va mettre 5 requêtes à obtenir, on est déjà au moins 5 fois plus rapide, 5 fois moins consommateur en mémoire, en CPU et en RAM.

Alors quand on fait un petit programme de quelques écrans utilisés par quelques personnes, c'est pas gênant.

Quand on fait un ERP qui va être utilisé par des centaines de personnes à travers toute la France, ou même des milliers à travers le monde entier, chaque Ko de consommé en trop par traitement, chaque milliseconde consommée de trop va faire la différence entre une application qui monte bien en charge et un truc qui s'effondre avec des performances lamentables.

Si on veut un programme performant, il faut penser performance au moment du design. L'optimisation, c'est pas des rustines qu'on ajoute par la suite quand les utilisateurs se plaignent.

Quant à la maintenabilité, entre une requête SQL et 5 appels à travers un ORM qui apporte son lot de limitations qui vont se traduire par du code supplémentaire dans le code, et une quantité supplémentaire de données chargées afin de faire des calculs que ne permet pas l'ORM, je fais mon choix tout de suite.

[Invité]

Pratiquement un truc faux par phrase...

Je vais commencer par l'un des derniers points : non, on ne pense pas optimisation avant tout, on pense à la robustesse et à la maintenabilité de l'application. Si problème de performance il y a (et j'insiste sur le si), on optimise ce qui a besoin d'être optimisé. C'est l'un des principes de base de la programmation, l'optimisation préventive est toujours source de problèmes.

Tu parles de déclencher plusieurs requêtes... euh non ? Ca reste le programmeur qui décide combien de requêtes l'ORM va exécuter. Parfois, mieux vaut tout récupérer d'un coup, d'autres fois plusieurs petites requêtes sont plus performantes. D'autre fois encore, on n'aura besoin d'une donnée que dans quelques pourcent des cas, il est donc plus économe de la récupérer en lazy load au besoin. Tu ne connais juste pas les ORM en fait...

"Quand on fait un petit programme utilisée par quelques personnes, ce n'est pas gênant...". Oui tu as raison, ça doit être pour ça que notre application Symfony est actuellement capable de gérer plus de 1000 utilisateurs concurrents avec un temps de réponse de moins de 100ms. Le jour où un seul serveur ne suffira plus, on en rajoutera, ça coûte toujours beaucoup, beaucoup moins cher de rajouter de la performance plutôt que de rajouter des devs pour maintenir une usine à gaz.

Tu oublies également que si dans certains cas, les performances de l'ORM sont insuffisantes, on peut toujours faire ses requêtes à l'ancienne. Mais c'est rarement le cas vu les mises en cache et autres optimisations mises en place par défaut dans les ORM.

Bref, tu n'as visiblement aucune expérience dans l'utilisation des ORM. Et quand on ne sait pas, on évite de donner son avis sur le sujet.

[vertex.3F]

Bonjour,

Je pense que ton analyse est biaisée à cause de cette phrase.
Évidement, que ne pas utiliser un ORM au profit de l'écriture de son propre ORM, ça n'a aucun sens. C'est comme dire "on ne peut pas se passer de voiture, car si on veut construire sa propre voiture c'est trop compliqué".

Un ORM n'a de sens qu'au niveau du développeur qui ne maîtrise rien de la couche de données : c'est un moyen de piloter la couche d'accès aux données sans avoir la moindre notion de SQL.

Cependant, pour le programme dans sa globalité, mise à part sur des projets très volumineux avec de nombreux développeurs qui ne maîtrisent pas tous la couche d'accès aux données, c'est plus un handicap qu'autre-chose :
- La plupart des opérations seront bien plus lentes
- Le code lui-même peut se trouver largement alourdi : là où une vue, requête SQL ou procédure stockée pourrait apporter un résultat complexe en une seule interrogation, un ORM peut demander une usine à gaz (par exemple interroger une table récursive)
- La méconnaissance de la couche de données des développeurs (qui sont souvent concepteurs) va souvent résulter en un modèle de données complètement bancal et des usines à gaz mise en places pour gérer des fonctionnalités pourtant simples à gérer en SQL

Bonjour Stringbuilder,

je suis entièrement d'accord, je reconnais volontiers que mes analyses sont biaisées ( https://fr.wikipedia.org/wiki/Biais_cognitif ), c'est pourquoi je suis davantage enclin à formuler mon opinion qu'à exprimer un avis catégorique.

Cela étant, cette opinion s'appuie sur mon expérience de développeur (c, c++, cobol, java, php, python) depuis de nombreuses années, avec et sans ORM. Je réalise d'ailleurs aujourd'hui, en écrivant ces lignes, le nombre considérable d'ORM qui ont été mis au point ( https://en.wikipedia.org/wiki/List_o...pping_software ), sans doute parce qu'un réel besoin existe et qu'un ORM tâche d'y répondre du mieux qu'il peut.

Pour mieux comprendre le point de vue que tu exprimes dans ce topic, pourrais tu STP décrire ta fonction actuelle et tes expériences personnelles avec les ORM ?

Merci
A bientôt

[SQLpro]

...notre application Symfony est actuellement capable de gérer plus de 1000 utilisateurs concurrents avec un temps de réponse de moins de 100ms. ....

Pour moi c'est lent…. Pour info, euridile (ancien nom du registre du commerce en ligne), traitait au début des données 2 000, avec une seule machine (SQL Server 2000) près de 30 000 connexions simultanées avec un temps moyens de requête inférieur à 30 ms...

A +

[Invité]

Le temps de requêtes sql moyen est de 20ms en mode dev

[escartefigue]

Dans la série, faites ce que je dis, mais pas ce que je fais

Je l'ai dit plus haut, je bosse sous MySQL, Postgres et Informix. Pour le reste, je n'ai pas envie de répondre à des insultes. De toute manière, quand on en vient aux insultes c'est généralement que l'on n'a pas grand-chose de pertinent à dire.

Tu dis ça parce que tu n'y connais rien et que tu es incompétent, d'ailleurs déclarer des fonctions dans des fonctions avec 35 callbacks imbriqués c'est le summum de l'élégance en programmation et tous ceux qui pensent le contraire sont des abrutis.

[Invité]

Ce n'est pas faute de l'avoir déjà dit mais la deuxième phrase était une imitation sarcastique de je ne sais plus quel membre qui soutient que si l'on n'aime pas JavaScript, c'est parce que l'on ne le comprend pas. D'ailleurs je me demande comment ça peut bien être pris au premier degré...

[deltree]

La fonction UDF, ça tombe bien, est requêtable.

Pas conséquent, on peut parfaitement gérer le order by lors de la construction du select final.
Quant au @min / @max, on peut parfaitement soit utiliser between isnull(@min, 0) and isnull(@max, 99999999999) directement dans l'UDF, ou plus proprement je pense, passer au paramètre des valeurs renseignées de ma même manière directement dans le code du programme :

pMin.Value = min.OrDefault(0);
pMax.Value = max.OrDefault(int.MAX_VALUE);

Bref, rien de plus compliqué.

Par contre, avec vos solutions ORM, on va rigoler quand il va falloir faire ce genre de comptages :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
select 
     country.continent,
     country.name pays,
     sum(city.population) * case when city.type = 'village' then 1 else 0 end paysans,
     sum(city.population) * case when city.type = 'village' then 1 else 0 end citadins,
     sum(city.population) population_totale,
     sum(city.population) over (partition by country.continent) population_continent
from 
country
inner join city on city.country_id = country.id
group by country.name

Et là on est dans du très simple.

en JPQL:

Code :

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

1
2
 
     Select city.coutry,city.type, count(city) from City c group by city.country, city.type;

ou pour le total de population :

Code :

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

1
2
 
     Select city.coutry,city.type, sum(city.population) from City c group by city.country, city.type;

Du reste je trouve que même en SQL on ne devrait pas tenter de transposer en colonne ce qu'on peut obtenir en ligne, globalement ce qu'on fait chaque fois qu'on utilise du "case when", on sort du paradigme SQL ensembliste standard.

[deltree]

Justement, c'est là que les utilisateurs d'ORM n'ont rien compris.

Ce qui coûte cher dans un programme, c'est pas la construction des requêtes, c'est pas non plus le temps d'exécution de ces dernières, mais avant tout le temps nécessaire à déclencher la requête et attendre le retour.
Tout échange entre le programme et la base de données est extrêmement consommateur, autant au niveau CPU, mémoire que réseau... mais avant tout, temps !

Ainsi, quand on peut faire en une seule requête ce qu'un ORM va mettre 5 requêtes à obtenir, on est déjà au moins 5 fois plus rapide, 5 fois moins consommateur en mémoire, en CPU et en RAM.
[...]

Et sur ce point ce que vous décrivez s'appelle la problématique "n+1". Il y a des solutions pour éviter cela, ça nécessite de maitriser l'orm (question que je pose souvent en entretien)

Je suis d'accord que d'un point de vue efficacité il faut viser des requêtes ORM qui permette d'avoir aussi peu de requête SQL que possible, idéalement les même que celles qu'on ferait manuellement.
Et comme je n'aime pas mélanger différents concepts dans la même réponse, je pourrais éventuellement parler de la nécessiter d'optimiser la totalité des requêtes, mais plus tard, c'est un autre débat.

[Dendrite]

Bonjour !

J'apporte mon petit grain de sel.
Je vois l'intérêt des couches, mais les surcouches, et les surcouches de surcouches... bof bof bof...

Cette mode des surcouches posent pour moi les mêmes problèmes que l'imbrication. Je préfère la juxtaposition à l'imbrication. En tant que développeuse web, je dois savoir quand je fais du SQL, rangé à un endroit, du PHP rangé à un autre, du HTML, de l'ajax etc.

A un moment, faut mettre les doigts dans le cambouis pour comprendre, et les doigts dans le SQL parfois. Et à un moment, le ticket d'apprentissage étant de toute façon cher, je préfère apprendre les fondamentaux que des surcouches temporaires qui bougent tous les 2 ans. Mais bon, c'est mon côté vieille bique sans doute.
SQL j'ai eu beaucoup de mal à y rentrer, mais je n'en sortirai pour rien au monde.

[Invité]

Mais c'est incroyable de lire et relire les mêmes banalités crasses sur le sujet. On n'utilise pas un ORM pour éviter d'avoir à apprendre le SQL, on utilise un ORM pour avoir du code propre, orienté objet, factorisé, maintenable