Pour autant que je sache, la plupart des bases de données relationnelles ne proposent aucune API de niveau pilote pour les requêtes, à l'exception d'une queryfonction qui prend une chaîne SQL comme argument.
Je pense à quel point il serait plus facile de faire:
var result = mysql.select('article', {id: 3})Pour les tables jointes, ce serait un peu plus complexe, mais toujours possible. Par exemple:
var tables = mysql.join({tables: ['article', 'category'], on: 'categoryID'});
mysql.select(tables, {'article.id': 3}, ['article.title', 'article.body', 'category.categoryID'])Code plus propre, pas de surcharge d'analyse de chaîne, pas de problèmes d'injection, réutilisation plus facile des éléments de requête ... Je peux voir beaucoup d'avantages.
Y a-t-il une raison spécifique pour laquelle il a été choisi de ne fournir l'accès aux requêtes que via SQL?
Réponses:
Les bases de données sont hors processus - elles s'exécutent généralement sur un serveur différent. Donc, même si vous aviez une API, elle aurait besoin d'envoyer quelque chose sur le fil qui représente votre requête et toutes ses projections, filtres, groupes, sous-requêtes, expressions, jointures, fonctions d'agrégation, etc. Ce quelque chose pourrait être XML ou JSON ou certains format propriétaire, mais il peut aussi bien s'agir de SQL car il est essayé, testé et pris en charge.
Il est moins courant de nos jours de créer des commandes SQL vous-même - de nombreuses personnes utilisent une sorte d'ORM. Même si celles-ci se traduisent finalement par des instructions SQL, elles peuvent fournir l'API que vous recherchez.
la source
Parce que SQL fournit une API commune. Vous pouvez écrire un pilote compatible ANSI 92 SQL qui émet SQL et expose l'API que vous désirez. En prime, il fonctionnera avec presque toutes les bases de données SQL sans réécriture.
Si cela était fait à votre façon, chaque base de données SQL aurait une API différente. À moins, bien sûr, que nous ayons tous normalisé votre API. Mais alors, nous aurions à nouveau SQL, plus ou moins, n'est-ce pas? Sauf que votre API semble être spécifique au langage de programmation, contrairement à SQL.
la source
Il y a plus à faire sur la base de données à des fins administratives, il est donc important de pouvoir écrire un script et soumettre du texte pour ajouter des utilisateurs, exécuter des sauvegardes, charger des données, modifier le schéma, etc. La plupart des administrateurs de bases de données ne voudront pas faire cela dans un autre langage de programmation.
Si les administrateurs de bases de données veulent conserver SQL, vous devez avoir une autre langue, la base de données aurait la charge de traiter les deux.
Il y a beaucoup de nouvelles fonctionnalités dans les bases de données, donc je ne pense pas qu'elles stagnent. Ils ne font tout simplement pas ce que vous proposez pour une raison quelconque.
SQL Server a la possibilité d'exécuter du code .NET de l'intérieur via SQL CLR. Cela est utile pour certaines de ces tâches qui ne rentrent pas dans un modèle relationnel, mais qui souhaitent maintenir les performances. Je réalise que ce n'est pas ce que tu cherches. C'est un exemple des nombreuses choses que les bases de données font.
Cela ne va pas disparaître de sitôt. NuoDB est l'une des bases de données les plus récentes à arriver sur le marché . Ils ont conservé SQL, fourni ACID tout en ajoutant la possibilité de distribuer des serveurs et de l'exécuter dans un cloud. Vous voudrez peut-être voir pourquoi ils se sont donné tant de mal pour promouvoir la poursuite de SQL (ce n'est pas leur seule raison, mais c'est un énorme argument de vente.).
la source
Le SGBD SQL fournit un accès considérablement optimisé au magasin via la langue maternelle et beaucoup d'autres, comme vous le notez, ne fournit aucune autre API.
L'observation selon laquelle la base de données n'est pas en cours de traitement ne s'applique pas dans un certain nombre de cas et n'est pas vraiment directement pertinente.
Même les bases de données qui nécessitent l'utilisation de SQL DML fournissent souvent une bibliothèque de curseurs pour fournir un accès itérateur à un ensemble de résultats, et les fameux SGBD Microsoft Access et Btrieve SQL fournissent tous deux une interface d'enregistrement directe vers les tables individuelles d'une base de données comme mécanisme. pour un accès très performant dans des circonstances spécifiques.
Comme indiqué, les requêtes complexes utilisant une telle syntaxe reproduiraient le comportement des bases de données réseau de la fin des années 70.
Les mécanismes d'accès alternatifs sont moins attrayants pour les utilisateurs traditionnels en raison de leur méconnaissance, mais la croissance de la popularité des bases de données NoSQL pourrait accroître l'intérêt pour d'autres API pour obtenir des gains de performances spécifiques. Il ne semble guère y avoir d'autre recommandation pour une telle approche.
la source