Pourquoi les bases de données relationnelles acceptent-elles uniquement les requêtes SQL?


15

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?


14
Que fait votre premier exemple qu'un ORM ne fournit pas déjà?
Robert Harvey

4
Votre chemin fonctionnerait très bien si la seule chose que quelqu'un ait jamais faite était de simples requêtes.
Blrfl

5
@RobertHarvey Rien. Mais il doit être converti en SQL. Le point de ma question est pourquoi ne pouvons-nous pas avoir accès au niveau du conducteur aux opérations de manipulation de données.
lortabac

20
Pour moi, c'est comme demander pourquoi les grille-pain n'acceptent pas la crème glacée.
HLGEM

2
Quelqu'un a déjà pensé à ce que vous pensez et est allé plus loin et les ORM sont donc nés.
The Muffin Man

Réponses:


33

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.


17
Je ne suis pas d'accord sur la création manuelle de commandes SQL. Les ORM conviennent parfaitement aux modèles de données très simplistes. Au-delà de trivial, vous écrivez votre propre couche SQL.
Martin York

2
Je jouerai l'avocat du diable et je noterai que tout ORM raisonnable devrait être configurable pour répondre aux besoins d'une application.
bunglestink

7
@LokiAstari: C'est vrai, mais les trucs triviaux CRUD peuvent représenter 80% ou plus de votre application.
Robert Harvey

@Tim, excellent point. En fait, la syntaxe hypothétique proposée dans la question ressemble énormément à JSON.
John M Gant

JSON est un format d'encapsulation et de transfert de données, pas une langue.
Craig

35

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.


7

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


Le code .NET dans SQL Server ne s'exécute pas réellement dans le moteur de base de données. Il s'agit du code .NET compilé dans un assembly sur le serveur et les procédures stockées sont attribuées à des méthodes de classe statique que le serveur de base de données sait appeler. Les méthodes utilisent un fournisseur de données et établissent une connexion à la base de données comme tout autre code .NET. Vous avez une situation similaire avec des bases de données (Oracle, Sybase) qui prennent en charge les procédures stockées Java. SQL, d'autre part, est "l'interface native" de la base de données, est similaire dans la plupart des produits de base de données et est en fait analysé et exécuté directement dans la base de données.
Craig

@Craig - Excellent point.
JeffO

3

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.

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.