Je n'apprendrai pas votre langue de requête

Ce sera un peu délirant, mais je suis vraiment ennuyé par un logiciel dans lequel les gens essaient d'inventer leur propre langage de requête. Nous avons déjà un billion d'ORM différents, un autre billion de bases de données avec notre propre langage de requête chacune, et un autre billion de produits SaaS, pour l'accès auquel vous devez maîtriser certains DSL réguliers qu'ils ont inventés.

Rendez-moi mon SQL. Cette langue est compréhensible par tout le monde, existe déjà à partir des années 70 et pendant ce temps a réussi à devenir une norme. Il est facile à lire et peut être utilisé par n'importe qui, des entreprises aux ingénieurs.

Cependant, au lieu de cela, je dois apprendre tout un tas de différents "langage de requête poubelle" parce que les gens essaient toujours de réinventer la roue.

Commençons par ORM. Leur principale caractéristique est une réduction du temps de développement. Mais au lieu d'écrire du SQL compréhensible pour tout le monde, je dois étudier la documentation d'un ORM spécifique pour comprendre comment écrire mes requêtes pour celui-ci. De plus, je dois passer du temps à déboguer pour savoir pourquoi cet ORM a traduit ma requête en un SQL monstrueux qui joint 17 tables à l'aide de leur analyse complète. Au lieu de s'en tenir au SQL standard, où il est assez facile de parler d'efficacité («essayez d'utiliser des colonnes indexées dans les prédicats», «n'en faites pas trop avec les jointures dans une requête», etc.), je dois faire face à une couche boueuse supplémentaire, qui masque la requête SQL d'origine. À la fin, vous vous retrouverez avec des classes de données gonflées de niveau supérieur, au lieu de traiter avec des structures de base de données faciles à comprendre et à traiter.

Sans oublier qu'il y a environ cinq mille ORM, donc au lieu d'apprendre le SQL, une fois que je dois apprendre 34 ORM différents. Cela ne signifie pas que les gens apprennent l'ORM, cela signifie qu'ils n'apprennent tout simplement pas le SQL.

Et tous ces produits SaaS. Je viens d'en choisir quelques-uns dans la pile de ma société:

• Splunk - SPL
• Mixpanel - JQL
• Rollbar - RQL
• Nouvelle relique - NRQL
• Adwords - AWQL

Quoi de pire qu'un vidage de données? Un vidage de données qui invente son propre langage de requête.

En toute honnêteté, il faut dire que certaines de ces requêtes sont toujours de type SQL, ou du moins revendiquent ce rôle, mais avec leurs propres bizarreries qui me font ignorer tout ce que je savais sur SQL auparavant. Parfois à tel point que ce sont ces connaissances passées qui peuvent s'avérer pratiquement sans valeur.

De plus, chaque base de données essaie également de réinventer le langage de requête. Mongo a son propre langage de requête terrible , que je n'ai jamais compris, Lucene a le sien , etc.

Qu'est-ce que je demande? Pas vraiment beaucoup:

1. Chaque produit SaaS devrait permettre de copier toutes les données dans ma propre base de données SQL (dans mon cas Postgresql / Redshift). Je ne veux pas utiliser leur DSL. L'Union européenne pourra peut-être en faire une nouvelle exigence après l'adoption de la directive sur les services bancaires ouverts PSD2 .
2. Un moratoire de 30 ans sur l’invention de nouveaux langages de requête est nécessaire.
3. Nous devons dissiper le mythe selon lequel les ORM rendent le code plus propre. Passez au SQL pur et vous obtiendrez une interaction beaucoup plus simple et plus transparente avec votre base de données.

C’est tout. Je comprends que je suis comme un vieux grognon, mais je prends ce risque pour moi.

PS

Ce poste a reçu un nombre suffisant de vues, il devrait donc susciter un vif intérêt auprès du public. Suivez la discussion sur Hacker News et les commentaires sur Reddit r / programmation .