Pourquoi ne pas aimer SQL ?

Question

J'ai beaucoup entendu dire ces derniers temps que SQL est un langage terrible, et il semble que tous les frameworks sous le soleil soient livrés avec une couche d'abstraction de base de données.

Cependant, d'après mon expérience, SQL est souvent le moyen le plus facile, le plus polyvalent et le plus convivial pour les programmeurs de gérer l'entrée et la sortie des données. Chaque couche d'abstraction que j'ai utilisée semble être une approche nettement limitée et 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 ?

Answer 1

C'est en partie subjectif. C'est donc mon opinion :

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

Le langage SQL est déclaratif. Vous ne pouvez pas dire à la base de données cómo il devrait faire des 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 vous retrouvez donc à écrire du SQL - lire des plans d'exécution - reformuler du SQL en essayant d'influencer le plan d'exécution, et vous vous demandez pourquoi vous ne pouvez pas écrire le plan d'exécution vous-même .

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

SQL est très vieux . SQL a été normalisé, mais trop tard, de nombreux fournisseurs avaient déjà développé leurs extensions de langage. Ainsi, SQL s'est retrouvé dans des dizaines de dialectes. C'est pourquoi les applications ne sont pas portables et c'est l'une des raisons pour lesquelles il faut disposer d'une couche d'abstraction de la base de données.

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

Answer 2

En dehors de tout ce qui a été dit, une technologie n'a pas besoin d'être mauvaise pour qu'une couche d'abstraction ait de la valeur .

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 à la base de données dans un ou plusieurs modules séparés est une bonne pratique et il en va de même pour l'isolation de votre code SQL. Cela améliore la lisibilité, la maintenabilité et la testabilité de votre code. Cela vous permet d'adapter rapidement votre système aux changements du modèle de base de données sans avoir à interrompre tous les éléments de haut niveau, etc.

SQL est génial. Les couches d'abstraction qui le recouvrent le rendent encore meilleur !

Answer 3

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

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

Answer 4

SQL est critiqué par plusieurs sources :

• Les programmeurs qui ne sont pas à l'aise avec autre chose qu'un langage impératif.
• Les consultants qui doivent quotidiennement faire face à de nombreux produits SQL incompatibles.
• Les fournisseurs de bases de données non relationnelles tentent de briser la mainmise des fournisseurs de bases de données relationnelles sur le marché.
• Les experts en bases de données relationnelles comme Chris Date qui considèrent que les implémentations actuelles de SQL sont insuffisantes.

Si vous vous en tenez à un seul produit SGBD, je suis tout à fait d'accord pour dire que les bases de données SQL sont plus polyvalentes et de meilleure qualité que leurs concurrentes, 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 conserver des données comptables organisées et cohérentes ?

La critique de SQL est souvent un synonyme de critique des SGBDR. Ce que les détracteurs des SGBDR ne semblent pas comprendre, c'est qu'ils résolvent très bien une énorme catégorie de problèmes informatiques et qu'ils sont là pour nous faciliter la vie, et non la compliquer.

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

Answer 5

Ce n'est pas si terrible. C'est une tendance malheureuse dans ce secteur que de mettre au rebut la technologie fiable précédente lorsqu'un nouveau "paradigme" apparaît. En fin de compte, 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, disposer d'une couche d'abstraction "standard" signifie qu'un développeur peut se concentrer sur le code de l'application et non sur le code SQL. Sans une telle couche standard, vous écrirez probablement une couche légère à chaque fois que vous développerez un système, ce qui est un gaspillage d'efforts.