Discussion :

[SQLpro]

...SQL est un langage primitif, verbeux, inélégant, déconnecté de la programmation objet et difficile à générer par programmation. C'est un langage très vieux ....

Tant de bêtise en si peu de mots... C'est tragique ! D'autant que GOOGLE vient d'annoncer un nouveau langage pour le parcours des tables de graphes... GQL. Quelques extraits de l'annonce :

"
Neo4j, un fournisseur de bases de données orientées graphes, a annoncé ce mardi que les comités internationaux qui développent le standard SQL ont voté en faveur de la création de GQL (Graph Query Language) comme nouveau langage de requête pour ce type de base de données.
"

Tiens, tiens, c'est le comité de normalisation du SQL qui va normaliser le GQL et sans doute l'intégrer à SQL !

" « Nous sommes parvenus à un équilibre en lançant GQL, le langage de requête de base de données du futur, tout en préservant la valeur et l'ubiquité du SQL. Notre comité a été encouragé de voir une forte participation de la communauté internationale à l'inauguration du projet GQL. Un tel soutien est la marque d'une norme émergente », a déclaré Keith Hare, qui est actif dans le processus des normes SQL depuis 1988 et qui préside le comité international des normes SQL pour les langages de base de données depuis 2005. "

Ha oui, le SQL est vieux, mort pourri et il n'évolue pas ??? (dixit sodium....)

"
Le projet GQL lancera le développement de la prochaine génération de normes technologiques pour l'accès aux données, optimisées pour le monde actuel des données connectées. Sa charte s'appuie sur les fondements de base déjà établis par SQL et sur une collaboration continue pour assurer la compatibilité et l'interopérabilité SQL et GQL.
"

mais c'est donc exactement le contraire !

CQFD.

A +

[Sodium]

Allez, histoire de remettre de l'eau au moulin

http://sametmax.com/les-critiques-de...-de-la-plaque/

[SQLpro]

Bien plus intéressant :
https://www.yegor256.com/2014/12/01/...i-pattern.html
https://www.developpez.com/actu/7961...t-pas-exister/

https://medium.com/building-the-syst...s-190add65add4

https://fr.slideshare.net/alimenkou/...rnate-12998784

http://www.sickenger.com/2013/02/11/...-just-stop-it/

Perf :
http://www.diva-portal.org/smash/get...983/FULLTEXT02

Dans cet article, très intéressant :
https://enterprisecraftsmanship.com/...u-need-an-orm/
Il est dit :
"
ORMs are often taken as a replacement for the necessity to learn SQL, as well as various pitfalls you may run into with relational databases. That’s a false perception.

When using an ORM, you still need to know how a database works and you still need to learn how to code in SQL. An ORM is a supplement for your SQL skills, not a replacement for them.
"

Les ORM sont souvent considérés comme substitut de la nécessité d'apprendre le langage SQL, ainsi qu'aux différents pièges que vous pouvez rencontrer avec des bases de données relationnelles. C’est une fausse perception.

Lorsque vous utilisez un ORM, vous devez toujours savoir comment fonctionne une base de données et apprendre à coder en SQL. Un ORM est un complément à vos compétences SQL, pas un remplacement pour eux.

Alors la question finale se pose ainsi : si je maîtrise SQL ais-je besoin de l'ORM ?


A +

[Sodium]

Les ORM sont souvent considérés comme substitut de la nécessité d'apprendre le langage SQL, ainsi qu'aux différents pièges que vous pouvez rencontrer avec des bases de données relationnelles. C’est une fausse perception.

Lorsque vous utilisez un ORM, vous devez toujours savoir comment fonctionne une base de données et apprendre à coder en SQL. Un ORM est un complément à vos compétences SQL, pas un remplacement pour eux.[/B]

Yep, c'est ce que tu radotes en boucle depuis une dizaine de pages on a compris

Btw je fais du SQL quotidiennement, notamment pour sortir des statistiques sur notre base produits. De ton côté, tu codes du logiciel tous les combien de temps exactement ?

Alors la question finale se pose ainsi : si je maîtrise SQL ais-je besoin de l'ORM ?

On te l'a déjà dit 300 fois : unification et ré utilisabilité du code entre les projets, facilité d'intégration de nouveaux devs dans une équipe, propreté du code, centralisation de la logique de l'application, et pour moi l'un des plus importants, l'élégance de l'architecture du programme.

Quant au fait que SQL soit encore très utilisé, ce n'est pas un argument. Les drivers et autres micrologiciels nécessitant énormément de performances sont toujours écrits en C. Un paquet de programmes utilisés par les banques tournent toujours en Cobol. La majorité des applications de ma boîte sont en Delphi 7. Pour une application normale et récente, un ORM est la bonne solution.

Mais bon, je n'ai pas d'espoir que tu finisses par le comprendre, étant de un profondément imbu de toi-même, de deux visiblement totalement incompétent lorsque l'on sort du champ de la base de données pure.

[Pyramidev]

https://medium.com/building-the-syst...s-190add65add4

Je recopie un beau raisonnement à côté de la plaque :

Code Python :

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

email = User.find(id=1).email

OK, that was easy. I just needed to get the User object by id then retrieve its email.

Now, try answering these questions:

• Was a database connection open when executing that line of code or was it open at a previous time?
• Are we using a connection from a database connection pool?
• How much data did we retrieve from the database?
• Do we need all the data retrieved from the database?
• Is that line of code fetching data from the database or is it accessing an internal cache?
• If there is a cache, when is it going to be refreshed?
• Does that line of code automatically commit to the database?

From reading that single line of code, I am unable to answer any of those questions.

Now, let’s try answering the previous questions with this code:

Code Python :

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

1
2
3
4
5
conn = psycopg2.connect('postrges://...')
with conn.cursor() as cur:
    conn.execute('SELECT email FROM users WHERE id=1')
    email = conn.fetchall()
conn.commit()

This snippet of code is more challenging to create because it requires understanding what we are doing. But, it is a lot simpler than the previous “one-liner”.

From the new code, we can answer all of the questions.

Sauf que, quand on cherche à écrire du code lisible et maintenable, on décompose le code en plusieurs niveaux d'abstraction. Par exemple, on décompose des fonctions en sous-fonctions. En particulier, si on écrivait ce bout de code avec conn.cursor(), on le rangerait dans une fonction, par exemple avec un nom du genre get_email_from_user_id. Dans mon exemple, admettons que get_email_from_user_id soit une méthode d'une classe UserStore.
Quand on lit email = user_store.get_email_from_user_id(1), on comprend tout de suite la logique métier, mais on ne sait répondre à aucune des questions sur l'implémentation. Il faut descendre dans le code source de get_email_from_user_id pour le savoir, et c'est normal.
Et comme un code qui contiendrait plein de fonctions du genre get_email_from_user_id sans passer par un ORM aurait beaucoup de répétitions, pour factoriser et standardiser ça, on a des abstractions qui s'appellent des ORM.
Du coup, dans le cas où on passe par un ORM, pour savoir si le programme lit un cache interne, quelle requête SQL il génère, etc. eh bien, à la place d'étudier chaque code verbeux des fonctions du genre get_email_from_user_id, il faut étudier l'ORM.
Je ne connais pas tous les ORM, donc peut-être que certains sont mal documentés et donc qu'il est compliqué de savoir comment ils se comportent même après les avoir étudiés. Mais alors il s'agirait d'un défaut de certains ORM individuels et non pas du concept de l'ORM en lui-même.

[deltree]

eux.[/B]

Alors la question finale se pose ainsi : si je maîtrise SQL ais-je besoin de l'ORM ?


A +

Oui

d'autre questions?
A+

[Sodium]

Difficile d'avoir une vision d'ensemble objective quand on se limite à un seul aspect d'un problème et que l'on est totalement incompétent en ce qui concerne le reste. Oui, le SQL est sûrement ce qu'il y a de mieux... quand on ne fait que du SQL

[escartefigue]

Difficile d'avoir une vision d'ensemble objective quand on se limite à un seul aspect d'un problème et que l'on est totalement incompétent en ce qui concerne le reste.

Raisonnement applicable aux objecteurs comme aux supporters des ORM : 1 partout, balle au centre
De toutes façon, ça n'est pas grave, il y a plusieurs pages déjà que le match est... nul !

[SQLpro]

Difficile d'avoir une vision d'ensemble objective quand on se limite à un seul aspect d'un problème et que l'on est totalement incompétent en ce qui concerne le reste. Oui, le SQL est sûrement ce qu'il y a de mieux... quand on ne fait que du SQL

Ma petite SODIUM au lieu de raconter des conneries sur mon compte, vous vous rendriez plus intelligente en tournant 100 fois la plume dans votre encrier, avant de critiquer les personnes. Une attaque personnelle, même à mot couvert, reste une sorte de diffamation, et c'est puni par la Loi…

Que savez vous de moi sur ma compétence en matière autre que le SQL comme vous l'affirmez de manière péremptoire ?

Donc je vous prie de cesser ces attaques personnelles qui, non seulement vous discrédite mais encore vous font passer aux yeux de tous pour une personne incompétente, de mauvaise foi et incapable de la moindre critique (intégriste en somme)…

Je n'ai bien évidement pas à me justifier auprès de vous de mes compétences…. Elles ne concerne que les clients qui me font confiance et me payent, d'ailleurs fort cher pour m'avoir, et mon carnet de commande est plein jusqu'en 2020.
En ce moment même je suis à Prague en temps que conseil pour une solution d'architecture applicative concernant la gestion des documents d'identité d'un état souverain de la CEE…..

A +

[Sodium]

Oui oui je sais, c'est bien pour ça que je disais qu'il suffit de regarder votre signature pour comprendre que vous êtes une personne profondément imbue d'elle-même (à votre place j'augmenterais encore un peu la taille de police, ça fait un peu léger là)

Et ce ne sont pas les menaces à la diffamation qui vont me faire peur

Bref, je pense qu'on peut conclure de la façon suivante : en développement (et beaucoup d'autres domaines), quand une personne vous dit de ne jamais faire ou utiliser quelque chose, ayez le réflexe de mettre en doute ses compétences, car une personne compétente est apte à peser les pour et contre d'un choix de manière pratique et non dogmatique.

[CinePhil]

Oui oui je sais, c'est bien pour ça que je disais qu'il suffit de regarder votre signature pour comprendre que vous êtes une personne profondément imbue d'elle-même

... dit celle qui depuis des pages et des pages ne cesse de se prétendre experte en ORM pour justifier son amour inconditionnel envers et contre tous les arguments qui ont pu lui être retournés...
Bref...

