Discussion :

[SQLpro]

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

Cette base de données a t-elle été créée avec un outil de modélisation comme Power AMC ? qui permet (entre autres) :
- de documenter le modèle, y compris dans le SGBDR
- de valider un modèle pour éviter les grosses fautes
- de générer un dictionnaire des données

Donc vous utilisez une surcouche d'ORM et vous nous vantez ses qualité de lisibilité, alors que vous pourriez développer en code pur et de l'autre vous n'utilisez pas les bons outil pour structurez votre base et donc la rendre facilement compréhensible, et constatez que cet absence d'utilisation d'outil vous pénalise…

Un peu de bon sens !

A +

[Sodium]

Elle a 30 ans la BDD hein, on n'est pas une boîte d'informatique à la base, donc non tout n'a pas été fait dans les règles de l'art.

alors que vous pourriez développer en code pur

Ben oué je pourrais... tout comme je pourrait planter un clou en tapant dessus avec un caillou. Mais pourquoi m'infligerais-je ça alors qu'il existe des outils adaptés ?

Je pourrais aussi développer l'application en assembleur, mais la question reste pourquoi faire ? Ce n'est jamais que ça l'informatique hein, des couches et des couches et des couches qui finalement aboutissent à du code machine totalement incompréhensible pour un être humain. Le code de haut niveau est fait pour être lu par des humains, pas par des machines. Et le SQL, eh bien c'est dégueulasse à lire, (sans déconner, ces "CASE WHEN", omondieu), à écrire, et à générer. Un ORM c'est clair, standardisé, facile à lire et à apprendre. Je ne vois aucune raison valable de sans passer quand l'utiliser est possible.

[StringBuilder]

Et le SQL, eh bien c'est dégueulasse à lire, (sans déconner, ces "CASE WHEN", omondieu), à écrire, et à générer. Un ORM c'est clair, standardisé, facile à lire et à apprendre. Je ne vois aucune raison valable de sans passer quand l'utiliser est possible.

Ca c'est un point de vue purement subjectif et quelque peu de mauvaise fois.

