Pourquoi pas d'amour pour SQL? [fermé]


116

J'ai beaucoup entendu ces derniers temps que SQL est un langage terrible, et il semble que chaque framework sous le soleil soit pré-emballé avec une couche d'abstraction de base de données.

Cependant, d'après mon expérience, SQL est souvent le moyen le plus simple, le plus polyvalent et le plus convivial pour les programmeurs de gérer l'entrée et la sortie de données. Chaque couche d'abstraction que j'ai utilisée semble être une approche nettement limitée sans réel avantage.

Qu'est-ce qui rend SQL si terrible et pourquoi les couches d'abstraction de base de données sont-elles précieuses?


11
qu'en est-il de la sécurité des types?
johnny

3
À qui s'adressent ces couches d'abstraction? SQL n'est pas un langage dans lequel tout le monde est bon, et il peut donc être destiné aux programmeurs médiocres. SQL lui-même n'est pas du tout un bon langage pour un non-programmeur.
David Thornley

27
@ David: Définissez un langage (informatique) qui est "bon pour un non-programmeur". Les non-programmeurs, à mon humble avis, devraient rester à l'écart des langages de programmation (et au sens large du mot, SQL).
DevSolar

15
toutes les réponses devraient aussi être wiki. il est tout simplement insensé que des questions et des réponses comme celles-ci obtiennent autant de votes. Je pensais que c'était un forum technique? vous pouvez résoudre le problème de quelqu'un en fournissant du code difficile à écrire et en obtenant un ou deux votes, mais répondez à une question comme celle-ci et obtenez des tonnes de votes. c'est vraiment nul si vous me demandez.
KM.

6
@KM: Le problème avec les votes est qu'ils dépendent beaucoup du nombre de personnes lisant une réponse. J'ai répondu à de nombreuses questions de NHibernate et Rhino Mocks qui ont mis du temps à répondre correctement - et j'ai été acceptée, mais pas un seul vote. Si vous répondez à quelque chose de trivial à propos de C #, vous obtenez des dizaines de votes. Les votes ne sont tout simplement pas justes. Suggérer quelque chose sur meta.stckoverflow, si vous savez quelque chose de mieux.
Stefan Steinegger

Réponses:


132

Ceci est en partie subjectif. Voici donc mon avis:

SQL a un style de langage pseudo-naturel . Les inventeurs pensaient qu'ils pouvaient créer une langue comme l'anglais et que les requêtes dans la base de données seraient très simples. Une terrible erreur. SQL est très difficile à comprendre, sauf dans des cas triviaux.

SQL est déclaratif. Vous ne pouvez pas dire à la base de données comment elle doit faire les choses, juste ce que vous voulez comme résultat. Ce serait parfait et très puissant - si vous n'aviez pas à vous soucier des performances. Vous finissez donc par écrire du SQL - lire des plans d'exécution - reformuler SQL en essayant d'influencer le plan d'exécution, et vous vous demandez pourquoi vous ne pouvez pas écrire vous-même le plan d'exécution .

Un autre problème du langage déclaratif est que certains problèmes sont plus faciles à résoudre de manière impérative. Donc, vous l'écrivez soit dans un autre langage (vous aurez besoin de SQL standard et probablement d'une couche d'accès aux données), soit en utilisant des extensions de langage spécifiques au fournisseur, par exemple en écrivant des procédures stockées, etc. En faisant cela, vous constaterez probablement que vous utilisez l'un des pires langages que vous ayez jamais vu - car il n'a jamais été conçu pour être utilisé comme un langage impératif.

SQL est très ancien . SQL a été standardisé, mais trop tard, de nombreux éditeurs ont déjà développé leurs extensions de langage. Donc SQL s'est retrouvé dans des dizaines de dialectes. C'est pourquoi les applications ne sont pas portables et une des raisons d'avoir une couche d'abstraction DB.

Mais c'est vrai - il n'y a pas d'alternatives possibles. Nous utiliserons donc tous SQL au cours des prochaines années.


31
"Dites simplement ce que vous voulez - nous livrons le plus rapidement possible". Cette approche déclarative est fantastique, et elle est en fait moderne (pensez à LINQ). Il est vrai que parfois vous avez besoin d'ajuster la vitesse, et une alternative procédurale à SQL pourrait alors être utile. Mais j'utiliserais toujours SQL déclaratif la plupart du temps pour la simplicité.
MarkJ

4
MarkJ: Je me souviens que j'ai réorganisé les clauses WHERE pour optimiser les requêtes dans oracle. Ils ont été résolus de bas en haut ... terrible.
Stefan Steinegger

16
Je suis complètement d'accord. Les informaticiens ont cette fascination pour les outils non procéduraux. Ne serait-il pas tellement plus facile si vous disiez simplement à l'ordinateur ce que vous voulez et qu'il découvre comment le faire! Ouais, si l'ordinateur était assez intelligent pour faire ça. Mais ce n'est pas le cas. J'aimerais que je dise simplement à ma voiture "Emmène-moi chez grand-mère" et cela me conduirait là-bas. Mais ce n'est pas le cas, alors je ne lâche pas simplement le volant et je prétends que cela fonctionnera. Peut-être qu'un jour la technologie sera là, ou peut-être que c'est un rêve impossible. Mais ce n'est pas là aujourd'hui. (suite ...)
Jay

12
Touché. Votre réponse décrit parfaitement mes premières frustrations avec SQL. J'ai écrit beaucoup de code procédural parce que je ne faisais pas confiance à SQL pour générer un plan d'exécution efficace. Au fur et à mesure que je maîtrisais mieux le SQL, j'ai découvert qu'il était en fait assez bon pour l'optimisation et que SQL correctement écrit s'exécutait généralement plus rapidement que mon code procédural.
Kluge

5
@Jay et les autres sceptiques SQL. Le problème selon mon expérience est que pour utiliser SQL efficacement, vous devez être capable de penser en termes d'ensembles et non de manière procédurale - c'est précisément ainsi que la plupart des programmeurs apprennent à penser. Utiliser SQL efficacement n'est vraiment pas si difficile et bien à la portée de tout codeur compétent (comme quiconque lisant SO!), Mais il est nécessaire de faire l'effort de passer à la logique basée sur les ensembles, et la plupart du temps, les gens ne le font pas. 'pas la peine (et je suis en train de modifier un programme où le codeur d'origine a tout fait en utilisant des curseurs précisément pour cette raison)
Cruachan

58

En dehors de tout ce qui a été dit, une technologie n'a pas à être mauvaise pour rendre une couche d'abstraction précieuse .

Si vous faites un script ou une application très simple, vous pouvez vous permettre de mélanger les appels SQL dans votre code où vous le souhaitez. Cependant, si vous faites un système complexe, isoler les appels de base de données dans des modules séparés est une bonne pratique et ainsi isoler votre code SQL. Il améliore la lisibilité, la maintenabilité et la testabilité de votre code. Il vous permet d'adapter rapidement votre système aux modifications du modèle de base de données sans interrompre tous les éléments de haut niveau, etc.

SQL est génial. Les couches d'abstraction le rendent encore plus grand!


6
Très diplomatique! (Et vrai, pour démarrer!)
Joseph Ferris

2
Le problème est l'inversion de l'abstraction. SQL dans une base de données relationnelle est un environnement déclaratif basé sur des ensembles. Il a un niveau d'abstraction plus élevé que la programmation impérative, orientée objet ou non.
Steven Huwig

2
Peut-être que oui, Steven, mais en termes d'application, il remplit une fonction de bas niveau (même s'il le fait de manière extrêmement élevée). Peu importe les transformations folles que vous faites au niveau de la base de données, en fin de compte, c'est un getter et un setter glorifiés. Ou vous pouvez le regarder de manière opposée, en ce sens qu'il est trop élevé pour être mélangé à l'application et doit être séquestré et considéré séparément. Dans tous les cas, garder le SQL en dehors du code principal de l'application présente des avantages très tangibles en termes de lisibilité et de refactoring.
Publié

53

Un point des couches d'abstraction est le fait que les implémentations SQL ont tendance à être plus ou moins incompatibles les unes avec les autres car la norme est légèrement ambiguë, et aussi parce que la plupart des fournisseurs y ont ajouté leurs propres extras (non standard). Autrement dit, SQL écrit pour une base de données MySQL peut ne pas fonctionner tout à fait de la même manière avec, par exemple, une base de données Oracle - même si cela "devrait".

Je conviens, cependant, que SQL est bien meilleur que la plupart des couches d'abstraction. Ce n'est pas la faute de SQL s'il est utilisé pour des choses pour lesquelles il n'a pas été conçu.


19
Je ne comprends pas comment les incompatibilités de dialectes SQL peuvent être un "point" si énorme contre SQL. C'est comme dire que C est de la merde parce que vous ne pouvez pas simplement compiler + exécuter la même source dans différentes distributions Linux. Si, et c'est un gros SI, votre entreprise décide de changer de fournisseur de base de données, c'est un événement rare et important qui comporte plus de pièces mobiles que la simple réécriture de SQL.
Jeff Meatball Yang

7
Ce n'est pas un point contre SQL, c'est un point pour les couches d'abstraction. Comme, vous ne pouvez pas simplement compiler + exécuter le même code C n'importe où, c'est un point pour plus de langages indifférents à la plate-forme. Mais cela ne rend pas SQL ni C "merdique": les couches d'abstraction courent de toute façon au-dessus des couches les plus profondes.
Joonas Pulakka

8
@Jeff: En C, les tâches courantes font partie de la norme. En SQL, il est impossible de paginer un jeu de résultats sans entrer dans le SQL spécifique au fournisseur.
Powerlord

4
Oh, et de la rareté du changement de fournisseur de bases de données: de quoi parlez-vous? La rareté d'une entreprise changeant de système d'exploitation rend-elle les solutions multiplateformes inutiles? Vous ne savez pas toujours à l'avance sur quoi votre produit va fonctionner, il vaut donc mieux opter pour des solutions plus génériques.
Joonas Pulakka

3
@Joonas: Je suppose que je voulais dire que le (s) langage (s) SQL n'est (sont) pas le problème - La question a été posée de savoir ce qui rend SQL si terrible, et ma première réaction, comme la vôtre, est que ce n'est pas le cas. Mais je voulais faire valoir que s'adapter à différents dialectes n'est pas vraiment le but des ORM - nous les aurions même si nous n'avions qu'un seul langage standard - je pense que c'est plus que nous avons besoin d'un moyen de résoudre les données normalisées en un modèle OO.
Jeff Meatball Yang

36

SQL est critiqué par plusieurs sources:

  • Des programmeurs qui ne sont à l'aise avec rien d'autre qu'un langage impératif.
  • Consultants confrontés quotidiennement à de nombreux produits SQL incompatibles
  • Fournisseurs de bases de données non relationnelles essayant de briser l'emprise des fournisseurs de bases de données relationnelles sur le marché
  • Des experts en bases de données relationnelles comme Chris Date qui considèrent les implémentations actuelles de SQL comme insuffisantes

Si vous vous en tenez à un seul produit SGBD, alors je suis tout à fait d'accord pour dire que les bases de données SQL sont plus polyvalentes et de meilleure qualité que leurs concurrents, du moins jusqu'à ce que vous atteigniez une barrière d'évolutivité intrinsèque au modèle. Mais essayez-vous vraiment d'écrire le prochain Twitter, ou essayez-vous simplement de garder certaines données comptables organisées et cohérentes?

La critique de SQL est souvent un support pour les critiques des SGBDR. Ce que les critiques des SGBDR semblent ne pas comprendre, c'est qu'ils résolvent assez bien une énorme classe de problèmes informatiques, et qu'ils sont là pour nous rendre la vie plus facile, pas plus difficile.

S'ils voulaient sérieusement critiquer SQL lui-même, ils soutiendraient des efforts tels que Tutorial D et Dataphor.


7
Concernant le premier point sur le fait que les programmeurs ne sont pas à l'aise avec autre chose qu'un langage impératif. Il sera intéressant au cours des prochaines années de voir si / comment la résurgence de la programmation fonctionnelle fait une différence. Il y a beaucoup de battage médiatique en ce moment sur des langages comme Haskell, F # et Scala, ce qui rend les développeurs beaucoup plus productifs. Ce type de pensée «mathématique» pour les programmeurs est très similaire à la connaissance de l'algèbre relationnelle et du calcul relationnel tuple que SQL suppose. Peut-être qu'il y aura une résurgence de la pensée native SQL basée sur les ensembles dans le temps!
Trevor Tippins

Je devrais préciser que je voulais dire "ces programmeurs qui ne sont pas à l'aise avec autre chose que la programmation impérative", non pas que tous les programmeurs soient mal à l'aise avec cela.
Steven Huwig

+1, bien dit. Et en tant que personne qui a passé les premières années en tant que codeur professionnel dans la base de données pré-relationnelle, je trouve franchement stupéfiant que quiconque veuille revenir à cette époque, sauf pour des tâches spécialisées. Une journée passée à écrire du code dans une arborescence DL / 1 devrait suffire à convaincre n'importe qui.
Cruachan

Le problème est qu'il existe de nombreux programmeurs compulsifs, qui préfèrent taper quelques centaines de lignes de code insipide plutôt que de penser aux choses pendant une heure environ.
Steven Huwig

Vous ne devriez pas avoir à penser aux choses pendant une heure pour écrire ou comprendre quelques lignes de code. Période.
Andrew le

23

Ce n'est pas si terrible. C'est une tendance malheureuse dans cette industrie à rejeter la technologie fiable précédente lorsqu'un nouveau «paradigme» sort. À la fin de la journée, ces frameworks utilisent très probablement SQL pour communiquer avec la base de données, alors comment cela peut-il être si mauvais? Cela dit, avoir une couche d'abstraction "standard" signifie qu'un développeur peut se concentrer sur le code d'application et non sur le code SQL. Sans une telle couche standard, vous en écririez probablement une légère à chaque fois que vous développez un système, ce qui est un gaspillage d'efforts.


16

SQL est conçu pour la gestion et l'interrogation des données basées sur SET. Il est souvent utilisé pour faire plus et les cas extrêmes entraînent parfois de la frustration.

L'UTILISATION réelle de SQL peut être tellement impactée par la conception de la base de données de base que le SQL n'est peut-être pas le problème, mais la conception peut - et lorsque vous ajoutez le code hérité associé à une mauvaise conception, les modifications sont plus impactantes et coûteuses à implémenter ( personne n'aime revenir en arrière et «réparer» les choses qui «fonctionnent» et qui atteignent les objectifs)

Les charpentiers peuvent marteler les clous avec des marteaux, scier le bois avec des scies et lisser les planches avec des rabots. Il est possible de «scier» à l'aide de marteaux et d'avions, mais c'est frustrant.


11

Je ne dirai pas que c'est terrible. Il ne convient pas à certaines tâches. Par exemple: vous ne pouvez pas écrire un bon code procédural avec SQL. J'ai été une fois obligé de travailler avec la manipulation de set avec SQL. Il m'a fallu un week-end entier pour comprendre cela.

SQL a été conçu pour l'algèbre relationnelle - c'est là qu'il doit être utilisé.


2
Le malheur est qu'il est très tentant de simplement coller un simple code procédural dans une procédure stockée. Et cela fonctionne très bien. JUSQU'À ce que quelqu'un ait besoin de le maintenir / ajouter quelques exceptions, etc ...
Brian Knoblauch

5
-1, euh c'est précisément le point, SQL est conçu pour être basé sur des ensembles et c'est la puissance de celui-ci. Penser en termes de procédure signifie que vous pensez mal.
Cruachan

1
Ce tournevis est nul! C'est si difficile de se cogner les ongles avec.
Casey Rodarmor

9

J'ai beaucoup entendu ces derniers temps que SQL est un langage terrible, et il semble que chaque framework sous le soleil soit pré-emballé avec une couche d'abstraction de base de données.

Notez que ces couches convertissent simplement leurs propres éléments en SQL. Pour la plupart des fournisseurs de bases de données, SQLc'est le seul moyen de communiquer avec le moteur.

Cependant, d'après mon expérience, SQL est souvent le moyen le plus simple, le plus polyvalent et le plus convivial pour les programmeurs de gérer l'entrée et la sortie de données. Chaque couche d'abstraction que j'ai utilisée semble être une approche nettement limitée sans réel avantage.

… Raison pour laquelle je viens de décrire ci-dessus.

Les couches de base de données n'ajoutent rien, elles vous limitent simplement . Ils rendent les requêtes incontestablement plus simples mais jamais plus efficaces.

Par définition, il n'y a rien dans les couches de base de données qui n'y soit pas SQL.

Qu'est-ce qui rend SQLsi terrible et pourquoi les couches d'abstraction de base de données sont-elles précieuses?

SQL est un langage agréable, cependant, il faut une certaine torsion du cerveau pour travailler avec.

En théorie, SQLc'est déclaratif, c'est-à-dire que vous déclarez ce que vous voulez obtenir et que le moteur le fournit de la manière la plus rapide possible.

En pratique, il existe de nombreuses façons de formuler une requête correcte (c'est-à-dire la requête qui renvoie des résultats corrects).

Les optimiseurs sont capables de construire un château Lego à partir de certains algorithmes prédéfinis (oui, ils sont multiples), mais ils ne peuvent tout simplement pas créer de nouveaux algorithmes. Il faut encore un SQLdéveloppeur pour les aider.

Cependant, certaines personnes s'attendent à ce que l'optimiseur produise "le meilleur plan possible", et non "le meilleur plan disponible pour cette requête avec une implémentation donnée du SQLmoteur".

Et comme nous le savons tous, lorsque le programme informatique ne répond pas aux attentes des gens, c'est le programme qui est blâmé, pas les attentes.

Dans la plupart des cas, cependant, la reformulation d'une requête peut effectivement produire le meilleur plan possible. Cependant, SQLcertaines tâches sont impossibles, car les améliorations nouvelles et croissantes apportées à ces cas deviennent de moins en moins nombreuses.

Ce serait bien, cependant, que les fournisseurs fournissent un accès de bas niveau aux fonctions comme "obtenir la plage d'index", "obtenir une ligne par le rowid" etc., comme les Ccompilateurs vous permettent d'incorporer l'assembly directement dans le langage.

J'ai récemment écrit un article à ce sujet dans mon blog:


7

Je suis un grand défenseur de l'ORM et je crois toujours que SQL est très utile, bien qu'il soit certainement possible de faire des choses terribles avec lui (comme toute autre chose). .

Je considère SQL comme un langage super efficace qui n'a pas la réutilisation du code ou la maintenabilité / refactorisation comme priorités.

Un traitement ultra-rapide est donc la priorité. Et c'est acceptable. Vous devez simplement être conscient des compromis, qui sont pour moi considérables.

D'un point de vue esthétique, en tant que langage, je pense qu'il manque certaines choses car il n'a pas de concepts OO et ainsi de suite - cela ressemble à un code de procédure très old school pour moi. Mais c'est de loin le moyen le plus rapide de faire certaines choses, et c'est un créneau puissant!


7

Je dirais qu'une couche d'abstraction de base de données incluse dans un framework est une bonne chose car elle résout deux problèmes très importants:

  1. Il maintient le code distinct. En plaçant le SQL dans une autre couche, qui est généralement très fine et ne devrait faire que les bases de l'interrogation et du transfert des résultats (de manière standardisée), vous gardez votre application libre de l'encombrement de SQL. C'est la même raison pour laquelle les développeurs Web (devraient) mettre CSS et Javascript dans des fichiers séparés. Si vous pouvez l'éviter, ne mélangez pas vos langues .

  2. De nombreux programmeurs sont tout simplement mauvais dans l'utilisation de SQL. Pour une raison quelconque, un grand nombre de développeurs (en particulier les développeurs Web) semblent être très, très mauvais dans l'utilisation de SQL, ou des SGBDR en général. Ils traitent la base de données (et SQL par extension) comme le petit intermédiaire sale par lequel ils doivent passer pour accéder aux données. Cela conduit à des bases de données extrêmement mal pensées sans index, des tables empilées au-dessus des tables de manière douteuse et des requêtes très mal écrites. Ou pire, ils essaient d'être trop généraux (système expert, n'importe qui?) Et ne peuvent raisonnablement pas relier les données de manière significative.

Malheureusement, parfois, la manière dont une personne essaie de résoudre un problème et les outils qu'elle utilise, que ce soit par ignorance, par entêtement ou par un autre trait, sont en opposition directe les unes avec les autres, et bonne chance pour essayer de les convaincre de cela. En tant que tel, en plus d'être simplement une bonne pratique, je considère une couche d'abstraction de base de données comme une sorte de filet de sécurité, car non seulement elle garde le SQL hors des yeux du pauvre développeur, mais elle rend leur code beaucoup plus facile à refactoriser, puisque toutes les requêtes sont au même endroit.


6

SQL est excellent pour certains types de tâches, en particulier la manipulation et la récupération d' ensembles de données.

Cependant, SQL manque (ou n'implémente que partiellement) plusieurs outils importants pour gérer le changement et la complexité:

  • Encapsulation : les mécanismes d'encapsulation de SQL sont grossiers. Lorsque vous écrivez du code SQL, vous devez tout savoir sur l'implémentation de vos données. Cela limite la quantité d' abstraction que vous pouvez réaliser.

  • Polymorphisme : si vous souhaitez effectuer la même opération sur différentes tables, vous devez écrire le code deux fois. (On peut atténuer cela avec une utilisation imaginative des vues.)

  • Contrôle de la visibilité : il n'y a pas de mécanisme SQL standard pour cacher des morceaux de code les uns des autres ou les regrouper en unités logiques, de sorte que chaque table, procédure, etc. est accessible de toutes les autres, même si cela n'est pas souhaitable.

  • Modularité et gestion des versions

Enfin, le codage manuel des opérations CRUD en SQL (et l'écriture du code pour le connecter au reste de l'application) est répétitif et sujet aux erreurs.

Une couche d'abstraction moderne fournit toutes ces fonctionnalités et nous permet d'utiliser SQL là où il est le plus efficace tout en cachant les détails d'implémentation perturbateurs et répétitifs. Il fournit des outils pour aider à surmonter la discordance d'impédance objet-relationnelle qui complique l'accès aux données dans le développement de logiciels orientés objet.


Qu'en est-il des schémas pour le contrôle de la visibilité?
Three Value Logic

5

SQL est basé sur la théorie des ensembles, alors que la plupart des langages de haut niveau sont orientés objet de nos jours. Les programmeurs d'objets aiment généralement penser en objets et doivent faire un changement mental pour utiliser les outils basés sur Set pour stocker leurs objets. Généralement, il est beaucoup plus naturel (pour le programmeur OO) de simplement couper le code dans la langue de son choix et de faire quelque chose comme object.save ou object.delete dans le code de l'application au lieu d'avoir à écrire des requêtes SQL et à appeler la base de données pour réaliser le même résultat.

Bien sûr, parfois pour des choses complexes, SQL est plus facile à utiliser et plus efficace, il est donc bon de maîtriser les deux types de technologie.


5

OMI, le problème que je vois que les gens ont avec SQL n'a rien à voir avec la conception relationnelle ni avec le langage SQL lui-même. Cela a à voir avec la discipline de la modélisation de la couche de données qui, à bien des égards, est fondamentalement différente de la modélisation d'une couche métier ou d'une interface. Les erreurs de modélisation au niveau de la couche présentation sont généralement beaucoup plus faciles à corriger qu'au niveau de la couche de données où plusieurs applications utilisent la base de données. Ces problèmes sont les mêmes que ceux rencontrés dans la modélisation d'une couche de service dans les conceptions SOA où vous devez prendre en compte les consommateurs actuels de votre service et les contrats d'entrée et de sortie.

SQL a été conçu pour interagir avec les modèles de bases de données relationnelles. Il existe d'autres modèles de données qui existent depuis un certain temps, mais la discipline concernant la conception de la couche de données existe correctement quel que soit le modèle théorique utilisé et, par conséquent, les difficultés que les développeurs ont généralement avec SQL sont généralement liées aux tentatives d'imposer un non-relationnel. modèle de données sur un produit de base de données relationnelle.


4

D'une part, ils rendent facile l'utilisation de requêtes paramétrées, vous protégeant des attaques par injection SQL. L'utilisation du SQL brut, de ce point de vue, est plus risquée, c'est-à-dire plus facile à se tromper du point de vue de la sécurité. Ils présentent également souvent une perspective orientée objet sur votre base de données, vous évitant d'avoir à faire cette traduction.


2
C'est vrai, mais vous n'avez pas besoin d'un ORM pour cela
finlandais

2
L'utilisation de requêtes paramétrées est triviale lors de l'écriture directe de SQL, à condition que vous ayez une couche d'interface de base de données décente (c'est-à-dire une couche qui prend en charge les espaces réservés). $dbh->do("DELETE FROM my_table WHERE some_value = ?", undef, $target_value); Là. Terminé.
Dave Sherohman

Je n'ai jamais dit que vous ne pouviez pas écrire de requêtes paramétrées avec RAW SQL. J'ai dit que l'utilisation de SQL brut est plus risquée car vous devez l'implémenter vous-même. J'ai vu de nombreux cas de code SQL brut où la requête n'est pas paramétrée. Les ORM offrent cet avantage automatiquement.
tvanfosson

2
C'est vrai, mais éviter l'injection SQL est trivialement facile, même sans instructions préparées. Chaque projet que je fais, j'écris une fonction simple qui met des guillemets autour d'une chaîne et échappe correctement les guillemets incorporés. Cela prend environ quinze minutes à écrire même si je ne le copie pas d'un projet précédent. Ensuite, je l'utilise pour chaque littéral que j'intègre dans une requête. Ce qui est stupéfiant pour moi, c'est que les programmeurs ne font pas ça! Ne prenez pas quinze minutes pour éviter une injection SQL délibérée ou - probablement plus courante - accidentelle! Pourquoi pas?!
Jay

3
Jay, est-ce que cette "fonction simple qui met des guillemets autour d'une chaîne et échappe correctement les guillemets incorporés" prend-elle en compte le jeu de caractères actuellement utilisé sur le serveur?
ygrek

4

Beaucoup entendu récemment? J'espère que vous ne confondez pas cela avec le mouvement NoSql. Autant que je sache, c'est principalement un groupe de personnes qui utilisent NoSql pour des applications Web à haute évolutivité et semblent avoir oublié que SQL est un outil efficace dans un scénario non "d'application Web à haute évolutivité".

L 'activité de la couche d' abstraction consiste simplement à trier la différence entre le code orienté objet et le code basé sur un ensemble de tables, tel que SQL aime parler. Habituellement, cela entraîne l'écriture de beaucoup de plaque chauffante et un code de transition terne entre les deux. ORM automatise cela et fait ainsi gagner du temps aux personnes objectivées.


4

Pour les programmeurs SQL expérimentés, les mauvais côtés sont

  • Verbosité
  • Comme beaucoup l'ont dit ici, SQL est déclaratif, ce qui signifie que l' optimisation n'est pas directe . C'est comme le rallye par rapport à la course sur circuit.
  • Cadres qui tentent de traiter tous les dialectes possibles et ne prennent en charge les raccourcis d'aucun d'entre eux
  • Pas de contrôle de version facile.

Pour d'autres, les raisons sont que

  • certains programmeurs sont mauvais en SQL. Probablement parce que SQL fonctionne avec des ensembles, tandis que les langages de programmation fonctionnent en paradigme objet ou fonctionnel. Penser en ensembles (union, produit, intersection) est une question d'habitude que certaines personnes n'ont pas.
  • certaines opérations ne sont pas explicites: c'est-à-dire au début, il n'est pas clair que et d' avoir des ensembles de filtres différents.
  • il y a trop de dialectes

L'objectif principal des frameworks SQL est de réduire votre saisie. Ils le font en quelque sorte, mais trop souvent uniquement pour des requêtes très simples. Si vous essayez de faire quelque chose de complexe, vous devez utiliser des chaînes et taper beaucoup. Les frameworks qui tentent de gérer tout ce qui est possible, comme SQL Alchemy, deviennent trop énormes, comme un autre langage de programmation.

[mise à jour le 26.06.10] Récemment, j'ai travaillé avec le module Django ORM . C'est le seul framework SQL digne que j'ai vu. Et celui-ci fait beaucoup travailler avec des choses. Les agrégats complexes sont cependant un peu plus durs.


3

SQL n'est pas un langage terrible, il ne joue tout simplement pas trop bien avec les autres parfois.

Si, par exemple, vous avez un système qui souhaite représenter toutes les entités sous forme d'objets dans un langage OO ou un autre, alors combiner cela avec SQL sans aucune sorte de couche d'abstraction peut devenir assez fastidieux. Il n'y a pas de moyen simple de mapper une requête SQL complexe sur le monde OO. Pour atténuer la tension entre ces mondes, des couches supplémentaires d'abstraction sont insérées (un OR-Mapper par exemple).


Pourquoi est-ce la faute de SQL si les langages OO ne s'y adaptent pas bien? Lorsque vous utilisez un service, conformez-vous à son interface ou ne l'utilisez pas.
KM.

2
Personne n'a dit que c'était la faute de SQL. La langue véhiculaire de l'accès à la base de données est SQL. La lingua franca de la logique métier est basée sur l'OO. Ces deux éléments ne correspondent pas parfaitement sans aide. Pas de "faute" ou "problème" ici, juste quelques exigences ("les faire correspondre") et une solution largement acceptée ("utiliser un OR-Mapper").
Joachim Sauer

Joachim Sauer a dit que SQL n'est pas un langage terrible, il ne joue tout simplement pas très bien avec les autres. Pour moi, on dirait que quelqu'un a dit que c'était la faute de SQL
KM.

1
@KM: Êtes-vous en train de dire que le français et l'allemand sont de mauvaises langues? Ils ne jouent pas très bien avec l'anglais.
David Thornley

3

SQL est un très bon langage pour la manipulation de données. Du point de vue du développeur, ce que je n'aime pas, c'est que changer la base de données ne casse pas votre code au moment de la compilation ... J'utilise donc l'abstraction qui ajoute cette fonctionnalité au prix de la performance et peut-être de l'expressivité du langage SQL , car dans la plupart des applications, vous n'avez pas besoin de tout ce que SQL possède.

L'autre raison pour laquelle SQL est détesté est à cause des bases de données relationnelles.

Le théorème CAP devient populaire:

Quels objectifs pourriez-vous souhaiter d'un système de données partagées?

  • Forte cohérence: tous les clients voient la même vue, même en présence de mises à jour
  • Haute disponibilité: tous les clients peuvent trouver une réplique des données, même en présence de pannes
  • Tolérance de partition: les propriétés du système sont conservées même lorsque le système est partitionné

Le théorème indique que vous ne pouvez toujours avoir que deux des trois propriétés CAP en même temps

Adresse de base de données relationnelle Forte cohérence et tolérance de partition.

Ainsi, de plus en plus de gens se rendent compte que la base de données relationnelle n'est pas la solution miracle, et de plus en plus de gens commencent à la rejeter en faveur de la haute disponibilité, car la haute disponibilité facilite la mise à l'échelle horizontale. La mise à l'échelle horizontale gagne en popularité parce que nous avons atteint la limite de la loi de Moore , donc la meilleure façon de faire évoluer est d'ajouter plus de machine.

Si la base de données relationnelle est rejetée, SQL est également rejeté.


3

SQL a de nombreux défauts, comme l'ont souligné d'autres affiches ici. Pourtant, je préfère de loin utiliser SQL à la plupart des outils que les gens proposent comme alternatives, car les «simplifications» sont souvent plus compliquées que ce qu'elles étaient censées simplifier.

Ma théorie est que SQL a été inventé par un groupe de skieurs bleus de la tour d'ivoire. Toute la structure non procédurale. Ça a l'air génial: dites-moi ce que vous voulez plutôt que comment vous voulez le faire. Mais dans la pratique, il est souvent plus facile de simplement donner les étapes. Cela ressemble souvent à essayer de donner des instructions d'entretien de la voiture en décrivant comment la voiture doit fonctionner lorsque vous avez terminé. Oui, vous pourriez dire: "Je veux que la voiture atteigne à nouveau 30 miles par gallon, et qu'elle fonctionne avec ce bourdonnement comme celui-ci ... hmmmm ... et, etc." Mais ce ne serait pas plus facile pour tout le monde dites simplement «Remplacez les bougies»? Et même lorsque vous découvrez comment exprimer une requête complexe en termes non procéduraux, le moteur de base de données propose souvent un plan d'exécution très inefficace pour y parvenir.

Et le traitement des nulls me rend fou! Oui, théoriquement, cela doit avoir sonné génial quand quelqu'un a dit: "Hé, si nul signifie inconnu, alors l'ajout d'une valeur inconnue à une valeur connue devrait donner une valeur inconnue. Après tout, par définition, nous n'avons aucune idée de la valeur inconnue. . " Théoriquement, absolument vrai. En pratique, si nous avons 10 000 clients et que nous savons exactement combien d’argent 9 999 nous doivent, mais il y a une question sur le montant dû par le dernier, et la direction dit: «Quel est le total de nos comptes clients?», Oui, le calcul est mathématiquement correct la réponse est "je ne sais pas". Mais la réponse pratique est "nous calculons 4 327 287,42 $ mais un compte est en question, donc ce nombre n'est pas exact". Je suis sûr que la direction préfère de loin obtenir un chiffre proche sinon certain qu'un regard vide.

Cela dit, je préférerais toujours utiliser SQL plutôt qu'une couche construite sur SQL, qui crée simplement un autre ensemble de choses que j'ai besoin d'apprendre, puis je dois savoir que finalement cela sera traduit en SQL, et parfois Je peux juste lui faire confiance pour faire la traduction correctement et efficacement, mais quand les choses deviennent complexes, je ne peux pas, alors maintenant je dois connaître la couche supplémentaire, je dois toujours connaître SQL et je dois savoir comment cela va se traduire Je peux tromper la couche en incitant SQL à faire la bonne chose. Arggh.


3
Toute l'idée de base de données relationnelle était le produit des blue-skyers de la tour d'ivoire. Les premières bases de données relationnelles avaient des performances horribles par rapport aux bases de données hiérarchiques actuelles, et ont mis beaucoup de temps à s'établir. La puissance de l'abstraction était telle que les bases de données hiérarchiques appartiennent essentiellement au passé (non pas qu'il n'y ait probablement pas de bases de données IMS et CODASYL encore disponibles). Cela devait très bien fonctionner.
David Thornley

1
Mais la direction ne verrait pas un "chiffre proche sinon certain" - elle verrait un chiffre erroné. Peut-être que ce client final doit beaucoup d'argent. La direction serait alors très mécontente de ce faux numéro.
HTTP 410

RoadWarrior: Oui, il est possible que vous ayez 10 000 clients qui vous doivent chacun 10 $ et 1 client qui vous doit 10 millions de dollars. Mais si tel était le cas, toute personne demandant un rapport AR connaîtrait probablement très bien le nom de ce client et saura exactement ce qui se passait avec lui. D'accord, je suis sûr qu'il y a des moments où aucune réponse est meilleure qu'une réponse qui est si peu fiable qu'elle n'a aucun sens. Mais c'est mon point: SQL est conçu autour de considérations théoriques comme celle-là: un dogmatique "rien de moins que la perfection ne vaut rien". ...
Jay

... Dans la vraie vie, 95% du temps, une réponse approximative est bien meilleure qu'un regard vide. Quand je regarde mon chéquier, je sais qu'il est fort possible que j'ai fait une erreur de calcul ou oublié d'écrire un chèque. Le solde pourrait bien être une approximation. Mais quand même, si je sais que j'ai «environ 1 000 $», je n'aurai aucun scrupule à faire un chèque de 50 $, et je me rendrai compte que faire un chèque de 10 000 $ sera futile.
Jay

Eh bien, j'ai dirigé une entreprise, et ce n'est jamais 10K contre 1. IMX, c'est plus proche de 20 inconnus pour 100 connus (le principe de pareto). Et certains de ces 20 nous devaient beaucoup d'argent, ce qui explique pourquoi le montant réel était contesté. Encore une fois, c'est le principe de pareto.
HTTP 410

3

• Chaque fournisseur étend la syntaxe SQL en fonction de ses besoins. Donc, à moins que vous ne fassiez des choses assez simples, votre code SQL n'est pas portable.

• La syntaxe de SQL n'est pas orthogonale; Par exemple, les instructions select, insert, update,et deleteont toutes une structure syntaxique complètement différente.


1
Comment cela rend-il la syntaxe non orthogonale?
Amok

1
Le langage aurait pu être conçu de telle sorte que toutes ces instructions impératives aient une syntaxe plus commune, en particulier entre les opérations insertet update, qui sont presque identiques sémantiquement, mais complètement différentes syntaxiquement.
David R Tribble

2

Je suis d'accord avec vos points, mais pour répondre à votre question, une chose qui rend SQL si "terrible" est le manque de standardisation complète de T-SQL entre les fournisseurs de bases de données (Sql Server, Oracle, etc.), ce qui rend le code SQL peu probable. complètement portable. Les couches d'abstraction de base de données résolvent ce problème, mais avec un coût de performance (parfois très sévère).


2
Je ne comprends pas comment les incompatibilités de dialectes SQL peuvent être un "point" si énorme contre SQL. C'est comme dire que C est de la merde parce que vous ne pouvez pas simplement compiler + exécuter la même source dans différentes distributions Linux.
Jeff Meatball Yang

1
@Jeff: Je ne pense pas que ce soit un énorme point contre SQL, en fait. C'est pourquoi j'ai dit «Je suis d'accord avec vos points» et mis «terrible» entre guillemets. Je préfère SQL aux couches d'abstraction de données, moi-même, même si je suis content que des choses comme NHibernate existent parce qu'elles sont bien meilleures que les conneries locales qui proliféraient.
MusiGenesis

1
C'est vrai - j'utilise aussi des couches d'abstraction - je suppose que je voulais dire que, pour moi, le langage SQL n'est pas le problème - c'est la transformation de données normalisées en objets, c'est pourquoi les couches d'abstraction sont utiles.
Jeff Meatball Yang

2

Vivre avec du SQL pur peut vraiment être un enfer de maintenance. Pour moi, le plus grand avantage des ORM est la possibilité de refactoriser le code en toute sécurité sans procédures fastidieuses de «refactoring de base de données». Il existe de bons frameworks de tests unitaires et des outils de refactoring pour les langages OO, mais je dois encore voir l'homologue de Resharper pour SQL, par exemple.

Tous les DAL ont toujours SQL dans les coulisses, et vous devez toujours le savoir pour comprendre ce qui se passe dans votre base de données, mais travailler quotidiennement avec une bonne couche d'abstraction devient plus facile.


le traitement des instances d'objets en mémoire est assez différent des données physiquement stockées dans une base de données. il y a plus de difficultés à corriger les mauvais designs, et peut-être des variations massives de performances basées sur de «petites choses»
KM.

2

Si vous n'avez pas trop utilisé SQL, je pense que le problème majeur est le manque de bons outils de développement.

Si vous avez beaucoup d'expérience avec SQL, vous aurez, à un moment ou à un autre, été frustré par le manque de contrôle sur le plan d'exécution. Il s'agit d'un problème inhérent à la manière dont SQL a été spécifié aux fournisseurs. Je pense que SQL doit devenir un langage plus robuste pour vraiment exploiter la technologie sous-jacente (qui est très puissante).


2

Vite, écrivez-moi SQL pour paginer un ensemble de données qui fonctionne dans MySQL, Oracle, MSSQL, PostgreSQL et DB2.

Oh, d'accord, le SQL standard ne définit aucun opérateur pour limiter le nombre de résultats qui reviennent et à quelle ligne commencer.


5
Pourquoi essayez-vous de cibler tous ces environnements avec votre code? Écrivez-moi du code C pour les threads qui fonctionnent sous Mac OS 9, Windows NT, OS / 2 Warp et Solaris.
Steven Huwig

2
@Steven Huwig: J'utiliserais probablement une couche d'abstraction pour le faire pour moi ... c'est exactement ce que la question posait.
Powerlord

@Steven: Il se trouve que j'utilise des frameworks et des couches d'abstraction pour pas mal de choses où j'ai besoin d'être indépendant de la plateforme. Cependant, l'indépendance de la base de données est tellement plus importante dans la plupart des cas. Même si vous ne livrez votre logiciel que pour fonctionner sous Windows, une fois que vous le vendez à de plus grandes entreprises, vous rencontrerez tout, de «Nous préférons OSS, supportez-vous MySQL» à «Nous utilisons Oracle | MSSQL | quoi que ce soit une norme d'entreprise, la soutenez-vous?
Fredrik

2

Il n'y a pas d'amour pour SQL car SQL est mauvais dans la syntaxe, la sémantique et l'utilisation actuelle. Je vais t'expliquer:

  • sa syntaxe est un éclat de cobol, toutes les critiques de cobol s'appliquent ici (à un moindre degré, pour être juste). Essayer d'être un langage naturel comme sans vraiment essayer d'interpréter le langage naturel crée une syntaxe arbitraire (est-ce DROP TABLE ou DROP, UPDATE TABLE, UPDATE ou UPDATE IN, DELETE ou DELETE FROM ...) et des monstruosités syntaxiques comme SELECT (combien de pages font ça remplit?)
  • la sémantique est également profondément imparfaite, Date l'explique en détail, mais il suffira de noter qu'une logique booléenne à trois valeurs ne correspond pas vraiment à une algèbre relationnelle où une ligne peut seulement faire partie ou non d'une table
  • avoir un langage de programmation comme interface principale (et souvent seule) des bases de données s'est avéré être un très mauvais choix et a créé une nouvelle catégorie de failles de sécurité

1

Je suis d'accord avec la plupart des articles ici que le débat sur l'utilité de SQL est principalement subjectif, mais je pense que c'est plus subjectif dans la nature de vos besoins commerciaux.

Les langages déclaratifs, comme l'a souligné Stefan Steinegger, sont bons pour spécifier ce que vous voulez, pas comment vous voulez le faire. Cela signifie que vos différentes implémentations de SQL sont décentes d'un point de vue de haut niveau: c'est-à-dire que si tout ce que vous voulez est d'obtenir des données et que rien d'autre n'a d'importance, vous pouvez vous contenter d'écrire des requêtes relativement simples et de choisir l'implémentation de SQL cela vous convient.

Si vous travaillez à un niveau beaucoup plus "inférieur" et que vous avez besoin d'optimiser tout cela vous-même, c'est loin d'être idéal. Utiliser une couche supplémentaire d'abstraction peut aider, mais si ce que vous essayez vraiment de faire est de spécifier les méthodes d'optimisation des requêtes, etc., il est un peu contre-intuitif d'ajouter un intermédiaire lorsque vous essayez d'optimiser.

Le plus gros problème que j'ai avec SQL est comme les autres langages "standardisés", il y a très peu de vrais standards. Je préférerais presque avoir à apprendre un tout nouveau langage entre Sybase et MySQL pour ne pas confondre les deux conventions.


Vous pouvez vous épargner un peu de cette douleur en n'utilisant tout simplement pas MySQL. ;)
Steven Huwig

1

Bien que SQL fasse le travail, il a certainement des problèmes ...


  • il essaie d'être simultanément l'abstraction de haut niveau et de bas niveau , et c'est ... étrange. Il aurait peut-être dû y avoir deux normes ou plus à des niveaux différents.
  • c'est un énorme échec en tant que norme . Beaucoup de choses tournent mal lorsqu'une norme remue tout, demande trop d'implémentations, demande trop peu ou, pour une raison quelconque, n'atteint pas l'objectif partiellement social de motiver les vendeurs et les implémenteurs à produire des implémentations complètes interopérables strictement conformes. Vous ne pouvez certainement pas dire que SQL a fait quoi que ce soit. Examinez d'autres normes et notez que le succès ou l'échec de la norme est clairement un facteur de la coopération utile obtenue:
    • RS-232 ( Mauvais , pas assez spécifié, même quelle broche transmet et quelle broche reçoit est facultative, sheesh. Vous pouvez vous conformer mais toujours rien. Chance d'interopérabilité réussie: vraiment faible jusqu'à ce que le PC IBM fasse un standard utile de facto .)
    • IEEE 754-1985 Floating Point ( Mauvais , dépassement: pas un seul supercalculateur ou station de travail scientifique ou microprocesseur RISC ne l'a jamais adopté, bien que finalement, après 20 ans, nous ayons pu l'implémenter correctement dans HW. Au moins le monde y a finalement grandi.)
    • C89, C99, PCI, USB, Java ( Bon , standard ou spec, ils ont réussi à motiver le strict respect de presque tout le monde, et que la conformité a donné lieu à interopération avec succès.)
  • il n’a pas été sélectionné pour la base de données la plus importante au monde . Bien que ce soit plus un point de données qu'une raison, le fait que Google Bigtable ne soit ni SQL ni relationnel est une sorte d'anti-succès pour SQL.

0

Je n'aime pas SQL, mais je ne veux pas non plus avoir à l'écrire dans le cadre de ce que je développe. La DAL n'est pas une question de vitesse de mise sur le marché - en fait, je n'ai jamais pensé qu'il y aurait une implémentation DAL qui serait plus rapide que les requêtes directes à partir du code. Mais le but du DAL est d' abstraire . L'abstraction a un coût, et ici c'est qu'elle prendra plus de temps à mettre en œuvre.

Les avantages sont cependant énormes. Ecrire des tests natifs autour du code, en utilisant des classes expressives, des ensembles de données fortement typés, etc. Nous utilisons une sorte de "DAL", qui est une implémentation DDD pure utilisant Generics en C #. Nous avons donc des référentiels génériques, des implémentations d'unité de travail (transactions basées sur le code) et une séparation logique. Nous pouvons faire des choses comme simuler nos ensembles de données avec peu d'effort et réellement développer avant les implémentations de bases de données. Il y avait un coût initial dans la construction d'un tel cadre, mais c'est très bien que la logique métier soit à nouveau la vedette du spectacle. Nous consommons maintenant les données comme une ressource et les traitons dans le langage que nous utilisons nativement dans le code. Un avantage supplémentaire de cette approche est la séparation claire qu'elle fournit. Je ne vois plus de requête de base de données dans une page Web, par exemple. Oui, cette page a besoin de données. Oui, la base de données est impliquée. Mais maintenant, peu importe d'où je tire des données, il n'y a qu'un (et un seul) endroit pour entrer dans le code et le trouver. Ce n'est peut-être pas un gros problème pour les petits projets, mais lorsque vous avez des centaines de pages dans un site ou des dizaines de fenêtres dans une application de bureau, vous pouvez vraiment l'apprécier.

En tant que développeur, j'ai été embauché pour mettre en œuvre les exigences de l'entreprise en utilisant mes compétences logiques et analytiques - et notre mise en œuvre de cadre me permet d'être plus productif maintenant. En tant que manager, je préfère que mes développeurs utilisent leurs compétences logiques et analytiques pour résoudre des problèmes plutôt que d'écrire du SQL. Le fait que nous puissions créer une application entière qui utilise la base de données sans avoir la base de données jusqu'à la fin du cycle de développement est une belle chose. Il ne s'agit pas de frapper les professionnels des bases de données. Parfois, une implémentation de base de données est plus complexe que la solution. SQL (et dans notre cas, Views et Stored Procs, en particulier) sont un point d'abstraction où le code peut consommer des données en tant que service. Dans les magasins où il y a une séparation nette entre les équipes de données et de développement, cela permet d'éviter de rester assis dans un schéma d'attente en attente de l'implémentation et des modifications de la base de données. Les développeurs peuvent se concentrer sur le domaine du problème sans survoler un DBA et le DBA peut se concentrer sur l'implémentation correcte sans qu'un développeur n'en ait besoindès maintenant .


1
Downvoter - voulez-vous expliquer pourquoi ou cliquez simplement sur le bouton bas pour tout ce avec quoi vous n'êtes pas d'accord?
Joseph Ferris

0

De nombreux articles ici semblent affirmer que SQL est mauvais parce qu'il n'a pas de fonctionnalités "d'optimisation du code" et que vous n'avez aucun contrôle sur les plans d'exécution.

Ce que font les moteurs SQL, c'est de proposer un plan d'exécution pour une instruction écrite, orienté vers les données , le contenu réel . Si vous souhaitez regarder au-delà du côté programmation, vous verrez qu'il y a plus dans les données que les octets passés entre les niveaux d'application.

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.