SQL est-il important si je connais bien les frameworks ORM? [fermé]

51

Je n'ai aucune expérience sérieuse en SQL et je déteste écrire SQL au lieu de LINQ. Je suis assez content des ORM.

Du point de vue des employeurs et du secteur, est-il important de connaître SQL? Dois-je maîtriser dessus? Les entreprises qui préfèrent le SQL pur aux frameworks ORM sont-elles un "dinosaure" dans le monde de la programmation?

sql orm entity-framework

— N'importe qui
source

14

Je me sens vieux. SQL a été suffisamment résumé pour que vous puissiez maintenant poser cette question sérieusement.

— Mark

11

@Mark: Peut-être pouvez-vous sérieusement poser la question, mais la réponse est toujours la même.

— Adam Robinson

30

Est-il toujours important de connaître l'arithmétique si je peux utiliser une calculatrice?

— Steven A. Lowe

4

NHibernate sans connaissance de SQL Profiler et comment se chatouiller le ventre pour utiliser JOIN, est un jihad de performance à attendre pour votre serveur de base de données

— Chris S

2

Devez-vous connaître le langage HTML si vous pouvez utiliser Dreamweaver?

— Tulains Córdova

63

C'est difficile à expliquer à beaucoup de programmeurs, car si vous ne connaissez que le SQL de base, cela ne vous donne vraiment pas un avantage considérable sur le béquille d'un ORM. Les concepts SQL les plus avancés, cependant, constituent une partie cruciale de la différence entre les applications qui fonctionnent simplement et les applications de haute qualité (en particulier, rapides et fiables).

Je suppose que quelqu'un d'autre conçoit les bases de données pour vous, parce que le faire sans savoir que le SQL est au-delà de tout ce qui est nécessaire . Mais même si vous ne vous développez que contre eux, voici une liste partielle de tout ce que les ORM ont encore tendance à faire mal ou pas du tout:

Requêtes récursives et / ou hiérarchiques
Paramètres optionnels (notamment leur traduction en prédicats d'intervalle)
Types de données définis par l'utilisateur
Types spécifiques à la plate-forme (hierarchyid et TVP SQL, tableaux Oracle et tableaux imbriqués, etc.)
Lots inserts / mises à jour / upserts / suppressions
Indices d'index
Astuces de verrouillage (en particulier les verrous de mise à jour et les lectures modifiées)
La gestion des erreurs
Jointures externes - leurs ensembles de résultats correspondent mal au modèle de POO, de nombreux ORM ont leur propre langage de requête, mais cela revient à connaître SQL lui-même;
Modularisation à l'aide de procédures stockées et de fichiers UDF, en particulier de fichiers UDF en ligne et de requêtes CROSS APPLY
Utilisation de OUTPUT / RETURNING pour le transfert de données dans plusieurs tables
Requêtes de pagination efficaces
Requêtes basées sur des fonctions de fenêtrage (rownum, rang, partitions)

La liste est encore longue: bon nombre de ces tâches n’ont jamais été confiées à un administrateur de bases de données débutant, et un développeur novice n’en a jamais entendu parler, mais elles sont très importantes dans les applications à grande échelle.

Les ORM sont vraiment efficaces pour accélérer le code SQL si ennuyeux - c'est-à-dire tous les codes CRUD et mappages et autres codes de plomberie répétitifs. Il n'y a donc aucune honte à les utiliser et à n'écouter personne qui dit qu'ils sont diaboliques. Mais vous devez absolument apprendre et même maîtriser le SQL, et vous préparer à passer aux commandes / requêtes de base de données brutes lorsque l'ORM ne fait pas le poids.

— Aaronaught
source

Je suis d'accord avec la plupart de vos points, mais en ce qui concerne les jointures externes: oui, elles correspondent mal à la POO, mais je pense que l'équivalent de la POO (par exemple, GroupJoindans LINQ) est bien meilleur.

— svick

@svick: Il a ses utilisations, mais ce n'est pas la même chose. Essayez d'émuler une jointure externe complète avec GroupJoin.

— Aaronaught

Oui, ce n'est pas la même chose. Et je pense que ce dont vous avez le plus souvent besoin est en fait un GroupJoin. C'est juste que les gens qui sont habitués à SQL pensent immédiatement à la jointure externe dans ces cas-là et demandent ensuite comment traduire cela en LINQ. Ce n'est pas la bonne approche. Vous ne devriez pas essayer de traduire votre SQL en LINQ, vous devriez traduire directement ce dont vous avez besoin.

— svick

@svick: Merci pour le tuyau. Je déteste me hisser au rang, mais après une interruption d'un an, je suis toujours l'un des principaux contributeurs à la fois pour SQL et Linq sur Stack Overflow. Je suis donc presque certain de comprendre la différence d'approche. Les jointures complètes sont rares, mais parfois, c’est ce dont vous avez besoin et il n’ya tout simplement pas d’analogue dans Linq. Il est assez désordonné et inefficace d'obtenir le même ensemble de résultats , quelle que soit sa structure .

— Aaronaught

Il semble que nous sommes réellement d'accord. Dans la plupart des cas, vous ne voulez pas réellement de jointure externe. Mais lorsque vous le faites, il est difficile de le traduire en LINQ.

— svick

90

Absolument! Le langage SQL est toujours la lingua franca des bases de données et, même si vous en faites beaucoup avec les ORM, vous devez comprendre le langage SQL pour comprendre les décisions que les ORM prennent et le code SQL qu’ils génèrent. En outre, il reste encore beaucoup à faire avec les procédures personnalisées SQL et stockées. Désolé, pas de repas gratuit.

— Otávio Décio
source

6

En effet. Vous devez par exemple connaître l'impact de différentes instructions de jointure et son impact sur les performances.

— Chiron

15

+1 Pas de repas gratuit! Qu'est-ce qui se passe avec toutes les questions qui demandent essentiellement si l'ignorance est acceptable?

— benzado

7

@benzado: Je ne pense pas que cela soit garanti pour SQL, mais vous devez choisir l'ignorance de certaines choses. il y a beaucoup trop de technologies (même les bonnes!) pour vraiment les connaître toutes. Donc je pense que c'est OK de demander "X est-il inutile si je connais vraiment bien Y ou si je fais Z?"

— Craig Walker

2

@Craig Je suis d'accord qu'il y a trop de choses à apprendre, mais un programmeur doit vraiment avoir une connaissance de base des niveaux inférieurs à ceux où il travaille.

— benzado

2

Les bases de données @Craig Walker constituent un savoir-faire essentiel pour la plupart des applications d'entreprise.

— HLGEM

25

Oui, vous devez toujours connaître SQL. Les ORM sont une abstraction très fuyante et ne donnent pas accès à toute la puissance de SQL. Pour les applications de jouets , vous êtes peut-être d'accord avec une connaissance limitée de SQL. Pour les applications d'entreprise, vous devrez comprendre la base de données pour obtenir des performances décentes de la part de l'ORM. En outre, de nombreuses tâches sont beaucoup plus faciles à accomplir avec SQL qu'avec un langage d'application. J'ai vu des programmeurs Java passer des jours à écrire du code pour faire quelque chose qui aurait pu être codé en SQL en une heure. La connaissance de SQL est très utile à quiconque écrit des applications utilisant une base de données relationnelle.

— Kevin Cline
source

14

La compétence SQL est une compétence incontournable de l'informatique aujourd'hui. LINQ est une technologie Microsoft Only. Les utilisations SQL vont au-delà du développement d'applications Web et client / serveur. Vous ne pouvez pas modéliser des bases de données et utiliser ETL si vous n’êtes pas doué avec SQL. Vous n'avez peut-être pas besoin de maîtriser les dialectes SQL utilisés dans ORACLE et SQL Server pour leurs produits Data Warehous, mais vous devez connaître le langage SQL standard. Les bases de SQL sont simples, il existe des tonnes de matériel pour vous aider à démarrer.

— Aucune chance
source

1

Quiconque connaît le fonctionnement de LINQ sera en mesure d'apprendre le SQL de base en une journée. C'est un argument terrible pour apprendre SQL.

— Boris Yankov

6

Si vous interagissez avec une base de données SQL, vous devez comprendre le code SQL généré par l'ORM. Vous devez comprendre les concepts inhérents aux bases de données SQL et comprendre ce que votre ORM ne peut pas faire pour vous. Les ORM facilitent la vie (et oui, je pense que travailler sans eux vous qualifie souvent de dinosaure), mais ce sont des outils (pour résumer des choses que vous connaissez), pas des béquilles (pour vous empêcher d’apprendre).

Si vous refusez d'apprendre le langage SQL, vous ne devez absolument pas toucher aux bases de données SQL, avec ou sans ORM, et vous devriez trouver un autre type de travail.

— Marnen Laibow-Koser
source

Bien que je sois d’accord pour dire que connaître le langage SQL est très utile - en principe obligatoire - je ne suis pas d’accord avec vos raisons. Avec ce raisonnement, vous devez connaître ASM et votre architecture de CPU avant d'écrire un programme, car les langages de haut niveau facilitent les choses, mais ce sont des outils (pour les choses abstraites). Si vous refusez d'apprendre les instructions et l'architecture de votre processeur, vous n'aurez aucune raison d'utiliser un ordinateur. <--- n'a aucun sens. La vraie raison pour laquelle vous en avez besoin est que les outils ORM en sont encore à leurs balbutiements. Je ne serais pas surpris si dans 5 à 10 ans la connaissance de SQL cessait d'être nécessaire

— Thomas Bonini

Les langages de haut niveau sont construits de manière à vous éviter d'avoir à connaître l'architecture sous-jacente, c'est vrai. C'est possible car le domaine est compatible avec l'architecture sous-jacente. Les ORM, cependant, sont une autre affaire. Je suis un grand fan des ORM, mais je ne pense pas qu'un jour viendra où vous pourrez en utiliser un sans connaître SQL (ou peu importe l'utilisation de la base de données sous-jacente). Les modèles objet et relationnel sont fondamentalement incommensurables, et je pense qu'il y aura toujours des concepts qui ne se traduiront pas. En plus, je parle des ORM d'aujourd'hui, pas de l'avenir

— Marnen Laibow-Koser

3

+1: "Si vous refusez d'apprendre le langage SQL, vous ne devez absolument pas toucher aux bases de données SQL, avec ou sans ORM, et vous devriez trouver un autre type de travail."

— Vecteur

2

Je reviendrais ceci un million de fois si je le pouvais. il y a beaucoup trop de gens qui n'ont rien à faire avec les bases de données SQL en raison de leur manque de compréhension générale et de leur manque de compréhension de ce qu'ils font. Ils font des ravages partout où ils vont en créant des énigmes de performances et en écrivant des rapports (fondés sur des décisions professionnelles) qui ont porté leurs fruits sans jamais s'apercevoir, car ils ignorent délibérément SQl, comme s'il s'agissait d'une sorte de badge d'honneur de détruire la base de données. c'est critique pour leurs applications.

— HLGEM

1

+1 pour "les outils (pour faire abstraction des choses que vous connaissez), pas les béquilles".

— Sholsinger

4

Je reconnais que je suis un inconditionnel de l'ORM et que je prêche les avantages de l'ORM depuis des années et que j'ai beaucoup à dire sur les raisons pour lesquelles l'ORM l'emporte sur SQL.

MAIS...

Je dois admettre que SQL est absolument nécessaire dans le monde réel et que tous les développeurs doivent bien comprendre SQL.

Les procs SQL sont plus rapides que l'ORM dans presque tous les cas. Même si vous pouvez être optimiste, la sortie de l'ORM dans la plupart des cas fait en sorte qu'elle arrive juste après les procédures SQL.

À l'occasion, vous avez besoin de SQL très résistant pour obtenir le résultat souhaité, et ces requêtes monstres sont plus faciles et plus rapides à créer dans les processus SQL.

Juste mes deux bits.

— SetiSeeker
source

4

Il viendra un moment où vous devrez optimiser quelque chose de complexe créé par l'ORM. À ce stade, vous avez généralement une requête extrêmement complexe à décomposer. Si vous n'avez jamais appris les bases, comment pouvez-vous espérer commencer à apprendre SQL avec les outils avancés? Vous ne comprendrez pas assez pour commencer même. ORMs entre les mains d'une personne qui comprend le langage SQL - un bon outil. Les ORM dans les mains de quelqu'un qui ne connaît pas du tout le langage SQL - un désastre imminent.

L'une des raisons pour lesquelles SQL est essentiel à la compréhension des bases de données est que les programmeurs d'applications ne pensent pas naturellement en termes de jeux de données. Mais la seule manière dont les bases de données fonctionnent efficacement est par jeux. Vous devez apprendre à penser en ensembles avant même d'essayer d'utiliser un ORM.

— HLGEM
source

3

Je me retrouve à forcer manuellement les requêtes dans les frameworks ORM le plus souvent. Et bien que la plupart aient leur propre langage de requête, ceux-ci sont tous inspirés de SQL, le code est transformé en SQL, et vous devez comprendre ce qui ne va pas en lisant ce SQL quand (pas si, quand) les choses tournent mal ou fonctionnent mal.
Ainsi, même si vous n’écrivez pas directement SQL, si vous comprenez bien au-delà d’un niveau élémentaire (vous n’aurez probablement pas besoin d’apprendre à écrire des procédures stockées, des déclencheurs, etc. si vous ne voulez accéder qu’à des bases de données). devrait connaître suffisamment la langue pour comprendre le code généré et le modifier au besoin.

— jwenting
source

3

Avant de parler de la question, une petite introduction d’abord; J'adore les ORM. Et je déteste le SQL. J'adore les ORM car ils cachent le gâchis hostile à l'utilisateur qu'est SQL et constituent un moyen agréable de gérer la base de données avec un langage intégré.

Cependant, je dois admettre que SQL présente de nombreux avantages, le plus important étant la précision. Je peux assez bien discuter de la complexité d'une requête SQL sans avoir une connaissance détaillée du schéma de base de données sous-jacent, simplement en parcourant la requête. Par conséquent, lorsque j'utilise SQL, je suis toujours alerte et j'ai toujours l'intuition de savoir où va la complexité d'un composant.

D'autre part, lorsque j'utilise des ORM, je suis tellement impressionné par la facilité d'intégration de la base de données que j'oublie littéralement qu'il existe même une base de données. Cela m'a vissé plusieurs fois. Dans le passé, j'ai souvent appelé des méthodes ORM d'apparence innocente, appelées dans les coulisses des jointures de bases de données massives et effrayantes, qui détruisent les performances.

C'est pourquoi pour moi, la vérité est quelque part entre les deux. J'aime utiliser les ORM, et je vais continuer à le faire, mais je dois faire plus attention et toujours étudier les implications (au niveau SQL) de tout appel de méthode ORM. Connaître les implications d'une couche d'abstraction est de l'or pur dans cette entreprise, et justifie l'utilisation de l'abstraction. Tout le reste, c'est comme se tirer une balle dans le pied.

— Charalambos Paschalides
source

3

Je pense aussi que parfois (même avec du SQL normal) les gens oublient que le simple fait de renvoyer un jeu de données ne signifie pas qu'il s'agit du bon jeu de données. Je pense que cela devient plus facile à oublier avec un ORM quand vous supposez que c'est ce qui est correct car vous ne comprenez pas vraiment ce qu'il a fait de toute façon.

— HLGEM

Je suis en désaccord sur ORM étant moins complexe que SQL. Avec SQL, vous pouvez récupérer des données sans programmation. SQL n'est pas un langage de programmation, mais un langage déclaratif. Il n'a donc pas de structure while, for ou if-then.

— Tulains Córdova

1

Un langage de programmation déclaratif est toujours un langage de programmation. SQL est un langage de programmation à usage spécifique, et oui, il est déclaratif pour la plus grande partie. Quant à la viande de votre commentaire, je ne comprends pas. SQL n’est pas un langage de programmation général, mais reste un langage. Vous devez toujours connaître la syntaxe, ses limites et ses défauts.

— Charalambos Paschalides

2

Si tout ce dont vous avez besoin est d'interagir avec la base de données uniquement avec l'application que vous créez, vous n'en avez probablement pas besoin. Dans certaines petites entreprises ou équipes de développeurs, vous devrez peut-être vous aider. Il est beaucoup plus facile de se connecter à la base de données d'un client et d'exécuter quelques instructions SQL pour voir ce qui se passe avec leurs données.

— JeffO
source

Qui doit interagir avec la base de données UNIQUEMENT via l'application qu'il est en train de créer?

— Tulains Córdova

2

Même avec un bon ORM mature, vous allez inévitablement rencontrer des situations dans lesquelles il émettra du SQL inefficace et vous facilitera grandement la vie si vous pouvez saisir ce qui se passe dans le SQL généré. Cela dit, si vous êtes très compétent avec l'ORM et savez comment utiliser un profileur pour votre base de données de choix, vous pouvez très facilement "simuler jusqu'à ce que vous le fabriquiez".

1

La réponse à tous ces types de questions ("Dois-je savoir X?") Est "apprends-le la première fois que tu en as besoin, si jamais tu en as besoin".

Cependant, il est important de ne pas tomber dans le piège de faire les choses moins efficacement, car vous n'êtes pas au courant ou n'êtes pas disposé à apprendre le moyen efficace de les faire.

Dans ce cas particulier, par exemple, que faites-vous si vous vous rendez compte qu’un bogue dans votre programme rendait PostCountparfois le champ de votre table utilisateur inexact.

Vous corrigez le bogue et vous devez maintenant mettre à jour le PostCount pour tous les utilisateurs. Comment faites-vous?

Si vous écrivez un petit script en utilisant ORM pour le faire, vous êtes très inefficace; une requête SQL très simple fera l'affaire.

Comme ces situations sont assez courantes, je crains que vous ne tombiez dans le piège décrit ci-dessus!

— Thomas Bonini
source

2

Je suis d'accord: si vous ne connaissez pas SQL, vous écrivez souvent des dizaines de lignes de code pour faire ce que vous auriez pu faire avec une seule requête SQL.

— benzado

2

re "apprenez-le la première fois que vous en avez besoin": ro-che.info/ccc/11.html

— MatrixFrog

1

Oui, vous avez toujours besoin de SQL.

Ne sautez pas à l’hypothèse que quelque chose de "vieux" est en quelque sorte indigne de considération. Les technologies dites "traditionnelles" sont celles qui existent encore après avoir résisté à l'épreuve du temps. Nous n'appelons pas les ordinateurs Wang «hérités», ils ont échoué et sont partis.

Si vous me demandez si cela me gêne que ma banque utilise probablement COBOL sur un ordinateur central, ou IBM i? Absolument pas. Ce sont des technologies solides, éprouvées et vraies. Devinez quoi, ils utilisent principalement DB2 SQL. Je suis beaucoup plus heureux de faire confiance à mon argent là-bas qu'avec un logiciel développé dans un langage à la mode du mois.

Les dinosaures ont duré sur cette terre beaucoup plus longtemps que nous, les humains. Et si vous lisez Jurasic Park (oui, les livres sont meilleurs que les films), alors je vous demande si vous voulez vraiment affronter une meute de velociraptors hyper-malins ou un T-Rex obstiné qui n'abandonne jamais? Ne soyez pas mordu en sous-estimant les "dinosaures". ;-)

— WarrenT
source

0

Hormis les jeux et la recherche (principalement statistique), pour laquelle je n’ai aucune expérience, il semble que l’accès aux bases de données et leur fonctionnement soient l’un des rares domaines dans lesquels de mauvaises décisions ont de très lourdes répercussions sur les performances. Je crois fermement en des abstractions de base de données plus puissantes dans le code, et je crois en linq, qui relie les opérations de la base de données au langage de programmation, en vous donnant tous les outils du langage (vérification de type, vérification de la syntaxe, tout ce qui vous plait votre langage de programmation) tout en vous donnant tout le pouvoir de faire ce que vous voulez est absolument fantastique. Malheureusement, cela ne fonctionne toujours pas toujours. Cela signifie que si la couche d'abstraction obtient ses optimisations erronées, vous risquez d'attendre des secondes au lieu de microsecondes, ou des minutes au lieu de secondes pour votre résultat. Comme ce sont des moments très remarquables, vous devez les optimiser, sinon votre application ne fonctionne pas: les performances deviennent le plus gros problème de votre application. Cela signifie que vous devez vous rapprocher du métal et optimiser à la main.

Lorsque nous en arrivons au point que manipuler de grands ensembles de données prend par exemple 3 ms lorsque vous le faites à la main, et 100 ms lorsque vous laissez la couche d'abstraction le faire pour vous, laissez-la bien gérer par la couche d'abstraction, car vous pourriez être 30 fois plus lent, mais vous êtes toujours (probablement pour la plupart des applications) assez rapide. La réalité de la situation est toutefois que lorsque vous recherchez des solutions optimisées avec un temps de réponse de 200 ms et que la couche d’abstraction le traite pour vous, l’algorithme prend «juste» 10 fois le nombre de performances, vous avez un 2 secondes de retard, puis vous vous souciez énormément, car cela ne va pas très vite, mais devient extrêmement lent. Constatant que les solutions de bases de données relationnelles ne sont pas adaptéesJe ne pense pas que cela sera résolu d’ici deux ou trois ans. Cela signifie que vous aurez encore besoin de passer au vase nu pendant un certain temps lorsqu'il s'agira de bases de données plus volumineuses, ou votre application sera si lente qu'elle ne pourra pas résister à la concurrence.

— Martijn
source