en développement (et beaucoup d'autres domaines), quand une personne vous dit de ne jamais faire ou utiliser quelque chose, ayez le réflexe de mettre en doute ses compétences

... dit celle qui depuis des pages et des pages nous dit qu'elle connait peu le SQL...

Bref...

[Sodium]

Je n'ai jamais prétendu être une experte en ORM ni ne jurer que par eux, il s'agit juste d'une solution élégante aux problèmes rencontrés dans la plupart des projets lorsqu'il s'agit de gérer des données en ayant un code le plus court possible dans les méthodes ayant besoin de manipuler des données. Il ne s'agit jamais que de factorisation. J'ai fait de même lorsqu'il s'agit de manipuler des images avec ImageMagick qui est une usine à gaz, une librairie avec 2-3 méthodes publiques accessible et qui gère toute la logique de manière transparente à un endroit. Je pense que la vraie bonne solution serait que les connecteurs aux bdds disposent d'une API à l'usage similaire à un ORM aboutissant à une requête optimisée. Il y a certainement sur d'autres forums des gens qui ne jurent que par le fait de ne l'utiliser qu'en ligne de commande en connaissant par coeur ses 3 millions de paramètres. Ca ne va pas m'empêcher de dormir pour autant.

Ce n'est pas non plus parce que je ne suis pas une experte en SQL que je ne sais pas l'utiliser, j'avais d'ailleurs à une époque écrit mon propre ORM et il ne m'est jamais arrivé de ne pas parvenir au résultat voulu. Je passe juste plus de temps dans la doc que ceux en faisant un usage intensif et me porte très bien comme ça. J'aime le code élégant et le SQL est l'inverse d'un code élégant, je n'ai donc pas de motivation particulière à y passer plus de temps que nécessaire, je préfère travailler mes compétences en langages et architecture de code. Chacun son truc.

[CinePhil]

J'aime le code élégant et le SQL est l'inverse d'un code élégant

C'est TON opinion !

Le SQL se lit comme une phrase :
Sélectionne ces colonnes
depuis cette table
jointe à telle autre sur telle condition de jointure
où telle condition sur les valeurs est respectée
avec les lignes groupées sur tel critère
ayant les groupement répondant à telle condition
et le tout ordonné selon tel ordre.

[Sodium]

Ca, c'est une manière élégante de faire une jointure :

Code :

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

return $this->hasMany('App\Comment');

[Cincinnatus]

[QUOTE=Sodium;11154888]Ca, c'est une manière élégante de faire une jointure :

ça, c'est ton opinion.

[MaitrePylos]

Un ORM , m'apporte une certaine vitesse de codage.
Par exemple ceci est rapide et clair pour moi :

Code php :

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

1
2
3
4
 
Attributions::where('directeur', '=', session('name'))
            ->where('annee', '=', $annee_academique)
            ->delete();

Mais même pas question d'essayer de transformer ceci en ORM

Code sql :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
WITH zoe(abreviation,dixieme,compteur) as(
                    select abreviation,sum(hrs_dixieme) as dixieme,count(hrs_dixieme)
                    from validation
                    where abreviation in (select abreviation from validation where lower(type_miss) like '%autre%')
                    group by abreviation
                )
                select z.abreviation,z.dixieme,(z.dixieme*0.2) as pourcent ,v.hrs_dixieme,z.compteur
                from zoe z
                inner join validation v
                    on v.abreviation = z.abreviation
                where lower(v.type_miss) like '%autre%'
                group by z.abreviation
                having z.hrs_dixieme > pourcent and compteur > 1

Oui je sais je sois encore l'optimiser.

[Cincinnatus]

Effectivement, on retrouve là l'utilisation optimale des outils. Et pour cela, il faut bien connaître et autant que possible maîtriser l'ensemble.
Les ORM sont utiles pour les requêtes simples, CRUD, le SQL étant quant à lui inégalable pour les requêtes complexes.

[Sodium]

Code sql :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
WITH zoe(abreviation,dixieme,compteur) as(
                    select abreviation,sum(hrs_dixieme) as dixieme,count(hrs_dixieme)
                    from validation
                    where abreviation in (select abreviation from validation where lower(type_miss) like '%autre%')
                    group by abreviation
                )
                select z.abreviation,z.dixieme,(z.dixieme*0.2) as pourcent ,v.hrs_dixieme,z.compteur
                from zoe z
                inner join validation v
                    on v.abreviation = z.abreviation
                where lower(v.type_miss) like '%autre%'
                group by z.abreviation
                having z.hrs_dixieme > pourcent and compteur > 1

Oui je sais je sois encore l'optimiser.

Oh le beau code imbuvable (SQL en général, pas le tiens). Rien qui ne différencie réellement les variables de la logique, il faut lire ligne par ligne ou même bloc par bloc pour comprendre ce qu'il se passe, se souvenir de quel alias fait référence à quoi...

Je ne vois pas vraiment en quoi le fait que le SQL "se lise comme du texte" est un avantage. Qu'est-ce qui est le plus rapide à comprendre, "Toto ramasse une pomme et va dans la cuisine" ou "$toto->take('apple')->goto('kitchen')" ?

[SQLpro]

Histoire de mettre un peu d'huile sur le feu… Quelle est l'empreinte écologique d'une solution via ORM comparée avec une solution en code pur ?
Evidemment, je pense que cela ne vas pas du tout dans le sens de l'ORM vu les multiples couches à traverser d'une part, la non intelligence d'un ORM d'autre part qui nivèle vers le bas l'écriture des requêtes SQL afin de miser sur le plus petit dénominateur commun…

Il est vrai que écologie et informaticien font assez peu bon ménage. La stratégie depuis quelques années (voir quelques décennies) est de miser sur le muscle plus que sur le cerveau… Les architectures avec un nombre effroyable de serveur en parallèle (scale out) alors que l'on pourrait souvent mutualiser en scale up (ma favorite étant la scale up milanaise... ! ) semble être à la mode… Bilan écologique catastrophique !!!

Il y a peu une étude classait le langage Python comme le plus mauvais en terme écologique… c'est évidemment le plus populaire actuellement chez les geek, attirés par la nouveauté comme les mouches par la merde !

Il y a quelques années, un de mes amis (?) se vantait, une fois acquise sa retraite d'IBM, d'être devenu subitement écologique…. Tout de même ce que c'est que d'être bobo ! Et il m'envoyait régulièrement de multiples emails enluminés d'html… Un jour je lui ait répondu que je ne me vantais pas d'être écologique, mais qu'au moins mes emails étaient rédiger en texte pur… Depuis il ne m'envoi plus aucun email….

Mon job d'audit de performances et d'expertise des solutions tournant autour des bases de données est paradoxalement un but écologique… La plupart des solutions au problème de "comment faire plus rapide" n'est pas de rajouter du matériel... C'est une courte vue ! Mais bien de dégraisser le code, de se débarrasser des verrues, pas seulement des ORM d'ailleurs…

A +

[SQLpro]

Oh le beau code imbuvable (SQL en général, pas le tiens).

Encore une fois une opinion personnelle qui n'a rien à faire sur ce forum… Placé dans un forum sur la mode ou le design ta remarque aurait sa place…

Pour info je suis l'auteur d'un cours SQL pour non informaticien que j'ai démarré il y a près de 20 ans et vendu il y a un peu plus de 10 ans à Orsys.
https://www.orsys.fr/Formation/SIF
C'est devenu un best seller, tant il est facile pour un non informaticien de lire un tel code qui sont de simples phrases….
Si c'était aussi imbitable que tu le prétends, alors personnes n'irait a ce cours et il aurait été retiré du panel Orsys qui compte plus de 1000 formations rien que sur le domaine high tech...

A +