Pourquoi utiliser la base de données SQL?
Je ne suis pas tout à fait sûr de stackoverflow est un lieu pour une question d'ordre général, mais nous allons essayer.
Être exposés à la nécessité de l'application de stockage de données quelque part, j'ai toujours utilisé sqlite ou MySQL, juste parce qu'il a toujours fait comme ça. Comme il semble que le monde entier est l'utilisation de ces bases de données (la plupart de tous les produits logiciels, cadres, etc), c'est assez dur pour un début de développeur comme moi de commencer à penser, si c'est une bonne solution ou pas.
Ok, disons que nous avons quelques orientée objet logique dans notre application, et les objets sont liés les uns aux autres en quelque sorte. Nous avons besoin de carte de cette logique pour le stockage de la logique, de sorte que les relations entre les objets de base de données sont nécessaires aussi. Cela nous conduit à l'utilisation de base de données relationnelle, et je suis ok avec ça - pour faire simple, notre base de données de lignes de la table est parfois le besoin d'avoir des références à d'autres tables de lignes. Mais pourquoi utiliser le langage SQL pour l'interaction avec une base de données?
Requête SQL est un message texte. Je peux comprendre c'est cool pour réellement comprendre ce qu'il fait, mais n'est-il pas ridicule d'utiliser le texte de la table et les noms de colonne pour une partie de la demande qui n'a jamais vu après deploynment? Si vous aviez à écrire un stockage de données à partir de zéro, vous n'avez jamais utilisé ce type de solution. Personnellement, je l'aurais utilisé certains "compilé db requête" bytecode, qui serait assemblé une fois à l'intérieur d'une application client et transmis à la base de données. Et il est certainement le nom des tables et des colons par des numéros d'identification, non ascii-chaînes. Dans le cas de changements dans la structure de la table de ceux de l'octet les requêtes peuvent être recompilé selon la nouvelle db schéma, stockées au format XML ou quelque chose comme ça.
Quels sont les problèmes de mon idée? Est-il une raison pour moi de ne pas l'écrire moi-même et à l'utilisation de base de données SQL à la place?
MODIFIER pour faire À ma question plus clairement. La plupart des réponses affirment que SQL, étant une requête de texte, permet aux développeurs de mieux comprendre la requête elle-même et de déboguer plus facilement. Personnellement, je n'ai pas vu les gens écrire des requêtes SQL à la main pendant un certain temps. Tous ceux que je connais, moi y compris, est à l'aide de l'ORM. Cette situation, dans laquelle nous construire un nouveau niveau d'abstraction pour masquer SQL, conduit à penser si nous avons besoin de SQL ou pas. Je vous serais très reconnaissant si vous pouviez donner quelques exemples dans lesquels SQL est utilisé sans ORM exprès, et pourquoi.
EDIT2 SQL est une interface entre un homme et une base de données. La question est de pourquoi devons-nous l'utiliser pour l'application et l'interaction des bases de données? J'ai toujours demander pour des exemples d'êtres humains d'écriture/de débogage SQL.
- Quand j'ai lu le titre, j'ai pensé que ce serait une question stupide... mais c'est en fait une idée très intéressante !
- Lorsque SQL a été tout d'abord introduit dans les années 1970, il n'y avait pas OO concept autour de. C'est comment l'informatique développé et maintenant, les gens voir les inconvénients et les gens introduits ORM comme le complément.
- Peut-être que la question devrait être, "Pourquoi utiliser SQL vs requêtes compilées dans la base de données"?
- J'ai généralement de la main-d'écrire de SQL (certes, mes questions ne sont pas très compliqué).
- Re: "j'ai toujours demander pour des exemples d'êtres humains d'écriture/de débogage SQL". Vous êtes sérieux à ce sujet?
- Ce sujet de l'utilisation de jQuery pour qui? Semble une bonne idée – Le cancer qui est en train de tuer, de SORTE
- Le NoSQL groupe Google est bon pour ce genre de requête </pun> ainsi.
- "N'est-il pas ridicule d'utiliser le texte de la table et les noms de colonne pour une partie de la demande qui n'a jamais vu après deploynment [sic]?" Peut-être, mais je n'ai jamais vu une application pour laquelle cela était vrai.
- Comment l'application de savoir ce qu'il faut faire à partir de la base de données? Il n'y a pas de véritable Application de Base de données sur l'interaction.
Vous devez vous connecter pour publier un commentaire.
Si tout ce que vous devez faire est de stocker des données d'application quelque part, puis, d'un usage général, SGBDR ou même SQLite peut-être exagéré. La sérialisation de vos objets et de les écrire dans un fichier qui pourrait être plus simple dans certains cas. Un avantage à SQLite est que si vous avez beaucoup de ce genre d'information, c'est tous les contenus dans un fichier. Un inconvénient est qu'il est plus difficile à lire. Par exemple, si vous sérialiser les données de YAML, vous pouvez lire le fichier avec un éditeur de texte ou shell.
C'est ainsi que les Api de base de données de travail. Découvrez SQL statique et préparées.
Si vous avez besoin de beaucoup de fonctionnalités, à un certain moment, il sera plus facile d'utiliser une RDMBS alors d'écrire votre propre base de données à partir de zéro. Si vous n'avez pas besoin de beaucoup de fonctionnalités, une solution plus simple peut-être plus sage.
Le point de l'ensemble de la base de données de produits est d'éviter l'écriture de la couche de base de données pour chaque nouveau programme. Oui, un moderne RDMBS peut ne pas toujours être un ajustement parfait pour chaque projet. C'est parce qu'ils ont été conçus pour être très générale, si dans la pratique, vous obtiendrez toujours des fonctionnalités supplémentaires que 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'être un ajustement parfait.
Mise à JOUR:
Bonne question.
La réponse peut être trouvée dans le document initial décrivant le modèle relationnel Un Modèle Relationnel de Données pour de Grandes Banques de Données Partagée, par E. F. Codd, publié par IBM dans les années 1970. Ce document décrit les problèmes avec la base de données existante technologies de l'époque, et explique pourquoi le modèle relationnel de qualité supérieure.
La raison de l'utilisation du modèle relationnel, et donc une requête logique de la langue tels que SQL, est des données de l'indépendance.
Données de l'indépendance est définie dans l'article:
"... l'indépendance des programmes d'application et le terminal des activités de la croissance dans les types de données et les changements dans la représentation des données."
Avant le modèle relationnel, la domination de la technologie de bases de données a été considérée comme le modèle de réseau. Dans ce modèle, le programmeur a savoir la structure de stockage sur disque des données et de parcourir l'arbre ou graphe manuellement. Le modèle relationnel permet d'écrire une requête contre le conceptuelle ou logique régime qui est indépendante de la représentation physique des données sur le disque. Cette séparation de schéma logique du schéma physique est pourquoi nous utilisons le modèle relationnel. Pour plus de détails sur cette question, ici sont des diapositives à partir d'une base de données de la classe. Dans le modèle relationnel, nous utilisons la logique de base des langages de requêtes comme SQL pour extraire des données.
Codd du papier va plus dans le détail sur les avantages du modèle relationnel. Donner une lecture.
SQL est un langage de requête qui est facile de taper sur un ordinateur en contraste avec les langages de requêtes utilisées dans les articles de recherche. Documents de recherche utilisent généralement le rapport de l'algèbre ou relationnelle calcul d'écrire des requêtes.
En résumé, nous utilisons SQL, car nous arrive d'utiliser le modèle relationnel de nos bases de données.
Si vous comprenez le modèle relationnel, il n'est pas difficile de voir pourquoi SQL est la façon dont il est. Donc, fondamentalement, vous avez besoin d'étudier la relation de modèle et de base de données internes plus en profondeur pour vraiment comprendre pourquoi nous utilisons SQL. Il est peut-être un peu de mystère autrement.
Mise à JOUR 2:
Parce que la base de données est une base de données relationnelle, il comprend uniquement les requêtes relationnelles langues. En interne, il utilise une algèbre relationnelle comme le langage pour la spécification des requêtes qui il se transforme alors en un plan de requête. Donc, nous écrivons notre requête dans une forme que nous pouvons comprendre (SQL), la bd prend notre requête SQL et il se transforme en interne, la langue de la requête. Puis il prend la requête et tente de trouver un "plan de requête" pour l'exécution de la requête. Il exécute ensuite le plan de requête et retourne le résultat.
À un certain point, nous devons coder notre requête dans un format que la base de données comprend. La base de données ne sait comment convertir SQL pour sa représentation interne, c'est pourquoi il est toujours SQL à un certain point dans la chaîne. Il ne peut pas être évitée.
Lorsque vous utilisez l'ORM, votre juste l'ajout d'une couche sur le dessus de la SQL. Le SQL est toujours là, sa juste caché. Si vous avez une couche de haut niveau pour la traduction de votre requête dans SQL, alors vous n'avez pas besoin d'écrire du SQL directement, ce qui est bénéfique dans certains cas. Quelques fois nous n'avons pas une telle couche qui est capable de faire les types de requêtes que nous avons besoin, nous devons donc utiliser SQL.
Tous ceux que je connais, moi y compris, est d'utiliser un ORM
Étrange. Tous ceux que je connais, moi y compris, écrit encore, la plupart du SQL à la main. Vous finissent généralement avec plus serré, plus haute performance requêtes que vous faites avec une solution générée. Et, selon votre secteur d'activité et de demande, cette vitesse ne question. Parfois beaucoup. ouais, je vais parfois l'utilisation de LINQ pour un quick-n-sale où je ne me soucie pas vraiment de ce que le SQL qui en résulte ressemble, mais jusqu'à présent rien automatisé bat la main-tuned SQL pour quand la performance contre une importante base de données dans un environnement à forte charge qui compte vraiment.
Compte tenu du fait que vous avez utilisé MySQL et SQLite, je comprends votre point de vue complètement. La plupart des SGBD ont des caractéristiques qui aurait besoin d'un peu de la programmation de votre côté, tandis que vous obtenez à partir de la base de données pour gratuit:
Index - vous pouvez stocker de grandes quantités de données et être encore capable de filtrer et rechercher très rapidement en raison de l'index. Bien sûr, vous pourriez vous mettre en œuvre propre de l'indexation, mais pourquoi réinventer la roue
l'intégrité des données - à l'aide de fonctionnalités de base de données comme une cascade clés étrangères peuvent assurer l'intégrité des données à l'échelle du système. Vous avez seulement besoin de déclarer des relations entre les données, et le système se charge du reste. Bien sûr, une fois de plus, vous pouvez mettre en œuvre des contraintes dans le code, mais c'est plus de travail. Considérons, par exemple, la suppression, où vous devez écrire du code dans l'objet du destructeur de suivre tous les objets dépendants et d'agir en conséquence
possibilité d'avoir de multiples applications écrits dans différents langages de programmation, de travailler sur différents systèmes d'exploitation, certains ont même distribué à travers le réseau, le tout à l'aide de la mêmes données stockées dans une base de données commune
morts facilité de mise en œuvre de pattern observer via des déclencheurs. Il existe de nombreux cas où seule une partie des données dépend de certaines autres données et il n'affecte pas l'aspect de l'INTERFACE utilisateur de l'application. Assurer la cohérence peut être très difficile ou exiger beaucoup de programmation. Bien sûr, vous pourriez mettre en œuvre déclencheur comme le comportement avec les objets, mais il exige plus de la programmation que de la simple définition SQL
Il y a quelques bonnes réponses ici. Je vais tenter d'ajouter mon grain de sel.
J'aime SQL, je peux penser à elle assez facilement. Les requêtes produites par des couches sur le dessus de la bd (comme ORM cadres) sont généralement hideux. Ils vont sélectionner des tonnes de trucs supplémentaires, à participer à des choses que vous n'avez pas besoin, etc.; tout cela parce qu'ils ne savent pas que vous voulez seulement une petite partie de l'objet dans le présent code. Lorsque vous avez besoin de haute performance, vous allez, souvent, et en utilisant au moins certaines des requêtes SQL personnalisées dans un ORM système juste pour accélérer un peu les goulots d'étranglement.
Pourquoi SQL? Comme d'autres l'ont dit, il est facile pour les humains. Il fait un bon plus petit dénominateur commun. Aucune langue ne peut rendre SQL et de les appeler en ligne de commande des clients, si nécessaire, et c'est à peu près toujours une bonne bibliothèque.
Est l'analyse porte sur le SQL inefficace? Un peu. La grammaire est assez structuré, donc il n'y a pas des tonnes de ambiguïtés qui ferait de l'analyseur de travail vraiment difficile. Le vrai truc, c'est que la surcharge de l'analyse hors SQL est rien sur le fond.
Disons que vous exécutez une requête "SELECT x from table where id = 3", puis le faire à nouveau avec 4, puis 5, plus et plus. Dans ce cas, la prise en compte de frais généraux peuvent exister. C'est pourquoi nous vous avons préparé des instructions (comme d'autres l'ont mentionné). Le serveur traite la requête une fois, et pourrez échanger dans la 3 et la 4 et la 5 sans avoir à l'analyse de tout.
Mais c'est le cas trivial. Dans la vraie vie, votre système peut adhérer à 6 tables et à tirer des centaines de milliers d'enregistrements (si pas plus). Il peut être une requête que vous laissez s'exécuter sur un cluster de base de données pendant des heures, parce que c'est la meilleure façon de faire les choses dans votre cas. Même avec une requête qui ne prend qu'une minute ou deux à exécuter, le temps d'analyser la requête est essentiellement libre, comparativement à tirer des enregistrements du disque et de faire le tri/agrégation/etc. La surcharge de l'envoi de la poste "JOINTURE EXTERNE GAUCHE SUR" est à seulement quelques octets par rapport à l'envoi spécial codé octet 0x3F. Mais quand votre résultat est de 30 MO (sans parler de concerts+), ces quelques octets supplémentaires sont sans valeur par rapport à ne pas avoir à jouer avec certains de la requête compilateur objet.
Beaucoup de gens utilisent SQL sur de petites bases de données. Le plus grand que je interagir avec seulement quelques dizaines de concerts. SQL est utilisé sur tout, de petits fichiers (comme des petits SQLite DBs peut-être) jusqu'à un téraoctet de la taille de clusters Oracle. Compte tenu de sa puissance, c'est en fait étonnamment simple et petit jeu de commandes.
proprietary? Je pensais à une certaine solution open-source, par exemple. 2) 3) Il semble que c'est une bonne chose pour les développeurs d'avoir textuelle requêtes car elles sont faciles à comprendre. Mais que penser de ces développeurs qui passent beaucoup de temps sur l'optimisation de la requête? Est-il utile? Je ne pense pas qu'une bonne interface de l'application de bytecode requêtes, comme je l'ai écrit à ce sujet, aurait été si difficile à comprendre. Les développeurs aimeraient vitesse plus que de l'apprentissage de la simplicité, je suppose.Je pense que c'est pour la même raison que vous utilisez lisible par l'utilisateur (code source) de la langue pour l'interaction avec le compilateur.
C'est un existant (facultatif) disposent de bases de données, appelé "procédures stockées".
Edit:
Lorsque j'ai mis en place mon propre de l'ORM, j'ai mis en place l'ORM de l'aide ADO.NET: et à l'aide de ADO.NET inclut l'aide d'instructions SQL dans sa mise en œuvre.
Après toutes les modifications et les commentaires, le point principal de votre question semble être : pourquoi est la nature de SQL plus proche de l'être humain/interface de base de données que d'être une application de base de données sur l'interface ?
Et la réponse très simple à que question est : parce que c'est exactement ce qu'il était à l'origine destiné à être.
Les prédécesseurs de SQL (QUEL'étant sans doute le plus important), sont destinés à être exactement cela : un langage de REQUÊTE, c'est à dire celui qui n'avait pas du tout de l'INSERT, UPDATE, DELETE.
En outre, il a été conçu pour être un langage de requête qui pourrait être utilisé par n'importe quel utilisateur, à condition que l'utilisateur est conscient de la structure logique de la base de données, et, évidemment, savait comment exprimer que la structure logique de la requête de la langue qu'il utilisait.
L'origine des idées derrière QUEL'/SQL ont été qu'une base de données a été construite à l'aide de n'importe quel mécanisme envisageable", que le "réel" de la base de données pourrait être vraiment n'importe quoi (par exemple, un seul gigantesque fichier XML - bien que XML n'a pas été considérée comme une option valable à l'époque), et qu'il y aurait "une sorte de machinerie" qui a compris comment transformer la structure réelle de cette "chose" dans la logique de la structure relationnelle comme il a été perçu par l'utilisateur SQL.
Le fait que pour réellement y parvenir, les structures sous-jacentes sont tenus de se prêter à "visualiser de manière relationnelle", n'a pas été bien compris dans ces jours, comme il est maintenant.
Oui, c'est ennuyeux d'avoir à écrire des instructions SQL pour stocker et récupérer des objets.
C'est pourquoi Microsoft a ajouté des choses comme LINQ (language integrated query) en C# et VB.NET pour le rendre possible pour interroger des bases de données à l'aide d'objets et de méthodes à la place de chaînes de caractères.
La plupart des autres langues ont quelque chose de similaire avec plus ou moins de succès selon les aptitudes de cette langue.
D'autre part, il est utile de savoir comment SQL fonctionne et je pense que c'est une erreur de vous protéger entièrement de lui. Si vous utilisez la base de données sans réflexion, vous pouvez écrire extrêmement inefficace des requêtes et des index de la base de données de manière incorrecte. Mais une fois que vous comprenez comment utiliser SQL correctement à l'écoute de votre base de données, vous disposez d'un très puissant essayé et testé outil pour trouver exactement les données dont vous avez besoin très rapidement.
Ma plus grande raison pour SQL est de rapports Ad hoc. Ce rapport à vos utilisateurs veulent mais ne savent pas qu'ils ont besoin d'elle encore.
J'utilise sqlite beaucoup à droite à partir de la plus simple des tâches (comme l'exploitation forestière mes journaux de pare-feu directement à une base de données sqlite) de plus en plus complexes d'analyse et de débogage des tâches dans ma journée-à-jour de la recherche. La pose de mes données dans des tableaux et de l'écriture de requêtes SQL pour munge eux de manière intéressante semble être la chose la plus naturelle pour moi dans ces situations.
Votre point de savoir pourquoi il est encore utilisé comme une interface entre l'application/de la base de données, c'est mon raisonnement simple:
Il y a environ 3-4 décennies de
un sérieux travail de recherche dans ce domaine
à partir de 1970 avec Codd séminal
livre sur l'Algèbre Relationnelle.
L'Algèbre relationnelle les formes de la
mathématiques de base SQL (et d'autres
QLs), bien que SQL n'est pas
complètement suivez le relationnel
de modèle.
Le "texte" de la forme de la langue
(en plus d'être facilement
compréhensible pour les humains) est également
facilement parsable par des machines (dire
à l'aide d'une grammaire de l'analyseur comme comme
lex) et est facilement convertible pour que ce soit "bytecode" à l'aide de n'importe quel nombre d'optimisations.
Je ne suis pas sûr si cela en toute
autre façon, aurait permis d'
convaincante avantages dans le cas génériques. Sinon, il
aurait été probablement découvert
et adopté en 3 décennies de
de recherche. SQL fournit probablement le
le meilleur compromis lors de l'intégration de la
diviser entre les humains et les bases de données et
applications/bases de données.
La question qui devient alors intéressant de se poser est: "Quels sont les vrais avantages de faire du SQL dans tout autre "non-texte" de la sorte?" Google pour cette suite:)
SQL est une commune de l'interface utilisée par le SGBD de la plate - forme de l'ensemble du point de l'interface, c'est que toutes les opérations de base de données peut être spécifié dans SQL sans avoir besoin supplémentaire d'appels d'API. Cela signifie qu'il existe une interface commune à travers tous les clients du système de logiciels d'application, des rapports et des requêtes ad-hoc outils.
Deuxièmement, SQL devient de plus en plus et de plus utile que les requêtes deviennent plus complexes. Essayez d'utiliser LINQ pour spécifier un en 12 sens de rejoindre un avec trois conditions basées sur des prédicats existentiels et un état basé sur un agrégat calculé dans une sous-requête. Ce genre de chose est assez compréhensible dans SQL mais peu probable dans un ORM.
Dans de nombreux cas, un ORM va faire 95% de ce que vous voulez - la plupart des requêtes émises par les applications sont simples opérations CRUD qu'un ORM ou une autre base de données générique mécanisme d'interface peut gérer facilement. Certaines opérations sont faites à l'aide personnalisée de code SQL.
Toutefois, les Formulaires ne sont pas l'alpha et l'oméga de la base de données de l'interfaçage. Fowler Modèles d'Architecture d'Applications d'Entreprise a tout à fait un bon article sur d'autres types d'accès à la base de la stratégie avec des éléments de discussion sur les mérites de chacun.
Il y a souvent de bonnes raisons de ne pas utiliser un ORM comme la principale base de données de la couche d'interface. Un exemple d'une bonne plate-forme de base de données des bibliothèques comme ADO.Net souvent un assez bon travail et s'intégrer parfaitement avec le reste de l'environnement. Vous trouverez peut-être que le gain de l'aide d'une autre interface n'est pas vraiment l'emportent sur les avantages de l'intégration.
Toutefois, la dernière raison est que vous ne pouvez pas vraiment ignorer SQL est que vous êtes en fin de compte, avec une base de données si vous faites une application de base de données. Il y a beaucoup, beaucoup de WTF des histoires au sujet de vis-ups dans des applications commerciales code fait par des gens qui n'ont pas compris les bases de données correctement. Mal pensé code de base de données peut causer des problèmes à bien des égards, et allègrement en pensant que vous n'avez pas besoin de comprendre comment le SGBD travaux est un acte d'Orgueil qui est lié à venir et vous mordre un jour. Pire encore, il viendra et la morsure de certains autres pauvres schmoe qui hérite de votre code.
Alors que je vois votre point de vue, SQL le langage de requête a une place, surtout dans les grandes applications avec un grand nombre de données. Et de souligner l'évidence, si la langue n'était pas là, on ne pouvait pas l'appeler SQL (Structured Query Language). L'avantage d'avoir SQL sur la méthode que vous avez décrit est SQL est généralement très lisible, même si certains ont vraiment repousser les limites de leurs requêtes.
J'ai tout cordialement accord avec Mark Byers, vous ne devriez pas vous protéger SQL. N'importe quel développeur peut écrire du SQL, mais pour vraiment faire votre demande d'effectuer bien avec SQL interaction, la compréhension de la langue est un must.
Si tout a été compilée avec le bytecode comme vous l'avez décrit, je déteste être le seul à avoir pour déboguer l'application après le développeur à l'origine de la gauche (ou même après ne pas voir le code pour 6 mois).
Je pense que la prémisse de la question est incorrecte. SQL peut être représenté sous forme de texte est sans importance. La plupart des bases de données modernes serait seulement de compiler des requêtes à la fois et de les mettre en cache de toute façon, vous avez déjà en fait, un "code compilé'. Et il n'y a pas de raison que cela ne pouvait pas arriver client sage que je ne suis pas sûr si quelqu'un l'a fait.
Vous dit SQL est un message texte, bien que je pense de lui en tant que messager, et, comme nous le savons, ne tirez pas sur le messager. Le vrai problème est que les relations ne sont pas une assez bonne manière d'organiser les données du monde réel. SQL est juste du rouge à lèvres sur le cochon.
Si la première partie vous semblent se référer à ce qui est généralement appelé le mapping Objet - relationnel impédance. Il y a déjà beaucoup de cadres pour les soulager de ce problème. Il y a tradeofs ainsi. Certaines choses seront plus faciles, d'autres plus complexe, mais dans le cas général, ils fonctionnent bien si vous pouvez vous permettre la couche supplémentaire.
Dans la deuxième partie, vous semblez vous plaindre SQL texte (il utilise des cordes à la place de l'ids, etc)... SQL est un langage de requête. Tout langue (ordinateur ou autre) qui est destiné à être lu ou écrit par des humains est centrée sur les textes pour cette question. Assembleur, C, PHP, you name it. Pourquoi? Parce que, eh bien... c'est logique, n'est-ce pas?
Si vous voulez requêtes précompilées, vous avez déjà des procédures stockées. Les requêtes préparées sont également compilé une fois à la volée, IIRC. La plupart (si pas tous) db pilotes de parler au serveur de base de données à l'aide d'un protocole binaire de toute façon.
oui, le texte est un peu inefficace. Mais en fait, l'obtention de données est beaucoup plus coûteux, de sorte que le texte sql est raisonnablement insignifiant.
SQL a été créé pour fournir une interface pour effectuer des requêtes ad hoc sur une base de données relationnelle.
Généralement, la plupart des bases de données relationnelles comprendre une certaine forme de SQL.
Orientée objet bases de données existent, et (probablement) utiliser des objets pour faire leur interrogation... mais comme je le comprends, OO bases de données ont beaucoup plus entendu, et les bases de données relationnelles fonctionnent tout aussi bien.
Bases de données relationnelles vous permettent également d'opérer dans un "déconnecté" de l'état. Une fois que vous avez les informations que vous avez demandé, vous pouvez fermer la connexion de base de données. Avec un OO base de données, vous devez retourner tous les objets liés à l'actuel (et de ceux qu'elles sont liées à... et... etc...) ou de rouvrir la connexion pour récupérer de nouveaux objets comme ils sont accessibles.
En plus de SQL, vous avez également Orm (object-relational mappings) que les objets de la carte de SQL et de retour. Il existe assez peu d'entre eux, y compris LINQ (.NET), le MS Entity Framework (.NET), mise en veille prolongée (Java), SQLAlchemy (Python), ActiveRecord (Ruby), Class::DBI (Perl), etc...
Un langage de base de données est utile, car elle fournit un modèle logique de données indépendant de toutes les applications qui l'utilisent. SQL a beaucoup de lacunes, cependant, ne serait-ce que son intégration avec d'autres langues est pauvre, type de charge est d'environ 30 ans de retard sur le reste de l'industrie et il n'a jamais été véritablement la langue relationnelle de toute façon.
SQL a survécu principalement parce que la base de données du marché a été et reste dominé par les trois méga-vendeurs qui ont un intérêt à protéger leur investissement. En constante évolution et SQL, les jours sont probablement numérotées, mais le modèle qui remplacera finalement il n'a probablement pas encore arrivé - bien qu'il existe beaucoup de prétendants autour de ces jours.
Je ne pense pas que la plupart des gens sont à votre question, mais 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:
L'un des Unix principes de conception peut être dit ainsi, "Écrire des programmes pour gérer les flux de texte, parce que c'est une interface universelle.".
Et qui, je crois, c'est pourquoi nous avons généralement l'utilisation de SQL à la place de certains "byte-SQL" qui ne dispose que d'une compilation de l'interface. Même si nous ne ont un byte-SQL, quelqu'un serait d'écrire un Texte "SQL", et la boucle serait complet.
Aussi, MySQL et SQLite sont moins complètes que, disons, MSSQL et Oracle SQL. Si vous êtes toujours dans le bas de la SQL de la piscine.
En fait il y a peu de non-SQL base de données (telles que l'Objectivité, Oracle Berkeley DB, etc.) les produits sont venus, mais non réussi à le faire. Dans l'avenir, si quelqu'un trouve intuitive alternative pour SQL, qui répondra à votre question.
Il y a beaucoup de non systèmes de base de données. Voici quelques-uns:
Memcached
Tokyo Cabinet
Aussi loin que la recherche d'une base de données relationnelle ne pas utiliser SQL principal de l'interface, 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 SQL, mettre une couche d'abstraction au-dessus (comme un ORM) de sorte que vous n'avez pas à vous inquiéter à ce sujet. Laissez l'abstraction s'en soucier. Il vous arrive à la même place.
Cependant, le problème de votre e vraiment de mentionner ici est l'objet-relation débranchez - le problème, c'est la relation elle-même. Objets et relationnel-tuples ne sont pas toujours prêtent à être une relation 1-1, ce qui est la raison pour laquelle un développeur peut frustré avec une base de données. La solution à cela est d'utiliser un autre type de base de données.
Parce que souvent, vous ne pouvez pas être sûr que (citant vous) "personne n'a jamais vu après le déploiement". Sachant qu'il y a une interface facile pour les rapports et pour dataset niveau de l'interrogation est un bon chemin pour l'évolution de votre application.
Vous avez raison, qu'il existe d'autres solutions qui peuvent être valables que dans certaines situations: XML, des fichiers de texte brut, OODB...
Mais ayant un ensemble d'interfaces communes (comme ODBC) est un énorme plus pour la durée de vie des données.
Je pense que la raison pourrait être la recherche/rechercher/grab algorithmes sql laungage est connecté à le faire. N'oubliez pas que sql a été développé pour les 40 ans - et l'objectif a été à la fois preformence sage et utilisateur aimable sage.
Demandez-vous quelle est la meilleure façon de trouver 2 attribue est. Maintenant, pourquoi une enquête sur chaque fois que vous voulez faire quelque chose qui comprend que 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 a 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 y avoir une "meilleure façon" de ces interagir, logiquement.
Également vous demander comment vous pourriez développer une meilleure console seule application qui n'utilise pas de sql laungage. Si vous ne pouvez pas le faire, je pense que vous avez besoin de développer un nouveau type de graphique, qui sont encore plus fondamentalement plus facile à utiliser qu'avec une console à développer des choses de lui. Et que ça pourrait être possible. Mais encore plus le développement des applications est basée autour de la console et en tapant.
Alors quand il s'agit laungage je ne pense pas que vous pouvez faire beaucoup plus fondamentalement plus simple texte laungage que sql. Et n'oubliez pas que chaque mot de tout ce qui est inseperatly connecté à son sens - si vous retirez le sens que le mot ne peut pas être utilisé: si vous supprimez le mot que vous ne peut pas communiquer du sens. Vous n'avez rien à décrire (Et peut-être que vous ne pouvez même pas penser à elle parce qu'il wouldent être connecté à tout ce que vous avez pensé avant...).
Donc, fondamentalement, la meilleure possible des algorithmes de manipulation de base de données sont affectées à des mots: si vous supprimez ces mots vous devez assigner ces manipulations quelque chose d'autre, et ce que ce serait?
je pense que vous pouvez utiliser l'ORM
si et seulement si vous connaissez la base de sql.
d'autre, le résultat n'est pas le meilleur