Le SQL est le seul langage de haut niveau que je connaisse qui soit lisible (jusqu'à la norme SQL92 tout du moins) par une personne n'ayant pas la moindre connaissance informatique.
Seule une rapide explication sur l'algèbre ensembliste est nécessaire.

Tout le reste, c'est purement de l'anglais exprimé aussi simplement qu'il est possible…

Après, pour ce qui est des fonctions de fenêtrages et autres common table expressions, je veux bien accepté que ça se lise pas aussi simplement sans plus d'explication… mais ça reste toujours moins compliqué à lire que n'importe quel autre langage de programmation, qu'il soit objet ou non.

Quant au CASE WHEN que tu sembles avoir en horreur, il est justement là pour éviter d'interroger plusieurs fois successivement le SGBD afin d'obtenir le résultat désiré… ça permet juste de gagner en clarté dans le code appelant, et surtout en performances…

Il est toujours plus aisé de maintenir une seule requête SQL appelée par un bout de code que de maintenir 25 requêtes appelées dans 25 bouts de code imbriqués…

[StringBuilder]

Un ORM c'est clair

Surtout quand on n'a pas la moindre idée de ce qu'il fait derrière

standardisé

Peux-tu nous communiquer le numéro de la RFC qui défini le fonctionnement d'un ORM ?
Avec le nombre d'ORM divers et variés qui existent, j'aimerais bien voir où est la standardisation...

facile à lire et à apprendre

Comme tu le dis toi-même, utiliser un ORM ne dispense pas de connaître le SQL.
Donc facile ou pas, ça reste quelque chose de plus à apprendre.
Sachant qu'avec l'évolution des languages de programmation, les ORM évoluent très vite, et qu'il existe de nombreux ORM différents pour chaque langage, cela représente donc une quantité non négligeable de choses jetables à apprendre.
Le SQL, pendant ce temps, existe depuis plus de 30 ans, et la norme n'évolue que tous les 3 ou 4 ans (tout en étant parfaitement rétro-compatible : tous les SGBD savent faire tourner des requêtes SQL89, SQL92, SQL1999, etc. dans la mesure où ils implémentent correctement ces différents standards).

Je ne vois aucune raison valable de sans passer quand l'utiliser est possible.

Je vois plus de raisons de ne pas l'utiliser que de l'utiliser.

La seule "bonne raison" pour utiliser un ORM, c'est pour prototyper en quelques minutes une application, grâce aux fonctionnalités "code first".
Dans le même temps, cela va à l'encontre du B.A.BA de la conception, puisque si on veut avoir une application qui tiens la route, il faut modéliser la base en premier, donc le seule avantage peut vite s'avérer être un inconvénient si on ne jette pas le prototype à la poubelle au moment où on prend la décision d'aller plus loin.

[Sodium]

En fait ça serait bien que vous arrêtiez d'intervenir vous deux, car votre discours se limite à vous vautrer dans votre expertise auto-proclamée (sans déconner, à quel point faut-il être imbu de soi-même pour avoir la signature de SQLPro) pour décréter que les ORM c'est sale. Ca serait bien que l'on puisse discuter entre gens qui ont réellement des choses à dire sur le sujet au lieu de se limiter à du cétaimieuavan digne d'un bar de PMU

[Cincinnatus]

En fait ça serait bien que vous arrêtiez d'intervenir vous deux, car votre discours se limite à vous vautrer dans votre expertise auto-proclamée

Marrant, à ce niveau de lecture, je pensais que quelqu'un d'autre vous interpellait, @Sodium et @Stringbuilder (puisque intervenant juste avant)... Puisque vous devez représenter la majorité des posts sur cette discussion, et que vous ne parvenez pas à convaincre l'autre partie...

[blbird]

En fait ça serait bien que vous arrêtiez d'intervenir vous deux, car votre discours se limite à vous vautrer dans votre expertise auto-proclamée (sans déconner, à quel point faut-il être imbu de soi-même pour avoir la signature de SQLPro) pour décréter que les ORM c'est sale. Ca serait bien que l'on puisse discuter entre gens qui ont réellement des choses à dire sur le sujet au lieu de se limiter à du cétaimieuavan digne d'un bar de PMU

Sérieusement tu oses poster ça, toi qui à longueur de topic, que ce soit SQL ou JavaScript, te proclame "expert" sur ces sujets pour les juger définitivement, alors que ta seule "expertise" se résume à dire que tu n'aimes pas, et donc que c'est pourri?

Si tu n'es pas capable de comprendre, ce n'est pas une raison pour tenter de discréditer une techno ou les autres par tout les moyens dignes d'un guosse de 10 ans à longueur de posts. C'est d'un pénible, un avis "j'aime pas" suffirait, ensuite, comme tu n'y connais rien, il suffirait de te taire...

[Sodium]

Marrant, à ce niveau de lecture, je pensais que quelqu'un d'autre vous interpellait, @Sodium et @Stringbuilder (puisque intervenant juste avant)... Puisque vous devez représenter la majorité des posts sur cette discussion, et que vous ne parvenez pas à convaincre l'autre partie...

Par définition, on ne peut pas faire changer d'avis des gens qui ont une position dogmatique sur un sujet

[al1_24]

En effet, on a bien compris que tu ne changerai pas d'avis.

[Sodium]

Il n'y a pas de raisons pour que je change d'avis. J'ai apporté des arguments justifiant mon point de vue.

Les arguments des anti-ORM, c'est "MOA je fais de la base de données et donc JE sais que les ORM c'est de la merde, même si je n'en ai jamais utilisé". Ce n'est pas un argument, c'est de la rhétorique foireuse.

[blbird]

Les arguments des anti-ORM, c'est "MOA je fais de la base de données et donc JE sais que les ORM c'est de la merde, même si je n'en ai jamais utilisé". Ce n'est pas un argument, c'est de la rhétorique foireuse.

Tes participations sont exactement du même acabit : les SQL c'est pourri, mais je n'y connais rien. Même pas foutu de t'appliquer à toi-même les critiques que tu fais aux autres.

Quand à tes arguments, ils sont tout aussi foireux. Ton avis comparatif n'a ici aucun intérêt, car pour pouvoir comparer A et B jusqu'au point de dire que l'un est de la m**de par rapport à l'autre, encore faut-il un minimum connaître A ET B, ce qui n'est pas ton cas, tu le dis toi-même.

Si tu étais moins tranché et vindicatif dans tes avis sur les technos (et sur les autres), ca passerait mieux. Mais là, à force d'insister, tu passes du drôle au ridicule.

[soazig]

Bonjour,
Personnellement je fais de la base de données depuis quelques années, j'utilise entity framework (un ORM) depuis 4 ans quotidiennement, et quand j'espionne les requêtes générées par entity framework, j'ai parfois peur.
Exemple lorsque je veux récupérer de la table des utilisateurs, le nom, le prénom et le matricule, entity framework fait 3 jointures externe sur la table utilisateurs ce qui est à mon sens deux de trop.
Quand le nombre de colonnes récupérées est trop important, entity framework n'arrive plus à rajouter des jointures externes, seule solution que j'ai trouvé, faire une vue (oui le machin en SQL!).

Maintenant Sodium, je suppose que tu vas dire que 20 d'expériences donc 4 à utiliser entity framework font de moi quelqu'un de mauvaise foi, sans expérience sur les ORM.
bonne journée
Soazig

[Sodium]

Tes entités sont probablement configurées n'importe comment

[soazig]

Bien sûr, tout ce que tu fais est parfait, et si l'avis des autres est en contradiction avec le tien, c'est qu'ils ne sont pas compétents.
La conclusion est donc que je suis incompétente et que tu es compétent, pondéré et que tes arguments sont les meilleurs.
Bonne journée
Soazig

[Sodium]

Si ton ORM fait trois jointures là où une seule est nécessaire, c'est que soit il est pourri (je ne connais pas donc je ne vais pas me permettre de juger), soit que tu l'utilises mal

[CinePhil]

Bonjour,

Je ne vais pas répondre aux 11 pages que je viens de lire, seulement partager ma maigre expérience...

En préambule, je dirai que ma spécialité est plutôt la conception de BDD et que le langage avec lequel je suis le plus à l'aise, c'est le SQL.

Il y a quelques années, j'ai eu à utiliser Hibernate, puis Doctrine. Dans les deux cas, il m'a donc fallu apprendre une syntaxe nouvelle dérivée du SQL mais pas vraiment du SQL.

Tout allait bien quand il s'agissait de faire des requêtes simples.
Tout s'est compliqué douloureusement quand il s'est agi de faire une requête un peu complexe avec plusieurs jointures internes et externes.
J'ai souffert dessus pendant assez longtemps et j'ai appelé la communauté DVP à l'aide... sans grand succès... au point que j'ai fini par faire ma requête en SQL pur en 1/4 d'heure et à la balancer telle quel dans mon programme. Ça fonctionnait, c'était clair, concis.

Avec Hibernate et grâce à logForJ, j'ai aussi découvert que de nombreuses requêtes étaient générées inutilement, là où une seule requête aurait suffi.

Depuis, j'appelle les ORM des Objets Réellement Merdiques !

Et quand je vois les questions qui arrivent sur nos forums BDD ou PHP et qui sont liés à l'utilisation d'ORM, j'ai tendance à penser, comme d'autres ici, que les développeurs utilisant les ORM utilisent ça parce que ça reste dans leur domaine du développement logiciel et qu'ils ne font pas l'effort d'apprendre un minimum de SQL un poil évolué (jointures, groupages, fonctions de calcul...).

Il me sera facilement répondu par certain que moi non plus je n'ai pas fait l'effort d'apprendre les ORM, j'en conviens. Mais quand on passe des jours de souffrance sur une bête requête qui ne prend qu'un quart d'heure à écrire, on n'a pas très envie de souffrir davantage.


Un jour, j'ai lu l'article de SQLPro sur le développement en bases de données épaisses et ça m'a fichtrement intéressé.
J'ai d'abord découvert que l'ERP que nous utilisons avait initialement été développé un peu de cette manière (nombreuses procédures stockées), même si aujourd'hui il semble que les développeurs aient pris le pouvoir et que ça va s'orienter vers des choix techniques à mon avis dangereux... mais bon... c'est un autre sujet.

Puis, depuis quelques temps, j'ai enfin l'occasion de me mettre au développement en base de données épaisses.
Pour l'enregistrement des données mes requêtes SQL ne sont donc que des CALL telle_procédure_stockée (les, paramètres, demandés); et c'est la procédure qui s'occupe de contrôler la pertinence et la cohérence des données et de répartir celles-ci dans les bonnes tables.
Si je change mon modèle de données, je change la procédure mais pas les appels à la procédure (sauf si j'ajoute ou retire un paramètre à la procédure, bien entendu).
Dès qu'une interrogation de la BDD est un peu complexe (plusieurs tables à interroger), j'interroge une vue. Là encore, si je change mon modèle de données, je ne change pas forcément le résultat de la vue donc je ne change que la vue et les programmes qui utilisent la vue.

J'ai vu plus haut quelques exemples de codes taillés pour un ORM ou un autre. Ben je trouve souvent bien plus compréhensible une requête SQL que ces enchaînements de méthodes que, de toute façon, il a bien fallu écrire quelque part, parfois en tronçonnant inutilement un truc qui ne nécessite que quelques lignes de SQL.

Bref, personne ne m'a convaincu de tenter de nouveau l'expérience des ORM. D'ailleurs, je n'aime pas non plus beaucoup les "grands" frameworks que je trouve très compliqués à prendre en main et qui, quand on détaille ce qu'il font, charge une multitudes de classes avant de commencer à composer la page web ou l'écran, parfois simple, qui est demandé par l'utilisateur. C'en est au point que j'ai entrepris de développer mon propre framework qui, j'espère, restera simple et léger (voir les débuts sur mon blog, même si c'est loin d'être fini).

Conclusion et pour répondre à la question d'origine : je reste sur du SQL pur, en base de données épaisse.
Le SQL existera probablement toujours et restera robuste bien après ma retraite (dans quelques années). Les ORM, j'en suis moins sûr !

[Sodium]

Et quand je vois les questions qui arrivent sur nos forums BDD ou PHP et qui sont liés à l'utilisation d'ORM, j'ai tendance à penser, comme d'autres ici, que les développeurs utilisant les ORM utilisent ça parce que ça reste dans leur domaine du développement logiciel et qu'ils ne font pas l'effort d'apprendre un minimum de SQL un poil évolué (jointures, groupages, fonctions de calcul...).

Une chaîne SQL (comme toutes les chaînes de caractères), c'est super chiant à générer par programmation. Rien que ça justifie déjà l'utilisation d'un ORM

[StringBuilder]

Une chaîne SQL (comme toutes les chaînes de caractères), c'est super chiant à générer par programmation. Rien que ça justifie déjà l'utilisation d'un ORM

Renseigne-toi sur les bases de données épaisses avant de sortir des trucs pareils.

Le principe c'est justement de ne pas générer des requêtes SQL à la volée...

Quant à l'ORM, il fait de toute façon ce que tu n'aimes pas faire : générer une chaîne SQL, au détail près que dans 90% des cas si tu l'avais écrite toi-même, elle aurait été bien plus simple et performante.

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

[champomy62]

Ayant les 2 casquettes, DEV et architecte base de données je peux dire que je prends plus de plaisir avec SQL.


1. Vos competences acquises font de vous un expert. SQL est la depuis 40 ans et le restera encore longtemps. Les orms changent tout les 3/5 ans, sont instables et plutot complique a prendre en main.. Je ne dis pas que ca apporte pas de benefice dans le code mais faut faire un choix .. Si vous changez de langage vous allez devoir re-apprendre un nouveau framework. (.NET a python par exemple) alors qu'en SQL: bon les noms des fonctions peuvent changer mais pas dramatiquement (surtout si vous vous tenez au standard).

2. Ensuite je n'ai pas vu cet argument dans le thread. En enfermant la logique de requetage, la modelisation dans votre code, si vous devez creer d'autres applications qui voudront requeter cette DB, ils devront [les developpeurs] re-créer les requêtes, fonctions pour lire ou ecrire. C'est beau la duplication de code ? L'entreprise ou je travaille a plusieurs centaines de scripts dans differents langages (perl, bash, python, C), ca n'aurait fait aucun sens de devoir re-ecrire ce code SQL.