Pourquoi utiliser une base de données SQL?
Je ne suis pas sûr que stackoverflow soit un lieu pour une question aussi générale, mais essayons.
Étant exposé au besoin de stocker les 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 (principalement des produits logiciels, des frameworks, etc.), il est plutôt difficile pour un développeur débutant comme moi de commencer à se demander si cette solution est bonne ou non.
Ok, supposons que nous ayons une logique orientée objet dans notre application et que les objets soient liés les uns aux autres. Nous devons mapper cette logique sur la logique de stockage afin que des relations entre les objets de base de données soient également requises. Cela nous amène à utiliser une base de données relationnelle, ce qui me convient parfaitement. En d'autres termes, les lignes de notre table de base de données devront parfois comporter 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 bien de vraiment comprendre ce qu’il fait, mais n’est-il pas idiot d’utiliser des noms de table de texte et de colonne pour une partie de l’application que personne n’a jamais vue après le déploiement? Si vous deviez écrire un stockage de données à partir de rien, vous n'auriez jamais utilisé ce type de solution. Personnellement, j'aurais utilisé un bytecode 'Compilation db query', qui serait assemblé une fois dans une application client et transmis à la base de données. Et il nommerait sûrement les tables et les deux-points par leur numéro d'identification, et non par des chaînes de caractères ascii. Dans le cas de modifications de la structure de la table, ces requêtes d'octets pourraient être recompilées en fonction du nouveau schéma de base de données, stockées au format XML ou quelque chose du genre.
Quels sont les problèmes de mon idée? Y at-il une raison pour que je ne l'écris pas moi-même et que j'utilise plutôt une base de données SQL?
EDITPour clarifier ma question. La plupart des réponses prétendent que SQL, en tant que requête texte, aide les développeurs à mieux comprendre la requête elle-même et à la déboguer plus facilement. Personnellement, je n'ai pas vu de gens écrire des requêtes SQL à la main depuis un moment. Toutes les personnes que je connais, y compris moi, utilisent ORM. Cette situation, dans laquelle nous construisons un nouveau niveau d'abstraction pour masquer le SQL, amène à penser si nous avons besoin de SQL ou non. Je vous serais très reconnaissant de bien vouloir 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 code SQL.
Si tout ce que vous avez à faire est de stocker des données d’application quelque part, un SGBDR à usage général ou même SQLite risque d’être excessif. Sérialiser vos objets et les écrire dans un fichier peut être plus simple dans certains cas. Un avantage de SQLite est que si vous avez beaucoup de ce type d’informations, elles sont toutes contenues dans un seul fichier. Un inconvénient est qu'il est plus difficile de le 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é certains bytecode 'Compilation db query', que serait assemblé une fois dans un application cliente et transmise au base de données.
Voici comment fonctionnent certaines API de base de données. Découvrez le SQL statique et les instructions préparées.
Y a-t-il une raison pour que je ne le fasse pas écris-le moi-même et utilise SQL base de données à la place?
Si vous avez besoin de nombreuses fonctionnalités, il sera plus facile d’utiliser un RDMBS existant que de créer votre propre base de données à partir de rien. 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 base de données pour chaque nouveau programme. Oui, un SGBDR moderne ne convient pas toujours parfaitement à chaque projet. En effet, ils ont été conçus pour être très généraux. En pratique, vous obtiendrez toujours des fonctionnalités supplémentaires dont vous n’avez pas besoin. Cela ne signifie pas qu'il est préférable d'avoir une solution personnalisée. Le gant n'a pas toujours besoin d'un ajustement parfait.
METTRE À JOUR:
Mais pourquoi utiliser le langage SQL pour 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 de grandes banques de données partagées , par EF Codd, publié par IBM en 1970. Ce document décrit les problèmes liés aux technologies de base de données existantes. du temps, et explique pourquoi le modèle relationnel est supérieur.
L'indépendance des données est la raison d'utiliser le modèle relationnel, et donc un langage de requête logique comme SQL.
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 vis-à-vis de la croissance des types de données et des modifications apportées à la représentation des données."
Avant le modèle relationnel, la technologie dominante pour les bases de données était appelée modèle de réseau. Dans ce modèle, le programmeur devait connaître la structure des données sur disque et parcourir manuellement l’arbre ou le graphique. Le modèle relationnel permet d’écrire une requête sur le schéma conceptuel ou logique indépendant de la représentation physique des données sur le disque. Cette séparation du schéma logique et 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'une classe de base de données. Dans le modèle relationnel, nous utilisons des langages de requête basés sur la logique, tels que SQL, pour extraire des données . L'article de Codd décrit plus en détail les avantages du modèle relationnel. Donnez-lui une lecture.
SQL est un langage d'interrogation facile à saisir sur un ordinateur, contrairement aux langages d'interrogation généralement utilisés dans les documents de recherche. Les articles de recherche utilisent généralement l'algèbre des relations ou le calcul relationnel pour rédiger des requêtes.
En résumé, nous utilisons SQL car 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 ce qu’il est. En gros, vous devez donc étudier plus en profondeur le modèle de relation et les éléments internes de la base de données pour bien comprendre pourquoi nous utilisons SQL. Sinon, cela pourrait être un mystère.
UPDATE 2:
SQL est une interface entre un humain et une base de données. La question est pourquoi faire nous devons l'utiliser pour interaction application/base de données? JE demandez toujours des exemples d’êtres humains écriture/débogage SQL.
Comme la base de données est une base de données relationnelle, elle ne comprend que les langages de requête relationnels. En interne, il utilise un langage de type algèbre relationnelle pour spécifier des requêtes qu'il transforme ensuite en un plan de requête. Donc, 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, il prend la requête et essaie de trouver un "plan de requête" pour exécuter la requête. Ensuite, il exécute le plan de requête et renvoie le résultat.
À un moment donné, nous devons coder notre requête dans un format compris par la base de données. La base de données ne sait convertir que SQL en sa représentation interne, c'est pourquoi il y a toujours du SQL à un moment donné de la chaîne. Cela ne peut être évité.
Lorsque vous utilisez ORM, vous ajoutez simplement une couche au-dessus du code SQL. Le SQL est toujours là, il est juste caché. Si vous avez une couche de niveau supérieur pour la traduction de votre demande en SQL, vous n'avez pas besoin d'écrire directement en SQL, ce qui est avantageux dans certains cas. Parfois, nous n’avons pas une telle couche capable de faire le type de requêtes dont nous avons besoin, nous devons donc utiliser SQL.
Toutes les personnes que je connais, y compris moi-même, utilisent ORM
Étrange. Toutes les personnes que je connais, y compris moi, écrivent encore la plupart du code SQL à la main. Vous vous retrouvez généralement avec des requêtes plus strictes et plus performantes qu'avec une solution générée. Et, selon votre secteur d'activité et votre application, cette vitesse est importante. Parfois beaucoup. Ouais, je vais parfois utiliser LINQ pour un quick-n-dirty où je ne me soucie pas vraiment de ce à quoi ressemble le résultat SQL, mais jusqu'à présent, rien ne vaut le code SQL ajusté à la main pour les performances d'une grande L'environnement de chargement compte vraiment.
Étant donné que vous avez utilisé MySQL et SQLite, je comprends tout à fait votre point de vue. La plupart des SGBD ont des fonctionnalités qui nécessiteraient une partie de la programmation de votre part, alors que vous les obtenez gratuitement depuis la base de données:
Indexes - vous pouvez stocker de grandes quantités de données tout en conservant la possibilité 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 fonctions de base de données telles que les clés étrangères en cascade permet d'assurer l'intégrité des données sur l'ensemble du système. Il 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 pouvez implémenter des contraintes dans le code, mais cela demande plus de travail. Pensez, par exemple, à la suppression, où vous devez écrire du code dans le destructeur de l'objet pour suivre tous les objets dépendants et agir en conséquence.
possibilité d'avoir plusieurs applications écrites dans différents langages de programmation, fonctionnant sous différents systèmes d'exploitation, certains même répartis sur le réseau - toutes utilisant les mêmes données stockées dans une base de données commune
implémentation simple et facile du motif observateur via des déclencheurs. Il existe de nombreux cas où seules certaines données dépendent d'autres données et n'affectent pas l'aspect de l'interface utilisateur de l'application. Assurer la cohérence peut être très délicat ou demander beaucoup de programmation. Bien sûr, vous pouvez implémenter un comportement semblable à un déclencheur avec des objets, mais cela nécessite plus de programmation qu'une simple définition SQL.
Il y a quelques bonnes réponses ici. Je vais essayer d'ajouter mes deux cents.
J'aime SQL, je peux y penser assez facilement. Les requêtes produites par les couches situées au-dessus de la base de données (comme les frameworks ORM) sont généralement hideuses. Ils choisiront des tonnes de choses supplémentaires, se joindront à des choses inutiles, etc. tout cela parce qu'ils ne savent pas que vous ne voulez qu'une petite partie de l'objet dans ce code. Lorsque vous avez besoin de hautes performances, vous finissez souvent par utiliser au moins certaines requêtes SQL personnalisées dans un système ORM, juste pour accélérer quelques goulots d'étranglement.
Pourquoi SQL? Comme d'autres l'ont dit, c'est facile pour les humains. Cela constitue un bon plus petit dénominateur commun. N'importe quelle langue peut créer du code SQL et appeler des clients en ligne de commande si nécessaire. C'est toujours une bonne bibliothèque.
L'analyse SQL est-elle inefficace? Quelque peu. La grammaire est assez structurée, il n'y a donc pas beaucoup d'ambiguïtés qui rendraient le travail de l'analyseur vraiment difficile. La vraie chose est que la surcharge de l'analyse SQL n'est fondamentalement rien.
Supposons que vous exécutiez une requête du type "SELECT x FROM table WHERE id = 3", puis recommencez avec 4, puis 5, encore et encore. Dans ce cas, la surcharge d'analyse peut exister. C'est pourquoi vous avez préparé des déclarations (comme d'autres l'ont mentionné). Le serveur analyse la requête une fois et peut permuter entre 3 et 4 et 5 sans avoir à tout réparer.
Mais c'est le cas trivial. Dans la vraie vie, votre système peut joindre 6 tables et devoir extraire des centaines de milliers d'enregistrements (sinon plus). Il peut s'agir d'une requête que vous laissez s'exécuter sur un cluster de bases de données pendant des heures, car c'est la meilleure façon de procéder dans votre cas. Même avec une requête dont l'exécution ne prend qu'une minute ou deux, le temps d'analyse de la requête est essentiellement gratuit comparé à l'extraction des enregistrements sur le disque et au tri/agrégation/etc. L'envoi de l'extension "LEFT OUTER JOIN ON" ne représente qu'une surcharge de quelques octets par rapport à l'envoi de l'octet codé spécial 0x3F. Mais lorsque votre jeu de résultats est de 30 Mo (sans parler de concerts +), ces quelques octets supplémentaires sont sans valeur, au lieu de ne pas avoir à jouer avec un objet spécial du compilateur de requête.
Beaucoup de gens utilisent SQL sur de petites bases de données. Le plus gros avec lequel je suis en contact n’est que quelques dizaines de concerts. SQL est utilisé sur tout, des fichiers minuscules (tels que les petites bases de données SQLite) jusqu'aux clusters Oracle de la taille en téraoctets. Considérant que c'est puissant, c'est en fait un jeu de commandes étonnamment simple et petit.
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 les interactions avec le compilateur.
Personnellement, j'aurais utilisé un bytecode 'Compilation db query', 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".
Modifier:
Je vous serais très reconnaissant de bien vouloir donner quelques exemples dans lesquels SQL est utilisé à dessein sans ORM, et pourquoi
Lorsque j'ai implémenté mon propre ORM, j'ai implémenté le framework ORM avec ADO.NET: et utiliser ADO.NET inclut l'utilisation d'instructions SQL dans son implémentation.
- 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 cela avec un protocole binaire propriétaire.
- Tout le monde le sait. Vous pouvez facilement trouver des experts, les nouveaux développeurs le comprendront généralement sans nécessiter de formation.
- SQL est très étroitement lié au modèle relationnel, qui a été étudié de manière approfondie en termes d’optimisation et d’évolutivité. Mais cela nécessite encore fréquemment des ajustements manuels (création d'index, structure de requête, etc.), ce qui est relativement facile grâce à l'interface textuelle.
Après toutes les modifications et tous les commentaires, l’essentiel de votre question semble être le suivant: pourquoi la nature de SQL est-elle plus proche d’une interface homme/base de données que d’une interface application/base de données?
Et la réponse très simple à cette question est: parce que c’est exactement ce à quoi il était destiné à l’origine.
Les prédécesseurs de SQL (QUEL étant sans doute le plus important) étaient exactement ce qu’il était: un langage QUERY, c’est-à-dire dépourvu d’INSERT, UPDATE, DELETE.
En outre, il était censé être un langage de requête pouvant être utilisé par tout utilisateur, à condition que celui-ci connaisse la structure logique de la base de données et sache évidemment comment exprimer cette structure logique dans le langage de requête qu'il utilisait.
L'idée de base de QUEL/SQL était qu'une base de données avait été construite en utilisant "n'importe quel mécanisme imaginable", que la "vraie" base de données pouvait être vraiment n'importe quoi (par exemple, un seul fichier XML gigantesque, bien que "XML" n'ait pas été considéré comme une option valide à l’époque), et qu’il y aurait "une sorte de machine" qui comprendrait comment transformer la structure réelle de ce "n'importe quoi" en une structure relationnelle logique telle qu’elle était perçue par l’utilisateur SQL.
Le fait que, pour y parvenir, les structures sous-jacentes doivent se prêter à une "vision relationnelle" n’a pas été compris aussi bien à l’époque qu’aujourd’hui.
Oui, il est embêtant de devoir écrire des instructions SQL pour stocker et récupérer des objets.
C'est pourquoi Microsoft a ajouté des éléments tels que LINQ (requête intégrée au langage) dans C # et VB.NET pour permettre d'interroger des bases de données à l'aide d'objets et de méthodes au lieu de chaînes.
La plupart des autres langues ont quelque chose de similaire avec des niveaux de réussite variables selon les capacités de cette langue.
D'autre part, il est utile de savoir comment fonctionne SQL et je pense que c'est une erreur de s'en protéger entièrement. Si vous utilisez la base de données sans y penser, vous pouvez écrire des requêtes extrêmement inefficaces et indexer la base de données de manière incorrecte. Mais une fois que vous avez compris comment utiliser correctement SQL et que vous avez optimisé votre base de données, vous disposez d'un outil très puissant, éprouvé et testé, qui vous permet de trouver très rapidement les données dont vous avez besoin.
Ma principale raison de SQL est le reporting ad hoc. Ce rapport que vos utilisateurs professionnels veulent mais ne savent pas qu'ils en ont encore besoin.
SQL est une interface commune utilisée par la plate-forme SGBD. L'intérêt principal de l'interface est que toutes les opérations de base de données peuvent être spécifiées en SQL sans nécessiter d'appels d'API supplémentaires. Cela signifie qu'il existe une interface commune à tous les clients du système: logiciels d'application, rapports et outils de requête ad-hoc.
Deuxièmement, SQL devient de plus en plus utile à mesure que les requêtes deviennent plus complexes. Essayez d'utiliser LINQ pour spécifier une jointure à 12 voies a avec trois conditions basées sur des prédicats existentiels et une condition basée sur un agrégat calculé dans une sous-requête. Ce genre de chose est assez compréhensible en SQL mais peu probable dans un ORM.
Dans de nombreux cas, un ORM fera 95% de ce que vous voulez - la plupart des requêtes émises par les applications sont de simples opérations CRUD qu'un ORM ou un autre mécanisme d'interface de base de données générique peut gérer facilement. Certaines opérations sont mieux effectuées à l'aide de code SQL personnalisé.
Cependant, les ORM ne sont pas la solution idéale pour l’interfaçage de bases de données. Patterns of Enterprise Application Architecture de Fowler contient une assez bonne section sur les autres types de stratégie d'accès aux bases de données, avec une discussion des avantages de chacun.
Il y a souvent de bonnes raisons de ne pas utiliser un ORM comme couche d'interface de base de données primaire. Un bon exemple est que les bibliothèques de bases de données de plates-formes telles que ADO.Net font souvent un travail suffisant et s'intègrent bien au reste de l'environnement. Vous constaterez peut-être que le bénéfice tiré de l'utilisation d'une autre interface ne l'emporte pas sur les avantages de l'intégration.
Cependant, la dernière raison pour laquelle vous ne pouvez pas vraiment ignorer SQL est que vous travaillez avec une base de données si vous utilisez une application de base de données. Il y a beaucoup d'histoires WTF sur des erreurs dans le code des applications commerciales faites par des personnes qui ne comprenaient pas bien les bases de données. Un code de base de données mal conçu peut poser problème à bien des égards, et penser joyeusement que vous n'avez pas besoin de comprendre le fonctionnement du SGBD est un acte de Hubris qui ne manquera pas de vous faire mal un jour. Pire encore, il va venir mordre un autre pauvre schmoe qui hérite de votre code.
SQL est une interface entre un humain et une base de données. La question est pourquoi faire nous devons l'utiliser pour interaction application/base de données? JE demandez toujours des exemples d’êtres humains écriture/débogage SQL.
J'utilise souvent sqlite, des tâches les plus simples (comme la journalisation des journaux de mon pare-feu directement dans une base de données sqlite) aux tâches d'analyse et de débogage plus complexes de mes recherches quotidiennes. Disposer mes données dans des tables et écrire des requêtes SQL pour les regrouper de manière intéressante me semble être la chose la plus naturelle dans ces situations.
Sur votre point de savoir pourquoi il est toujours utilisé comme interface entre application/base de données, voici mon raisonnement simple:
Il y a environ 3 ou 4 décennies de Recherches sérieuses dans ce domaine Depuis 1970 avec le document fondamental de Codd Sur l'algèbre relationnelle QLs), bien que SQL ne suive pas complètement le modèle relationnel
La forme "texte" de la langue (à part être facilement compréhensible par les humains) est également facilement analysable par des machines (par exemple en utilisant un analyseur grammatical tel que Lex) et est facilement convertible en n'importe quel "bytecode" en utilisant un nombre quelconque d'optimisations.
Je ne sais pas si faire cela dans aucun autrement aurait cédé convaincant avantages dans les cas génériques. Sinon ça aurait probablement été découvert et adopté au cours des 3 décennies de recherche. SQL fournit probablement le meilleurs compromis pour combler le diviser entre humains/bases de données et applications/bases de données.
La question qu'il devient alors intéressant de se poser est la suivante: "Quels sont les avantages réels de l'utilisation de SQL d'une autre manière" non textuelle "?" Est-ce que google pour cela maintenant :)
Je pense que la prémisse de la question est incorrecte. Que SQL puisse être représenté sous forme de texte est sans importance. La plupart des bases de données modernes ne compilent les requêtes qu'une seule fois et les mettent en cache de toute façon, vous avez donc déjà un «code binaire compilé». Et il n'y a aucune raison pour que cela ne se produise pas du point de vue du client, même si je ne suis pas sûr que quelqu'un l'ait fait.
Vous avez dit que SQL était un message texte, eh bien, je le considère comme un messager et, comme nous le savons, ne lui tirez pas dessus. Le vrai problème est que les relations ne constituent pas un moyen suffisant d'organiser des données réelles. SQL est juste du rouge à lèvres sur le cochon.
Bien que je comprenne votre point de vue, le langage de requête SQL a sa place, en particulier dans les applications volumineuses contenant beaucoup de données. Et pour souligner l'évidence, si le langage n'existait pas, vous ne pourriez pas l'appeler SQL (Structured Query Language). L'avantage d'avoir SQL sur la méthode que vous avez décrite est que SQL est généralement très lisible, bien que certains poussent réellement les limites de leurs requêtes.
Je suis tout à fait d’accord avec Mark Byers, vous ne devez pas vous protéger de SQL. Tout développeur peut écrire en SQL, mais pour que votre application fonctionne vraiment avec l'interaction SQL, il est indispensable de comprendre le langage.
Si tout était pré-compilé avec du code binaire comme vous l'avez décrit, je n'aimerais pas être le seul à devoir déboguer l'application après le départ du développeur d'origine (ou même après ne pas avoir vu le code pendant 6 mois).
Un des principes de conception Unix peut être dit ainsi: "Écrire des programmes pour gérer les flux de texte, car c'est une interface universelle.".
Et c’est pourquoi, je crois, nous utilisons généralement SQL au lieu d’un «byte-SQL» n’ayant qu’une interface de compilation. Même si nous avions un octet-SQL, quelqu'un écrirait un "texte SQL" et la boucle serait complète.
De plus, MySQL et SQLite ont moins de fonctionnalités que, par exemple, MSSQL et Oracle SQL. Donc, vous êtes toujours dans le bas du pool SQL.
En fait, il existe quelques produits de base de données non SQL (comme Objectivity, Oracle Berkeley DB, etc.), mais aucun d’entre eux n’a réussi. À l'avenir, si quelqu'un trouve une alternative intuitive au SQL, cela répondra à votre question.
SQL a été créé pour fournir une interface permettant de faire des requêtes ad hoc sur une base de données relationnelle.
Généralement, la plupart des bases de données relationnelles comprennent une forme de SQL.
Les bases de données orientées objet existent et (probablement) utilisent des objets pour effectuer leurs requêtes ... mais, si je comprends bien, les bases de données OO ont beaucoup plus de risques d'être entendues et les bases de données relationnelles fonctionnent parfaitement.
Les bases de données relationnelles vous permettent également de fonctionner dans un état "déconnecté". Une fois que vous avez les informations demandées, vous pouvez fermer la connexion à la base de données. Avec une base de données OO, vous devez soit renvoyer tous les objets liés à celui en cours (et ceux auxquels ils sont associés ... et le ... etc ...), soit rouvrir la connexion pour en récupérer de nouveaux. objets comme ils sont accédés.
Outre SQL, vous disposez également d'ORM (mappages objet-relationnel) qui mappent des objets sur SQL et inversement. Il y en a beaucoup, notamment LINQ (.NET), le MS Entity Framework (.NET), Hibernate (Java), SQLAlchemy (Python), ActiveRecord (Ruby), Class :: DBI (Perl), etc. .
Si vous parlez de la première partie, vous parlez de ce que l’on appelle habituellement l’impédance de mappage objet-relationnel. Il existe déjà de nombreux cadres pour atténuer ce problème. Il y a aussi des échanges commerciaux. Certaines choses seront plus faciles, d'autres plus complexes, mais dans le cas général, elles fonctionnent bien si vous pouvez vous permettre la couche supplémentaire.
Dans la deuxième partie, vous semblez vous plaindre du fait que SQL est un texte (il utilise des chaînes plutôt que des identifiants, etc.) ... SQL est un langage de requête. Toute langue (ordinateur ou autre) destinée à être lue ou écrite par des humains est orientée texte pour cette matière. Assembly, C, PHP, nommez-le. Pourquoi? Parce que, bon ... ça a du sens, n'est-ce pas?
Si vous voulez des requêtes précompilées, vous avez déjà des procédures stockées. Les déclarations préparées sont également compilées une fois à la volée, IIRC. La plupart (sinon tous) des pilotes de base de données communiquent avec le serveur de base de données via un protocole binaire.
oui, le texte est un peu inefficace. Cependant, obtenir les données coûte beaucoup plus cher, de sorte que SQL basé sur le texte est relativement insignifiant.
Un langage de base de données est utile car il fournit un modèle logique pour vos données, indépendamment des applications qui l'utilisent. SQL présente de nombreuses faiblesses, notamment parce que son intégration avec d’autres langues est médiocre, le support des types a 30 ans de retard sur le reste du secteur et il n’a jamais été un langage réellement relationnel.
SQL a survécu principalement parce que le marché des bases de données a été et reste dominé par les trois méga-vendeurs qui ont tout intérêt à protéger leurs investissements. Cela change et les jours de SQL sont probablement numérotés, mais le modèle qui le remplacera ne sera probablement pas encore arrivé - bien qu'il y ait beaucoup de prétendants autour de ces jours.
Je ne pense pas que la plupart des gens comprennent votre question, même si je pense que c'est très clair. Malheureusement, je n'ai pas la réponse "correcte". Je suppose que c'est une combinaison de plusieurs choses:
- Les décisions semi-arbitraires lors de sa conception telles que la facilité d'utilisation, l'absence de compilateur SQL (ou IDE), la portabilité, etc.
- Il est arrivé à bien s'accumuler (probablement pour des raisons similaires)
- Et maintenant, pour des raisons historiques (compatibilité, bien connu, prouvé, etc.) continue d’être utilisé.
- Je ne pense pas que la plupart des entreprises se sont embarrassées avec une autre solution car cela fonctionne bien, n'est pas un goulot d'étranglement, c'est un standard, bla, bla ..
Parce que souvent, vous ne pouvez pas être sûr que (vous citant) "personne n'a jamais été vu après le déploiement" . Sachant qu'il existe une interface simple pour la création de rapports et l'interrogation au niveau de l'ensemble de données, cela constitue un bon chemin pour l'évolution de votre application.
Vous avez raison, il existe d’autres solutions valables dans certaines situations: XML, fichiers texte brut, OODB, etc.
Avoir un ensemble d’interfaces communes (comme ODBC) est un atout considérable pour la vie des données.
Il existe de nombreux systèmes de bases de données non relationnelles. En voici quelques-unes: MemcachedTokyo Cabinet
Je pense que la raison pourrait être les algorithmes de recherche/recherche/capture auxquels le fichier SQL est connecté. N'oubliez pas que SQL est développé depuis 40 ans - et que l'objectif a été à la fois de réaliser des performances et de satisfaire les utilisateurs.
Demandez-vous quelle est la meilleure façon de trouver 2 attibuts. Maintenant, pourquoi enquêter sur le fait que chaque fois que vous voudriez faire quelque chose qui inclut cela à chaque fois que vous développez votre application. En supposant que l’objectif principal est le développement de votre application lors du développement d’une application.
Une application présente des similitudes avec d'autres applications, une base de données présente des similitudes avec d'autres bases de données. Il devrait donc exister un "meilleur moyen" d'interagir logiquement entre ceux-ci.
Demandez-vous également comment vous développeriez une meilleure application ne contenant que la console et n’utilisant pas SQL Laungage. Si vous ne pouvez pas faire cela, je pense que vous devez développer un nouveau type d’interface graphique qui est encore plus simple à utiliser que sur une console - pour en tirer parti. Et cela pourrait effectivement être possible. Cependant, la plupart des applications sont principalement basées sur la console et la dactylographie.
Ensuite, je ne pense pas que vous puissiez créer un laungage de texte beaucoup plus simple que sql. Et rappelez-vous que chaque mot de quelque chose est intimement lié à sa signification - si vous supprimez le sens, le mot ne peut pas être utilisé - si vous supprimez le mot, vous ne pouvez pas communiquer le sens. Vous n’avez rien pour le décrire (et vous ne pouvez peut-être même pas penser que c’est parce que cela n’aurait aucun rapport avec ce que vous avez pensé avant ...).
Donc, fondamentalement, les meilleurs algorithmes possibles pour la manipulation de base de données sont attribués à des mots - si vous supprimez ces mots, vous devrez attribuer à ces manipulations autre chose - et ce serait quoi?
En ce qui concerne la recherche d'une base de données relationnelle qui n'utilise pas SQL comme interface principale, je pense que vous ne le trouverez pas. Raison: SQL est un excellent moyen de parler de relations. Je ne peux pas comprendre pourquoi c'est un gros problème pour vous: si vous n'aimez pas le SQL, mettez une abstraction dessus (comme un ORM) afin que vous n'ayez pas à vous en préoccuper. Laissez l'abstraction s'en soucier. Cela vous amène au même endroit.
Cependant, le problème que vous êtes vraiment, c'est que la relation objet-relation est déconnectée - le problème vient de la relation elle-même. Les objets et les nuplets relationnels ne se prêtent pas toujours à une relation 1-1, ce qui explique pourquoi un développeur peut être frustré par une base de données. La solution consiste à utiliser un type de base de données différent.