Y a-t-il encore un besoin d'écrire du SQL?


12

Avec autant d'outils ORM pour la plupart des langages modernes, existe-t-il encore un cas d'utilisation pour écrire et exécuter SQL dans un programme, dans un langage / environnement qui les prend en charge? Si oui, pourquoi?

Pour plus de clarté: je ne demande pas si les programmeurs doivent connaître SQL ou si je dois avoir un outil SQL sur mon bureau. Je demande spécifiquement pourquoi je pourrais l'avoir dans le code (ou la configuration, ou autre) par opposition à un ORM.


Un ORM peut-il gérer des requêtes dynamiques? Je sais que vous pouvez modifier les clauses where sans trop de problème (dans la plupart des ORM). Mais y en a-t-il un où vous pouvez modifier l'intégralité de l'instruction SQL à la volée? Je connais quelques utilisations où cela serait impuissant et où le sql brut serait probablement plus facile à gérer.
Tony

réponse courte, OUI.
gabe.

Réponses:


35
  • Vous êtes plus à l'aise pour écrire SQL pour interroger des données que pour écrire du code procédural.
  • Votre ORM, bien que beau à regarder, génère un SQL horriblement lent dans certains domaines critiques.
  • Vous devez profiter des fonctionnalités exposées par votre SGBDR qui ne sont pas / ne peuvent pas être mises à disposition via votre ORM.
  • Chaque fois que vous tapez SELECT * FROM..., Dieu tue un chaton. Et vous détestez les chatons.
  • Vous n'utilisez pas d'ORM, de POO ou de langue moderne.

8
Toutes bonnes raisons. L'efficacité serait pourtant mon numéro un. Dans certaines situations, un ORM comme vous l'avez dit génère du SQL qui peut être optimisé à la main et affiné.
Chris

20
Si je sais déjà ce que je veux dire en anglais, pourquoi devrais-je écrire le français et le passer dans une boîte noire qui le traduira en anglais? Je préfère de beaucoup l'écrire moi-même avec éloquence au lieu de manipuler le français dans l'espoir qu'il crée le bon anglais.
Mike M.

8
die kitty die !!
jellyfishtree

3
Je parle le français et l'anglais nativement. L'analogie est très bonne: vous pouvez porter le message principal, mais des nuances subtiles seront perdues. Des nuances subtiles sont parfois plus importantes, car elles agissent comme un langage corporel pour indiquer des positions tacites. Je préfère écrire du SQL.
Christopher Mahan

2
Mis à part les abstractions qui fuient, les gens semblent oublier que la plupart des ORM ont de nombreux avantages par rapport aux requêtes SQL simples: cache de premier et deuxième niveau, chargement paresseux (avec un chargement enthousiaste étant une option afin d'éviter le problème N + 1) et pouvoir unir -tester la couche d'accès aux données (en changeant le SGBD pour une base de données en mémoire), pour n'en nommer que quelques-uns ...
rsenna

15

Écrire du SQL complexe

Les ORM sont parfaits pour les choses de base. Cependant, pour les situations complexes, vous devrez écrire SQL.

Bref, il y a certainement un besoin de SQL et il le restera toujours.


1
J'ai récemment réécrit le projet d'un collègue. J'ai remplacé 9 de ses projets C # (qui comprenaient 2 couches d'accès aux données) par un seul script SQL de 150 lignes. L'exécution du projet (qui importait des données de SchemaLogic dans le service de métadonnées gérées de SharePoint 2010) prend désormais 3 minutes au lieu de 15. La version SQL est tellement plus rapide et plus courte qu'elle n'est même pas drôle à distance.
Ant

Cent pour cent d'accord. Pour les applications commerciales réelles pour toute grande institution, des situations complexes se produisent toujours.
Rick Henderson

10
  • Vues
  • Déclencheurs
  • Contraintes
  • Packages (SSIS, DTS, etc.)
  • Chaque fois que vous devez contrôler avec précision le flux d'exécution

ORM ne vous aide pas à créer, régler ou automatiser la base de données. Cela vous donne simplement un autre moyen d'interagir avec la base de données une fois que vous avez fait tout cela.


Je suis d'accord, mais la question est de savoir s'il doit y avoir du SQL dans mon code C # (par exemple), pas de savoir si le travail de base de données doit être fait. ORM mentirait sur la plupart de ces trucs.
C. Ross

@c. Ross Oui, et ce n'est certainement pas le cas commun, j'ai eu des raisons de construire / modifier / analyser toutes ces choses par le biais de code à des moments de ma carrière. Si vous n'avez aucune raison de faire ces choses dans le code, vous ne le faites pas, mais je ne connais pas d'ORM qui fasse un très bon travail sur les opérations de schéma. Le contrôle précis du flux d'exécution est un cas plus courant pour la plupart des gens, mais il y a des cas où cela n'est pas nécessaire également. Vous avez également raison de penser qu'un ORM peut se trouver au-dessus, et je pense que cela est vrai dans beaucoup de ces cas tant que vous ne modifiez pas suffisamment le schéma pour irriter l'ORM.
Bill

4

Sûr:

  • Généralement, ORM encapsule beaucoup, mais à la fin, vous devez savoir ce qui se passe dans les coulisses. Ceci est crucial pour les performances et l'évolutivité. Bien qu'à l'intérieur de l'application, je n'écris pas beaucoup de SQL mais je sais à peu près à quoi ressemble le SQL ou DDL.
  • Direct SQL est souvent agréable pour écrire des requêtes en lecture seule. Il est beaucoup plus facile de le formuler dans le langage de requête ORM et vous pouvez également limiter le jeu de résultats (par exemple, "sélectionner l'identifiant dans .....").
  • ORM ne devrait pas du tout vous éloigner de SQL. J'utilise beaucoup SQL pour les requêtes ad hoc directement sur le client DB (comme mysql-client). Il vous offre une très belle interface uniforme et des fonctionnalités de regroupement.

4

Les ORM existent en raison de l'inadéquation de l'impédance entre nos implémentations de bases de données relationnelles communes et nos fonctionnalités de langage OO. Ils ne sont qu'un pont, mais la plupart des gens traitent SQL comme le fromage Limburger dans le réfrigérateur.

Si vous pouvez à juste titre dire que vous utiliserez toujours votre ORM ou une autre couche d'accès aux données abstraites au lieu de traiter SQL / procédures stockées / vues comme une ou des interfaces de première classe, alors vous feriez probablement mieux sans toucher à SQL.

En pratique, je n'ai jamais vu de projet pur-ORM ne nécessitant pas au moins SQL pour interroger la base de données pour la validation finale.


3

Les ORM sont un outil de la boîte à outils des programmeurs. Ils ont leurs propres problèmes. Certains exemples sont:

  • Impossible de contrôler SQL
  • Souffre d'un problème n + 1

2
Qu'est-ce que le "problème N + 1"? Je ne suis pas familier ...
RationalGeek

Je pense que c'est ça: stackoverflow.com/questions/97197/…
Axe

2
Je ne suis pas sûr d'être d'accord. Un bon ORM devrait vous permettre d'exécuter du SQL brut lorsque cela est nécessaire, et les problèmes N + 1 sont généralement des erreurs de débutant (par exemple, des boucles imbriquées sur des collections chargées paresseusement) qui peuvent être facilement évitées.
richeym

@richeym: Ceux où les premières choses me sont venues à l'esprit. L'autre réponse me soutient cependant. Le fait est qu'un ORM n'est qu'un outil, il y a des cas où le SQL brut est préféré.
Tony

3

