Pourquoi utiliser une base de données SQL ?

Question

Je ne suis pas sûr que stackoverflow soit un endroit pour une question aussi générale, mais essayons.

Ayant été exposé à la nécessité de stocker des données d'application quelque part, j'ai toujours utilisé MySQL ou sqlite, simplement parce que c'est toujours fait comme ça. Comme il semble que le monde entier utilise ces bases de données (la plupart des produits logiciels, des frameworks, etc.), il est assez difficile pour un développeur débutant comme moi de commencer à se demander si c'est une bonne solution ou non.

Ok, disons que nous avons une logique orientée objet dans notre application, et que les objets sont liés les uns aux autres d'une manière ou d'une autre. Nous devons faire correspondre cette logique à la logique de stockage, donc les relations entre les objets de la base de données sont également nécessaires. Cela nous amène à utiliser une base de données relationnelle, et je suis d'accord avec cela - pour faire simple, les lignes de notre table de base de données devront parfois avoir des références aux lignes d'autres tables. Mais pourquoi utiliser le langage SQL pour interagir avec une telle base de données ?

La requête SQL est un message texte. Je peux comprendre que c'est cool pour comprendre réellement ce qu'il fait, mais n'est-ce pas idiot d'utiliser des noms de tables et de colonnes en texte pour une partie de l'application que personne ne verra jamais après le déploiement ? Si vous aviez dû écrire un stockage de données à partir de zéro, vous n'auriez jamais utilisé ce genre de solution. Personnellement, j'aurais utilisé un bytecode de 'requête db compilée', qui serait assemblé une fois dans une application client et transmis à la base de données. Et il aurait sûrement nommé les tables et les colonnes par des numéros d'identification, et non par des chaînes ascii. Dans le cas de changements dans la structure des tables, ces requêtes en octet pourraient être recompilées selon le nouveau schéma de la base de données, stockées en XML ou quelque chose comme ça.

Quels sont les problèmes de mon idée ? Y a-t-il une raison pour que je ne l'écrive pas moi-même et que j'utilise plutôt une base de données SQL ?

EDIT Pour que ma question soit plus claire. La plupart des réponses affirment que SQL, étant une requête texte, aide les développeurs à mieux comprendre la requête elle-même et à la déboguer plus facilement. Personnellement, cela fait un moment que je ne vois plus de personnes écrire des requêtes SQL à la main. Tous ceux que je connais, y compris moi, utilisent des ORM. Cette situation, dans laquelle nous construisons un nouveau niveau d'abstraction pour cacher le SQL, nous amène à nous demander si nous avons besoin du SQL ou non. Je vous serais très reconnaissant si vous pouviez donner quelques exemples dans lesquels SQL est utilisé sans ORM à dessein, et pourquoi.

EDIT2 SQL est une interface entre un humain et une base de données. La question est pourquoi devons-nous l'utiliser pour l'interaction application/base de données ? Je demande toujours des exemples d'êtres humains écrivant/déboguant du SQL.

Answer 1

Tous ceux que je connais, y compris moi, utilisent des ORM.

Étrange. Tous ceux que je connais, y compris moi, écrivent encore la plupart du SQL à la main. Vous obtenez généralement des requêtes plus précises et plus performantes qu'avec une solution générée. Et, en fonction de votre secteur d'activité et de votre application, cette rapidité fait matière. Parfois beaucoup. Oui, j'utiliserai parfois LINQ pour une opération rapide où je ne me soucie pas vraiment de l'aspect du SQL résultant, mais jusqu'à présent, rien d'automatisé ne vaut un SQL ajusté à la main lorsque les performances contre une grande base de données dans un environnement à forte charge sont vraiment importantes.

Answer 2

Si tout ce dont vous avez besoin est de stocker certaines données d'application quelque part, alors un SGBDR général ou même SQLite peut être excessif. Dans certains cas, il est plus simple de sérialiser vos objets et de les écrire dans un fichier. Un avantage de SQLite est que si vous avez beaucoup d'informations de ce type, elles sont toutes contenues dans un seul fichier. L'inconvénient est qu'il est plus difficile de les lire. Par exemple, si vous sérialisez vos données en YAML, vous pouvez lire le fichier avec n'importe quel éditeur de texte ou shell.

