Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Affichage des résultats du sondage: Êtes-vous pour l'utilisation d'un ORM (mapping objet-relationnel) ? Pourquoi ? Partagez vos avis

Votants
107. Vous ne pouvez pas participer à ce sondage.
  • Oui

    57 53,27%
  • Non

    48 44,86%
  • Pas d'avis

    4 3,74%
Sondage à choix multiple
  1. #21
    Membre éclairé
    Homme Profil pro
    Ingénieur en génie logiciel
    Inscrit en
    juin 2012
    Messages
    386
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Canada

    Informations professionnelles :
    Activité : Ingénieur en génie logiciel
    Secteur : Finance

    Informations forums :
    Inscription : juin 2012
    Messages : 386
    Points : 851
    Points
    851

    Par défaut

    Citation Envoyé par max2148 Voir le message
    La réponse n'est pas binaire.
    L'ORM est portable entre SGBD (apres est ce que l'on change souvent de SGBD ?), simplifie grandement la maintenance et les accès.
    pour les fonctions les plus basiques oui...

    chaque bd a des types de données différentes et des fonctionnalités différentes qui ne sont pas nécessaire pris en compte par un orm, par exemple un hstore de postgres n'existe pas dans les autres bd... pour pouvoir l'utiliser dans jpa, beaucoup de code a été nécessaire pour que ça puisse fonctionner
    Aillez le courage de justifier vos -1.
    http://www.laboiteaprog.com/ - http://www.solutions-norenda.com/

  2. #22
    Membre extrêmement actif Avatar de Sodium
    Homme Profil pro
    Développeur Web
    Inscrit en
    avril 2014
    Messages
    1 360
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Belgique

    Informations professionnelles :
    Activité : Développeur Web

    Informations forums :
    Inscription : avril 2014
    Messages : 1 360
    Points : 1 753
    Points
    1 753

    Par défaut

    Citation Envoyé par marc.collin Voir le message
    il est question ici de valider ce que le orm génère comme requête et non de factorisation.
    Valider ce que l'orm génère comme requête.... je n'ai pas compris.

    Citation Envoyé par marc.collin Voir le message
    Pas besoin d'un orm pour faire ça... spring-data en est la preuve
    Ce que je montre là c'est la couche controller, ensuite bien entendu tu as ce qui se passe derrière ces fonctions qui fait appel à l'orm, et bien entendu il y a la facilité de traiter les données retournées, notamment pour les relations.

  3. #23
    Rédacteur
    Avatar de SQLpro
    Homme Profil pro
    Expert SGBDR & SQL, spécialiste Microsoft SQL Server
    Inscrit en
    mai 2002
    Messages
    18 821
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert SGBDR & SQL, spécialiste Microsoft SQL Server
    Secteur : Conseil

    Informations forums :
    Inscription : mai 2002
    Messages : 18 821
    Points : 44 019
    Points
    44 019

    Par défaut

    Citation Envoyé par marc.collin Voir le message
    … par exemple un hstore de postgres n'existe pas dans les autres bd...
    Si, dans SQL Server via les tables In Memory et l'indexation ColumnStore….

    A +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Enseignant CNAM PACA - ISEN Toulon - CESI Aix en Provence * * * * *

  4. #24
    Membre expérimenté
    Profil pro
    Inscrit en
    octobre 2005
    Messages
    858
    Détails du profil
    Informations personnelles :
    Âge : 39
    Localisation : France

    Informations forums :
    Inscription : octobre 2005
    Messages : 858
    Points : 1 317
    Points
    1 317

    Par défaut

    J'utilise moi-même Hibernate, et je vois des avantages et inconvénients dont personne n'a parlé.

    Ce qui me manquerait le plus sans Hibernate, ce sont les chargements paresseux. Un gain de performance appréciable, mais complexe à coder soi-même. Hibernate le fait automatiquement.

    Ce qui ne me manquerait pas, ce sont les problèmes de compatibilité avec d'autres librairies. Hibernate utilise des proxies qui affolent les librairies utilisant l'introspection de code, par exemple Jackson. Dans le cas de Jackson il existe un plugin, encore faut-il le savoir.

    En parlant de Jackson, celui-ci possède des fonctionnalités appréciables permettant au développeur de gérer manuellement les cas complexes. Ça manque à Hibernate, et contourner un bogue peut être difficile.

    Un problème récurrent que je vois avec les ORM est la façon de les aborder. M. Bendersky semble attendre de l'ORM qu'il permette de s'abstraire entièrement de la base de données sous-jacente et de traiter les données comme si elles étaient en mémoire vive. C'est trop en demander. Les ORM permettent d'économiser du code répétitif, point. Ils ne permettent absolument pas de ne pas savoir utiliser une base de données relationnelle et de ne pas utiliser SQL. Si on les utilise en connaissance de cause, ils sont très utiles.

    Je dois admettre que mon expérience est à 99% sur Hibernate, donc d'autres développeurs ont peut-être une expérience différente.

  5. #25
    Membre éclairé
    Profil pro
    Inscrit en
    novembre 2009
    Messages
    345
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations forums :
    Inscription : novembre 2009
    Messages : 345
    Points : 677
    Points
    677

    Par défaut

    1) En 25 ans de carrière je n'ai jamais rencontré un défenseur des ORM qui connaissait vraiment bien SQL.

    2) "Les ORM sont bien pour les requêtes de base."
    Ok admettons. Et? Dans la vraie vie d'un vrai système complexe les requêtes de base représente quelle partie du temps de développement par rapport à celui des requêtes complexes?
    S'encombrer de la lourdeur d'un ORM pour ça...

    3) Les ORM rendent indépendants de la base de données.
    Non. Les ORM rendent dépendants de l'ORM !!
    Ce qui est bien pire.
    Ce qui rend indépendant de la base de données c'est justement SQL.
    Si votre couche d'accès est complètement en SQL dans la DB (procédures stockées), vos couches d'accès (qui peuvent être multiples!) sont indépendantes et interchangeables!

    3A) Oui mais quid changement de base de données?
    Dans la vraie vie changer de base de données se passe moins souvent que le changement de technologie qui s'addressent à la DB.
    Et faire passer du SQL d'une DB à l'autre, même si ce n'est pas automatique n'est pas la fin du monde (de DB2 windows à oracle en 2001 à DB2/400 en 2003 à SQL Server en 2016. Sans souci.

  6. #26
    Membre extrêmement actif Avatar de Sodium
    Homme Profil pro
    Développeur Web
    Inscrit en
    avril 2014
    Messages
    1 360
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Belgique

    Informations professionnelles :
    Activité : Développeur Web

    Informations forums :
    Inscription : avril 2014
    Messages : 1 360
    Points : 1 753
    Points
    1 753

    Par défaut

    Citation Envoyé par frfancha Voir le message
    1) En 25 ans de carrière je n'ai jamais rencontré un défenseur des ORM qui connaissait vraiment bien SQL..
    Un peu comme les gens qui considèrent que coder avec autre chose que VIM est une hérésie...

    C'est sûr que quand on a 25 ans d'expertise dans un domaine, et qu'on a arrêté de se tenir à jour niveau technos parce qu'au bout d'un moment marre quoi, il faut bien justifier cette expertise et le chèque qui va avec.

  7. #27
    Membre éclairé
    Profil pro
    Inscrit en
    novembre 2009
    Messages
    345
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations forums :
    Inscription : novembre 2009
    Messages : 345
    Points : 677
    Points
    677

    Par défaut

    Citation Envoyé par Sodium Voir le message
    C'est sûr que quand on a 25 ans d'expertise dans un domaine, et qu'on a arrêté de se tenir à jour niveau technos parce qu'au bout d'un moment marre quoi, il faut bien justifier cette expertise et le chèque qui va avec.
    Je sais pas. Peut-être que tu as raison que je devrais arrêter de me tenir à jour.
    En attendant toute l'interface est en vue.js - asp.net core 3 preview 5 - les appels à la DB passent les rows aux procédures stockées en JSON en SQL Server 2016, etc, etc, ...
    Mais bon tu as raison c'est du vieux brol.
    Vivement la retraite.

  8. #28
    Membre éprouvé

    Profil pro
    Conseil - Consultant en systèmes d'information
    Inscrit en
    février 2004
    Messages
    614
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : Conseil - Consultant en systèmes d'information

    Informations forums :
    Inscription : février 2004
    Messages : 614
    Points : 1 271
    Points
    1 271

    Par défaut

    Citation Envoyé par frfancha Voir le message
    1) En 25 ans de carrière je n'ai jamais rencontré un défenseur des ORM qui connaissait vraiment bien SQL.

    2) "Les ORM sont bien pour les requêtes de base."
    Ok admettons. Et? Dans la vraie vie d'un vrai système complexe les requêtes de base représente quelle partie du temps de développement par rapport à celui des requêtes complexes?
    S'encombrer de la lourdeur d'un ORM pour ça...

    3) Les ORM rendent indépendants de la base de données.
    Non. Les ORM rendent dépendants de l'ORM !!
    Ce qui est bien pire.
    Ce qui rend indépendant de la base de données c'est justement SQL.
    Si votre couche d'accès est complètement en SQL dans la DB (procédures stockées), vos couches d'accès (qui peuvent être multiples!) sont indépendantes et interchangeables!

    3A) Oui mais quid changement de base de données?
    Dans la vraie vie changer de base de données se passe moins souvent que le changement de technologie qui s'addressent à la DB.
    Et faire passer du SQL d'une DB à l'autre, même si ce n'est pas automatique n'est pas la fin du monde (de DB2 windows à oracle en 2001 à DB2/400 en 2003 à SQL Server en 2016. Sans souci.
    Alors là, que dire de plus, tout est dit. Je confirme complètement via ma aussi très longue expérience sur plusieurs plateforme (J2EE et M$) : je n'aurais pas dit mieux.

  9. #29
    Membre expérimenté
    Profil pro
    Inscrit en
    février 2004
    Messages
    1 798
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : février 2004
    Messages : 1 798
    Points : 1 478
    Points
    1 478

    Par défaut

    J'ai toujours galéré avec les ORM et je pense qu'il n'y a aucun sens à vouloir transformer un modèle relationnel en modèle objet et inversement.

    Plus haut ça parle de conception de base de données. Un ORM prend également en considération sa consistance.

    Par exemple, une table de droits, une table d'utilsateur et une table affectant les droits d'un utilisateur sur un autre (ce serait des groupes ou peut n'importe, ça ne changerait rien). Lorsqu'un utilisateur 1 a des droits sur un utilisateur 2 et que l'utilisateur 2 en a sur l'utilisateur 1. Par exemple "tu as le droit de voir mes trucs et moi j'ai le droit de voir et modifier tes trucs". L'ORM va vite partir en référence circulaire.

    Et là il faut jouer avec du depht ou rendre des propriétés protégées pour ne pas les inclure mais dans un autre cas on en aura besoin et ça part très vite en bricolage.

    Pour les mises à jour aussi ce n'est pas terrible. Il faut aller chercher un objet, modifier ce que l'on a besoin de modifier, puis l'enregistrer. Ça en fait des échanges alors qu'un UPDATE est bien plus simple.

    Pour des requêtes un peut complexe, soit on passe son temps à détourner l'ORM pour réutiliser son pool de connectivité interne, soit il faut en créer un autre, donc deux gestion à mettre en place.

    Aussi, il n'y a pas d'ORM qui sort du lot, donc aucune capitalisation de compétence / connaissance à en retenir, donc aucun intérêt de dire qu'on a 3 ans d'XP sur tel ou tel ORM. Mieux vaut dire que l'on en a 3 en SQL.

    Donc la promesse de gagner du temps en code produire par l'abstraction de ce qu'il y a derrière ne peut être tenue. Au contraire ça ne fait que rendre les choses plus obscures, donc plus coûteuses.

    Avoir des gros pavés SQL dans le code n'est pas génial non plus, car on veut aller à l'essentiel de ce que ça fait et pas comment ça le fait. Ce que j'ai fait c'est mettre mes requêtes SQL dans des fichiers avec un petit loader qui fixe les paramètres nécessaire pour charger le fichier et exécuter la requête. Ainsi le code reste propre, lisible et avec ai milieu truc léger, tout con et réutilisable.

    Ce que j'aimerais c'est approfondir GraphQL, avec génération et surveillance du schéma, ça ferait déjà un truc en moins à penser / maintenir. Ce qui me freine c'est qu'ils ont leur propre syntaxe de requête à mettre dans des chaînes de caractères. Ce serait du JSon permettant ainsi d'utiliser les linter, d'échapper les variables et ainsi de garder un code propre, ça serait super bien. Après je n'ai que survolé, j'espère avoir prochainement le temps de m'y intéresser de plus prêt.

    Toujours est-il que ce qui est sûr, c'est qu'un dev qui manipule de la data doit savoir comment elle est organisée pour être efficace dans sa manipulation
    "Heureusement qu'il y avait mon nez, sinon je l'aurais pris en pleine gueule" Walter Spanghero

  10. #30
    Membre extrêmement actif Avatar de Sodium
    Homme Profil pro
    Développeur Web
    Inscrit en
    avril 2014
    Messages
    1 360
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Belgique

    Informations professionnelles :
    Activité : Développeur Web

    Informations forums :
    Inscription : avril 2014
    Messages : 1 360
    Points : 1 753
    Points
    1 753

    Par défaut

    Citation Envoyé par mister3957 Voir le message
    Avoir des gros pavés SQL dans le code n'est pas génial non plus, car on veut aller à l'essentiel de ce que ça fait et pas comment ça le fait. Ce que j'ai fait c'est mettre mes requêtes SQL dans des fichiers avec un petit loader qui fixe les paramètres nécessaire pour charger le fichier et exécuter la requête. Ainsi le code reste propre, lisible et avec ai milieu truc léger, tout con et réutilisable.
    Là tu ne fais jamais que bricoler une ébauche d'ORM simplifiée...

  11. #31
    Membre éclairé
    Homme Profil pro
    Ingénieur en génie logiciel
    Inscrit en
    juin 2012
    Messages
    386
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Canada

    Informations professionnelles :
    Activité : Ingénieur en génie logiciel
    Secteur : Finance

    Informations forums :
    Inscription : juin 2012
    Messages : 386
    Points : 851
    Points
    851

    Par défaut

    Citation Envoyé par BugFactory Voir le message
    J'utilise moi-même Hibernate, et je vois des avantages et inconvénients dont personne n'a parlé.

    Ce qui me manquerait le plus sans Hibernate, ce sont les chargements paresseux. Un gain de performance appréciable, mais complexe à coder soi-même. Hibernate le fait automatiquement.
    et génère des requêtes supplémentaire
    Aillez le courage de justifier vos -1.
    http://www.laboiteaprog.com/ - http://www.solutions-norenda.com/

  12. #32
    Membre expérimenté
    Homme Profil pro
    Développeur .NET
    Inscrit en
    février 2007
    Messages
    784
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 34
    Localisation : Canada

    Informations professionnelles :
    Activité : Développeur .NET

    Informations forums :
    Inscription : février 2007
    Messages : 784
    Points : 1 401
    Points
    1 401

    Par défaut

    C'est assez drole ce genre de news car on peut sortir a peu pres n'importe quel argument, sans etude, sans contexte et essayer d'en faire une generalite.

    Etant donne que chaque orm a ses specificites, il faudrait savoir de quoi l'on parle: un micro orm type dapper, ou un monstre type hybernate/jpa/entity framework ?

    Meme question pour les sgbd, on attaque pas de la meme maniere un sqlite qu'une base oracle.

    Mais avant ca il faut parler du scope du projet, du contexte, des contraintes et fonctionnalites, du volume de donnees.

    Enfin il faut ajouter l'experience de l'equipe de dev, si c'est un projet long terme, le turnover de la societe et la politique de la boite.

    Une fois seulement on peut commencer a parler choix et consequences:
    • Utiliser un orm sur on projet .net core qui aura une duree de vie d'un an c'est correct.
    • Si le projet consiste majoritairement a faire des imports de donnees csv, l'orm sera plus un frein qu'un apport.

  13. #33
    Membre éclairé
    Homme Profil pro
    Ingénieur en génie logiciel
    Inscrit en
    juin 2012
    Messages
    386
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Canada

    Informations professionnelles :
    Activité : Ingénieur en génie logiciel
    Secteur : Finance

    Informations forums :
    Inscription : juin 2012
    Messages : 386
    Points : 851
    Points
    851

    Par défaut

    Citation Envoyé par SQLpro Voir le message
    Si, dans SQL Server via les tables In Memory et l'indexation ColumnStore….

    A +
    désolé, pas vraiment la même chose...
    Aillez le courage de justifier vos -1.
    http://www.laboiteaprog.com/ - http://www.solutions-norenda.com/

  14. #34
    Membre expert
    Avatar de Pyramidev
    Homme Profil pro
    Développeur
    Inscrit en
    avril 2016
    Messages
    922
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Développeur

    Informations forums :
    Inscription : avril 2016
    Messages : 922
    Points : 3 953
    Points
    3 953

    Par défaut

    Citation Envoyé par mister3957 Voir le message
    Aussi, il n'y a pas d'ORM qui sort du lot, donc aucune capitalisation de compétence / connaissance à en retenir, donc aucun intérêt de dire qu'on a 3 ans d'XP sur tel ou tel ORM. Mieux vaut dire que l'on en a 3 en SQL.
    Dans quel(s) langage(s) travailles-tu ?
    En Python, en dehors des projets avec Django, je crois que c'est SQLAlchemy qui sort du lot.

  15. #35
    Membre confirmé

    Homme Profil pro
    Ingénierie logistique
    Inscrit en
    janvier 2013
    Messages
    247
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Ingénierie logistique
    Secteur : Transports

    Informations forums :
    Inscription : janvier 2013
    Messages : 247
    Points : 647
    Points
    647

    Par défaut

    Topic à troll ? ze relational-object impedance mismatch : ;
    Empreinte PGP - pool.sks-keyservers.net : 5589 3CA6 6518 1E59 9FCA A48D 2B11 B467 46B3 1D66
    Je suis les règles de Crocker.

  16. #36
    Membre expert
    Avatar de GLDavid
    Homme Profil pro
    LIMS manager, bio/chemoinformatique
    Inscrit en
    janvier 2003
    Messages
    2 723
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    Localisation : France, Seine Saint Denis (Île de France)

    Informations professionnelles :
    Activité : LIMS manager, bio/chemoinformatique
    Secteur : Industrie Pharmaceutique

    Informations forums :
    Inscription : janvier 2003
    Messages : 2 723
    Points : 3 725
    Points
    3 725

    Par défaut

    Bonjour

    Pour moi, réponse de normand: tout dépend de la question à laquelle vous devez répondre.
    Si vous devez développer une application qui doit interroger différentes bases de données, alors SQL est votre ami.
    Vous devrez toujours interroger la même base de données en entreprise, alors un ORM peut être la solution.

    J'étais beaucoup dans le premier cas à utiliser des requêtes SQL. Et je me rend compte qu'en réalité j'étais plus dans le 2ème cas: à taper toujours dans la même base mais finalement à recréer un miniORM. Alors, franchissons le pas. Pour une appli d'entreprise et de reporting, un ORM est parfait. Cela simplifie le développement et les performances ne sont pas impactées.
    Néanmoins, j'ai opté pour un ORM concernant le développement d'un microservice. Et j'avais l'impression d'utiliser une bombe atomique pour tuer un moustique. Oui, des requêtes SQL eussent (corrigez moi si je me trompe) été mieux, mais j'avais aussi dans la tête un besoin d'évolution et de flexibilité et la souplesse d'un ORM n'est pas à remettre en question.

    Just my 2 cents,

    @++
    GLDavid
    Consultez la FAQ Perl ainsi que mes cours de Perl.
    N'oubliez pas les balises code ni le tag

    Je ne répond à aucune question technique par MP.

  17. #37
    Membre extrêmement actif Avatar de Sodium
    Homme Profil pro
    Développeur Web
    Inscrit en
    avril 2014
    Messages
    1 360
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Belgique

    Informations professionnelles :
    Activité : Développeur Web

    Informations forums :
    Inscription : avril 2014
    Messages : 1 360
    Points : 1 753
    Points
    1 753

    Par défaut

    N'oublions pas que les coûts matériels pour rattraper une perte de performance sont pratiquement toujours mineurs par rapport à ceux engendrés par un code de mauvaise qualité qui nécessitera plus de maintenance.

  18. #38
    Membre éprouvé Avatar de Cincinnatus
    Homme Profil pro
    Développeur Java
    Inscrit en
    mars 2007
    Messages
    386
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Nord (Nord Pas de Calais)

    Informations professionnelles :
    Activité : Développeur Java
    Secteur : Service public

    Informations forums :
    Inscription : mars 2007
    Messages : 386
    Points : 1 017
    Points
    1 017

    Par défaut

    Citation Envoyé par mister3957 Voir le message
    J'ai toujours galéré avec les ORM et je pense qu'il n'y a aucun sens à vouloir transformer un modèle relationnel en modèle objet et inversement.

    Plus haut ça parle de conception de base de données. Un ORM prend également en considération sa consistance.

    Par exemple, une table de droits, une table d'utilsateur et une table affectant les droits d'un utilisateur sur un autre (ce serait des groupes ou peut n'importe, ça ne changerait rien). Lorsqu'un utilisateur 1 a des droits sur un utilisateur 2 et que l'utilisateur 2 en a sur l'utilisateur 1. Par exemple "tu as le droit de voir mes trucs et moi j'ai le droit de voir et modifier tes trucs". L'ORM va vite partir en référence circulaire.

    Et là il faut jouer avec du depht ou rendre des propriétés protégées pour ne pas les inclure mais dans un autre cas on en aura besoin et ça part très vite en bricolage.
    Est-ce un problème de données ou d'application ? Rien compris à l'exemple.
    Quel rapport entre des droits (dans une table) et une référence circulaire ? Là, c'est la requête, via ORM ou en SQL natif, qui est, pour rester correct, à refaire.

  19. #39
    Membre expérimenté
    Profil pro
    Inscrit en
    février 2004
    Messages
    1 798
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : février 2004
    Messages : 1 798
    Points : 1 478
    Points
    1 478

    Par défaut

    Citation Envoyé par Sodium Voir le message
    Là tu ne fais jamais que bricoler une ébauche d'ORM simplifiée...
    Bah non puisque l'on a le contrôle de la requête pour aller chercher ce dont en a besoin et surtout comment. Et ça n'a rien à voir avec le fait de chercher à transformer un schéma relationnel en schéma objet.
    "Heureusement qu'il y avait mon nez, sinon je l'aurais pris en pleine gueule" Walter Spanghero

  20. #40
    Membre extrêmement actif Avatar de Sodium
    Homme Profil pro
    Développeur Web
    Inscrit en
    avril 2014
    Messages
    1 360
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Belgique

    Informations professionnelles :
    Activité : Développeur Web

    Informations forums :
    Inscription : avril 2014
    Messages : 1 360
    Points : 1 753
    Points
    1 753

    Par défaut

    Avec un ORM aussi tu peux avoir un contrôle total sur ta requête. Dans 95% des cas celui-ci n'est pas nécessaire, mais il existe.
    Il faut arrêter avec les parodies d'informaticiens, la majorité de nos requêtes ce sont des requêtes simples, pas des monstres avec 10 jointures et 15 sous-requêtes.

Discussions similaires

  1. Réponses: 4
    Dernier message: 05/09/2016, 14h39
  2. Réponses: 5
    Dernier message: 22/03/2006, 14h54
  3. Réponses: 5
    Dernier message: 20/10/2005, 10h42

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo