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

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?

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.

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!

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.

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.

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.

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.

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é.

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:

• Double réflexion en SQL

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!

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.

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.

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.

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.

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.

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.

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 où 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.

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).

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é.

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.

• 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.

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).

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.

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).

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.

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é

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.

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.

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 .

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.