Personnellement, j'aurais utilisé un bytecode de 'requête db compilée', qui serait qui serait assemblé une fois dans une application cliente et transmis à la base de données.

C'est ainsi que fonctionnent certaines API de base de données. Consultez le SQL statique et les instructions préparées.

Y a-t-il une raison pour que je ne l'écrire moi-même et d'utiliser une base de à la place ?

Si vous avez besoin de nombreuses fonctionnalités, il sera plus facile à un moment donné d'utiliser un SGBDR existant que d'écrire votre propre base de données en partant de zéro. Si vous n'avez pas besoin de nombreuses fonctionnalités, une solution plus simple peut être plus judicieuse.

L'intérêt des produits de base de données est d'éviter d'écrire la couche de base de données pour chaque nouveau programme. Oui, un SGPD moderne n'est pas toujours parfaitement adapté à chaque projet. C'est parce qu'ils ont été conçus pour être très généraux, donc en pratique, vous obtiendrez toujours des fonctionnalités supplémentaires dont vous n'avez pas besoin. Cela ne signifie pas pour autant qu'il est préférable de disposer d'une solution personnalisée. Le gant ne doit pas toujours être parfaitement adapté.

UPDATE :

Mais pourquoi utiliser le langage SQL pour l'interaction avec une telle base de données ?

Bonne question.

La réponse à cette question se trouve dans le document original décrivant le modèle relationnel. Un modèle relationnel de données pour les grandes banques de données partagées par E. F. Codd, publié par IBM en 1970. Cet article décrit les problèmes posés par les technologies de base de données existantes à l'époque et explique pourquoi le modèle relationnel est supérieur.

La raison de l'utilisation du modèle relationnel, et donc d'un langage d'interrogation logique comme SQL, est l'indépendance des données.

L'indépendance des données est définie dans le document comme suit :

"... l'indépendance des programmes d'application et des activités des terminaux par rapport à la croissance des types de données et aux changements dans les représentations des données."

Avant le modèle relationnel, la technologie dominante pour les bases de données était appelée le modèle réseau. Dans ce modèle, le programmeur devait connaître la structure des données sur le disque et parcourir l'arbre ou le graphe manuellement. Le modèle relationnel permet d'écrire une requête sur le schéma conceptuel ou logique qui est indépendant de la représentation physique des données sur le disque. Cette séparation du schéma logique du schéma physique est la raison pour laquelle nous utilisons le modèle relationnel. Pour en savoir plus sur cette question, ici sont des diapositives d'un cours sur les bases de données. Dans le modèle relationnel, nous utilisons des langages d'interrogation basés sur la logique, comme SQL, pour récupérer des données. L'article de Codd explique plus en détail les avantages du modèle relationnel. Lisez-le.

SQL est un langage d'interrogation facile à taper sur un ordinateur, contrairement aux langages d'interrogation généralement utilisés dans les documents de recherche. Les documents de recherche utilisent généralement l'algèbre de relation ou le calcul relationnel pour écrire les requêtes.

En résumé, nous utilisons SQL parce qu'il se trouve que nous utilisons le modèle relationnel pour nos bases de données.

Si vous comprenez le modèle relationnel, il n'est pas difficile de comprendre pourquoi SQL est tel qu'il est. En gros, vous devez étudier le modèle relationnel et les internes de la base de données plus en profondeur pour vraiment comprendre pourquoi nous utilisons SQL. Sinon, c'est un peu un mystère.

UPDATE 2 :

SQL est une interface entre un humain et une base de données. La question est de savoir pourquoi devons-nous l'utiliser pour l'interaction application/base de données ? I demande toujours des exemples d'êtres humains écrivant/débuguant SQL.

Comme la base de données est une base de données relationnelle, elle ne comprend que les langages d'interrogation relationnels. En interne, elle utilise un langage semblable à l'algèbre relationnelle pour spécifier les requêtes qu'elle transforme ensuite en un plan de requête. Ainsi, nous écrivons notre requête sous une forme que nous pouvons comprendre (SQL), la base de données prend notre requête SQL et la transforme en son langage de requête interne. Ensuite, elle prend la requête et essaie de trouver un "plan de requête" pour exécuter la requête. Enfin, elle exécute le plan de requête et renvoie le résultat.