Si vous savez ce que vous faites, vous pouvez utiliser efficacement un ORM pour remplacer une grande partie de votre code de type CRUD. Cependant, ils ne sont pas aussi efficaces pour les choses complexes, ils sont difficiles à régler (vous savez que les performances sont l'une des parties critiques de la conception de la base de données, pas d'émulation d'objets) et elles sont carrément horribles et dangereuses entre les mains de quelqu'un qui ne le fait pas. ne comprends pas ou n'écrit pas SQL lui-même

Je tiens également à souligner qu'il n'est pas facile de faire efficacement des rapports complexes avec un ORM. Et de plus, si vous n'apprenez pas le SQL simple dans les trucs faciles, comment arriverez-vous au point où vous pourrez écrire du SQL complexe pour le reporting? Je n'ai jamais travaillé dans une application qui n'avait pas de besoins de reporting et souvent assez compliquée.

Les ORM ne sont pas non plus utiles pour la plupart des processus BI ou ETL. Ils ne sont pas non plus utiles pour les requêtes d'administrateur de base de données ou pour trouver des informations dans les tables d'audit et annuler un ensemble particulier de modifications de base de données. Il y a beaucoup de choses qui sont encore plus efficaces avec SQL. L'application interrogeant la base de données est une petite partie de ce qui doit l'interroger dans un environnement d'entreprise.

Je vois également de nombreuses questions sur la façon de faire quelque chose à l'aide d'un ORM que l'affiche sait déjà faire en SQL. C'est agréable d'apprendre de nouvelles choses, mais quand elles génèrent du temps et des efforts supplémentaires sans réel gain par rapport à la méthode originale (et souvent une réelle perte de performances), pourquoi les utilisez-vous autrement qu'elles ne sont "à la mode" en ce moment.


2

Parfois, un client veut juste une requête rapide et facile pour renvoyer des données pour un rapport, une exportation, un vidage de données, etc. et veut attendre qu'un programme entier soit développé.

De plus, un bon programmeur SQL peut toujours écrire du SQL plus rapide et plus efficace que n'importe quel ORM que j'ai utilisé. De plus, j'ai trouvé que beaucoup de gens ont juste le point ORM vers des procédures stockées - ignorant vraiment les avantages des ORM car les ORM ne sont pas parfaits pour les processus complexes.

De plus, lorsque vous utilisez une base de données comme Oracle avec un langage de procédure très riche et puissant, vous pouvez faire beaucoup sans jamais avoir besoin d'un "programme". PL / SQL sur Oracle dans les bonnes mains est très rapide et efficace.


1
PL / SLQ signifie "langage procédural / langage de requête structuré", alors comment est-ce que ce n'est pas un "programme"?
Christopher Mahan

Christopher Mahan: Exactement. Le produit principal d'une entreprise pour laquelle j'ai travaillé consiste en ~ 5 fois plus de code PL / SQL que Java Code (LOC).
user281377

0

Si vous souhaitez utiliser une base de données vous-même, oui. La plupart des ORM que j'ai essayé d'utiliser n'étaient tout simplement pas suffisants ou ne couvraient pas ma base de données. De plus, comment allez-vous dépanner ou écrire des requêtes personnalisées qui ne sont pas couvertes?


0

Il est toujours nécessaire pour écrire des déclencheurs et des procédures stockées. Les procédures stockées sont peut-être tombées en disgrâce actuellement, mais elles sont toujours très utiles dans certaines situations. SQL peut également être requis pour certaines jointures multi-tables particulièrement poilues.


0

Oui, vous pouvez éviter d'écrire SQL. Mais vous finirez par écrire HQL à la place (ou Linq, ou DQL ...)!

Sérieusement, je suis un grand fan des ORM, et je pense qu'on peut éviter d'utiliser du SQL pur la plupart du temps. Mais nous devons nous rappeler qu'un ORM n'est qu'une grande abstraction, et toutes les grandes abstractions fuient ...

(Mais à propos du problème N + 1: il s'agit d'un chargement paresseux, et la plupart des outils ORM ont un moyen de demander un chargement rapide, évitant ainsi ce problème particulier.)


0

ORM ne vous amènera qu'à un certain point. Mais il y a des cas où vous devez exécuter une requête vraiment compliquée, avec des jointures, des sous-requêtes, des unions, des moins, des fonctions analytiques compliquées, etc. C'est là que vous avez besoin de SQL. Mais comment êtes-vous censé écrire des requêtes compliquées lorsque vous laissez toutes les requêtes simples à l'ORM?


0

Même si vous n'aviez pas besoin de l'écrire dans votre code, il est assez pratique de pouvoir l'utiliser lorsque vous avez un accès terminal à un serveur de base de données.

En outre, la plupart de ce qui rend la programmation d' un défi travaille dans les limites que les ensembles de vie US- souvent , nous sommes travaillons avec l' ancien code, ou les anciennes versions de bases de données et n'ont pas la possibilité d'installer la dernière ORM quelle que soit la langue que nous sommes travailler avec. Dans cette situation, vous aurez besoin de tout outil à votre disposition.

Le reste du temps, vous n'aurez peut-être pas besoin de SQL pour vos tâches CRUD, mais il y a beaucoup plus dans SQL que de simples requêtes SELECT, INSERT, UPDATE et JOIN de base. Vous pouvez faire des choses très intelligentes avec lui et même si vous ne les utilisez pas souvent, il est utile de savoir de quoi il s'agit.

De plus en plus, je pense que nous nous retrouverons dans un monde post-SQL, cependant - la plupart des services Cloud utilisent un stockage de table non SQL et pour un travail de type CRUD simple, la pleine puissance de SQL n'est pas nécessaire. Mais cela ne signifie pas qu'il n'y aura aucune valeur à le comprendre.

De plus, bien sûr, quelqu'un doit en savoir suffisamment pour écrire un meilleur système ORM si les systèmes actuels ne sont pas à la hauteur. Cela les aiderait s'ils connaissaient SQL ...


Exactement: après avoir rédigé un moteur de génération de rapports et des rapports fantaisie à partir d'un environnement Oracle Data Warehouse, je peux vous dire avec insistance que connaître SQL n'est pas la même chose que savoir utiliser un ORM.
Christopher Mahan

0

Pour créer des applications Web à grande échelle, cela est totalement inutile et peut rendre les choses beaucoup plus stressantes et perdre du temps qu'elles ne devraient l'être. La raison en est que toute application à grande échelle devrait utiliser une couche de persistance de mémoire (en RAM) qui devrait être des parties de mise en cache de mémoire de la base de données qui sont fréquemment utilisées.

Si vous devez faire des choses avec des appareils mobiles, etc. qui n'ont pas beaucoup de mémoire pour travailler, où l'application en cours de programmation s'exécute en tant que "client" ou application autonome sur un appareil mobile, une tablette, etc. des choses comme l'utilisation de SQL sont encore courantes et sont importantes car la mémoire sur l'appareil est si petite que vous ne pouvez pas mettre en cache beaucoup de choses en mémoire.


2
"toute application à grande échelle devrait utiliser une couche de persistance de mémoire (en RAM) qui devrait être des parties de mise en cache de mémoire de la base de données qui sont fréquemment utilisées." - Toute base de données décente le fera également.
Matthew Frederick

Android et iPhoneOS utilisent tous deux SQLite, un système de base de données compatible SQL-92. Voir stackoverflow.com/questions/2011724/…
Christopher Mahan

0

La complexité et la quantité de SQL que j'écris ne sont pas suffisantes pour rendre raisonnable le raccordement d'un framework ORM.

(J'écris SQL peut-être une fois par mois, si)


0

J'ai rencontré de nombreux grands corps avec des DBA qui craignent activement les développeurs utilisant des outils ORM.

Ce sont des DBA impliqués dans le réglage et les performances.

Et oui, les outils ORM peuvent être gérés pour faire des choses comme ça, mais j'ai vu des endroits où ils n'accepteront qu'une procédure stockée (Sql Server) et vous poseront des questions sur ce que vous y faites.

De plus, les outils ORM peuvent être mal utilisés et produire un Sql aussi pauvre que l'écriture du Sql vous-même.


Je suppose que le DBA qui s'inquiète pour un développeur utilisant un ORM s'apparente à un développeur qui s'inquiète pour un analyste / gestionnaire / client, étant donné un outil qui lui permet d'écrire du code!
gbjbaanb

0

One biggie - Migrations DDL et base de données. Parfois, vous devez assembler ces éléments à la main pour mettre à jour les choses sans casser les données existantes.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.