À un moment donné, nous devons encoder notre requête dans un format que la base de données comprend. La base de données ne sait que convertir SQL en sa représentation interne, c'est pourquoi il y a toujours du SQL à un moment donné de la chaîne. On ne peut pas l'éviter.

Lorsque vous utilisez un ORM, vous ajoutez simplement une couche par-dessus le SQL. Le SQL est toujours là, il est juste caché. Si vous disposez d'une couche de niveau supérieur pour traduire votre requête en SQL, vous n'avez pas besoin d'écrire directement du SQL, ce qui est bénéfique dans certains cas. Parfois, nous ne disposons pas d'une telle couche capable d'effectuer les types de requêtes dont nous avons besoin, et nous devons donc utiliser le SQL.

Answer 3

Étant donné que vous avez utilisé MySQL et SQLite, je comprends parfaitement votre point de vue. La plupart des SGBD ont des fonctionnalités qui nécessitent une partie de la programmation de votre côté, alors que vous l'obtenez gratuitement de la base de données :

• Indices - vous pouvez stocker de grandes quantités de données tout en étant capable de filtrer et de rechercher très rapidement grâce aux index. Bien sûr, vous pouvez implémenter votre propre indexation, mais pourquoi réinventer la roue ?

• intégrité des données - L'utilisation de fonctionnalités de base de données telles que les clés étrangères en cascade peut garantir l'intégrité des données dans l'ensemble du système. Il vous suffit de déclarer la relation entre les données, et le système s'occupe du reste. Bien sûr, une fois de plus, vous pourriez implémenter les contraintes dans le code, mais cela représente plus de travail. Prenons l'exemple de la suppression, pour laquelle il faudrait écrire du code dans le destructeur de l'objet pour suivre tous les objets dépendants et agir en conséquence.

• capacité à avoir applications multiples écrites dans des langages de programmation différents, fonctionnant sur des systèmes d'exploitation différents, certaines étant même distribuées sur le réseau - toutes utilisant l'application mêmes données stockées dans une base de données commune

• mise en œuvre très facile de Schéma d'observation via des déclencheurs. Il existe de nombreux cas où seules certaines données dépendent d'autres données et où cela n'affecte pas l'interface utilisateur de l'application. Assurer la cohérence peut être très délicat ou nécessiter beaucoup de programmation. Bien sûr, vous pouvez mettre en œuvre un comportement de type déclencheur avec des objets, mais cela nécessite plus de programmation qu'une simple définition SQL.

Answer 4

• C'est une norme omniprésente. Presque tous les langages de programmation ont un moyen d'accéder aux bases de données SQL. Essayez ça avec un protocole binaire propriétaire.
• Tout le monde le sait. Vous pouvez trouver des experts facilement, les nouveaux développeurs le comprendront généralement dans une certaine mesure sans avoir besoin de formation.
• SQL est très étroitement lié au modèle relationnel, qui a fait l'objet d'une étude approfondie en matière d'optimisation et d'évolutivité. Mais il nécessite encore fréquemment des ajustements manuels (création d'index, structure des requêtes, etc.), ce qui est relativement facile grâce à l'interface textuelle.

Answer 5

Mais pourquoi utiliser le langage SQL pour interagir avec une telle base de données ?

Je pense que c'est pour la même raison que vous utilisez un langage lisible par l'homme (code source) pour l'interaction avec le compilateur.

Personnellement, j'aurais utilisé un bytecode de "requête db compilée", qui serait assemblé une fois dans une application client et transmis à la base de données.

Il s'agit d'une fonctionnalité existante (facultative) des bases de données, appelée "procédures stockées".

---

Edit :

Je vous serais très reconnaissant si vous pouviez donner des exemples dans lesquels SQL est utilisé sans ORM à dessein, et pourquoi

Lorsque j'ai implémenté mon propre ORM, j'ai implémenté le cadre ORM en utilisant ADO.NET : et l'utilisation d'ADO.NET inclut l'utilisation d'instructions SQL dans son implémentation.