Pourquoi les bases de données ne sont-elles pas intégrées en tant que fonction linguistique?

Existe-t-il des langages de programmation qui ont une base de données intégrée comme fonctionnalité de langage de première classe plutôt que de se connecter à une base de données SQL (ou autre) externe? Quels seraient les inconvénients et les avantages d'une telle fonctionnalité? À quoi ressemblerait une telle fonctionnalité et comment changerait-elle la façon dont nous programmons?

Le seul langage auquel je peux penser est les anciens langages xBase comme DBase, Clipper et FoxPro. Il existe un projet GNU qui propose une version gratuite et principalement compatible appelée Clip

C'était aussi Pick Basic qui liait un langage de programmation directement à une plate-forme de base de données.

Ceci a été fait. C'était une impasse évolutive qui limitait la façon dont une langue pouvait accéder aux données.

Les langues sont "petites" et les bases de données sont "grandes"; donc chaque fois que les deux sont combinés, ce n'est pas une langue avec la base de données comme fonctionnalités, mais une base de données avec la langue comme fonctionnalité. De nombreuses bases de données contiennent des langages propriétaires, par exemple PL / SQL, T-SQL.

Je ne pense pas nécessairement que la bonne question soit "pourquoi n'y est-il pas?" mais "pourquoi devrait-il y en avoir?". Que gagnerait-on à ce que les bases de données soient une caractéristique du langage? N'oubliez pas que le langage est tout en bas de la pile de programmation. Faire gonfler une langue affecte tout . Ainsi, les concepteurs de langage doivent être lents à ajouter de nouvelles fonctionnalités, en particulier celles qui impliqueraient un tel investissement.

Il existe 3 systèmes hérités proches de vos besoins:

1. Pick ,
2. MUMPS ,
3. Microsoft Access

Pick et MUMPS ont été développés des années avant le premier article académique sur les bases de données relationnelles (qui était environ une décennie avant que le premier système commercial de base de données basé sur SQL n'arrive sur le marché - d'une société que nous appelons maintenant Oracle; la première tentative d'IBM pour un produit a échoué et un système basé sur SQL réussi était plus tard). Vous les trouverez peut-être encore utilisés (notre système de transport public local utilisait Pick jusqu'à récemment pour le système de planification de voyage). Vous ne voulez rien avoir à faire avec Pick ou MUMPS, et le meilleur conseil que je puisse vous donner est "éloignez-vous du clavier avec vos mains en l'air!" Si vous ne rien avoir à faire avec eux, l'expression « vous serez désolé » devrait sonner dans vos oreilles.

Microsoft Access est sévèrement moqué et critiqué dans les cercles informatiques, car il est assez facile pour un non-développeur de créer une application commerciale critique à partir d'Access et de la faire muter en quelque chose dont la société ne peut littéralement pas vivre. Il est également très probable que bon nombre de développeurs aient commencé à développer via MS Access et que les choses s'enlisaient, ils ont appris à les corriger (la première étape consiste traditionnellement à apprendre le Visual Basic et à réécrire d'abord l'application Access en VB, puis dans quelque chose de "mieux"). Il est possible de créer une application Access bien comportée qui s'exécute distribuée avec une énorme quantité de données - je l'ai vu faire - mais il existe des moyens plus faciles de faire les choses, et il faut beaucoup moins de compétences pour créer (et entretenir) un puits application se comporte de VB et SQL Server.

Depuis SQL Server 2005, Microsoft a introduit la possibilité de mettre CLR dans des procédures et fonctions stockées. Et si vous voulez être délicat à ce sujet, vous pouvez créer des types de données que vous pouvez ensuite utiliser comme colonnes dans la base de données. Je pense qu'Oracle a eu quelque chose de similaire avec Java.

Cela étant dit, je ne pense pas que quelque chose vous empêche d'en créer un ou de faire des hypothèses à leur sujet. Pick et MUMPS sont plus anciens que la plupart des codeurs ici et reflètent une façon très COOL de regarder le monde.

Mon conseil personnel est de garder les choses séparées. Utilisez un langage qui est bon pour manipuler les données dont votre projet a besoin (avec la mise en garde que parfois le "meilleur" langage est celui que vous pouvez facilement trouver des programmeurs qui peuvent lire / écrire le code). Utilisez un système de base de données capable de conserver les données dont votre projet a besoin.

L'ajout d'une base de données dans un langage de programmation peut s'adresser uniquement à un ensemble très restreint d'utilisateurs. Et s'ils veulent utiliser des fonctionnalités non SGBDR? Ou vous ne voulez pas du tout utiliser une base de données? Le compilateur sera inutilement gonflé pour de tels cas d'utilisation.

Se tromper.

Eh bien, tout d'abord, vous demandez pourquoi le cadre dans lequel le langage fonctionne ne fournit pas de base de données. Une langue est simplement un moyen d'exprimer quelque chose que vous voulez faire dans des grammaires définies; il ne fournit pas vraiment de services comme ça. :)

Cela dit, il y a plusieurs raisons.

• La construction d'un système de stockage de base de données efficace est un problème difficile, probablement de l'ordre ou supérieur à la construction du .NET Framework (par exemple). Si une équipe essayait d'inclure une base de données dans son framework, ce serait tout ce sur quoi elle finirait par travailler.

• Une base de données qui se charge doit se trouver sur sa propre machine distincte et non dans le processus du code qui y accède.

• Les ORM fournissent une grande partie du type de sécurité et de vérification du temps de compilation qui serait le bénéfice d'une telle action, sans pour autant que le framework essaie d'être une base de données.

Cela dit, je suppose qu'il serait judicieux d'inclure une sorte d'implémentation SQLite dans le cadre contre lequel des applications ayant des besoins d'accès aux données moins importants pourraient fonctionner. Cependant, je ne suis pas sûr que ce serait utile dans des applications non triviales.

elles sont; ces langues sont appelées 4GL . DataFlex est mon préféré, bien que je ne l'utilise plus.

Mise en garde: J'ai aidé à développer la version orientée objet de DataFlex, v3.0

Je pense que votre vraie question est "pourquoi n'y a-t-il pas de langages de programmation fournis avec les bibliothèques de bases de données ".

Les langages à usage général traitent toutes les E / S comme une seule et même chose, que ce soit en écrivant ou en lisant sur / depuis un disque, une webcam, le réseau, l'écran, un emplacement en mémoire - tout est des E / S, et c'est tout ce qui concerne les langages de programmation. avec.

En fait, à part la lecture / écriture dans le tas et la pile, la plupart des langages de programmation ne font même pas d'E / S réelles. Certains langages fournissent des fonctionnalités natives pour exprimer les opérations d'E / S (par exemple la print commande en BASIC), mais la plupart des langages les traitent simplement comme des appels de fonction normaux (par exemple printfen C) et laissent les bibliothèques gérer l'écriture réelle.

Certains langages comme C # offrent des fonctionnalités de langage pour exprimer des requêtes, mais même alors, ce ne sont que des expressions sur la structure de données la plus élémentaire des listes (ou IEnumerables, comme on les appelle en .NET) qui sont traduites en opérations SQL par les bibliothèques - le langage lui-même ne fait que travailler avec des notions très abstraites d'IO.

Quant à savoir pourquoi la construction d'un package de base de données dans la bibliothèque standard d'un langage de programmation n'est pas une bonne idée, c'est très probablement parce que rien d'autre dans une bibliothèque standard ne dépendrait normalement de la fonctionnalité de la base de données.

Oui. Les langues de la plate-forme AS / 400 ont une prise en charge native de première classe des bases de données.

En effet, la plate-forme AS / 400 a la base de données entièrement intégrée partout et permet de nombreuses fonctionnalités très intéressantes, comme la facilité de navigation dans un jeu de résultats mettant à jour les valeurs en cours de route.

Dépend de la langue et de la plateforme. Par exemple, il est assez trivial pour moi d'utiliser une variété de bases de données tout en travaillant avec C, j'utilise simplement la bibliothèque appropriée.

Un langage doit maintenir son implémentation standard, ce qui signifie généralement fournir le montant minimum nécessaire pour que quelqu'un puisse construire ce qu'il veut construire. Tout le reste devient une bibliothèque, ou peut-être une extension de la langue maintenue par les autres.

C'est du moins le cas pour les langues qui suivent des normes établies par des organisations telles que l'ISO.

Tel qu'écrit, la question est partiellement fausse, comme l'ont montré certains contre-exemples ci-dessus.

J'affinerais donc d'abord la question comme suit: "Pourquoi un SGBD n'est-il généralement pas intégré en tant que fonctionnalité d'un langage de programmation généraliste de haut niveau?"

C'est pour la même raison que d'autres produits logiciels tels que les systèmes d'exploitation, les systèmes de fichiers, les serveurs Web, les couches de mise en cache, etc. ne sont généralement pas intégrés. Les langages à usage général fonctionnent généralement à un niveau d'abstraction supérieur à celui de ces produits. Il est donc raisonnable qu'un programmeur implémente un SGBD dansun langage à usage général, et que le SGBD peut même exposer des aspects de son langage parent ou un langage déclaratif spécifique à la base de données à l'usage des programmeurs de bases de données. Mais il y a trop d'options de conception dans l'écriture d'un SGBD pour qu'il soit sage de les corriger dans un langage de programmation à usage général. Si vous les corrigez, vous vous retrouvez avec un cas comme MUMPS, où l'intrication des deux entraîne une industrie entière embourbée dans un problème de poule et d'oeuf, coincée avec un SGBD obsolète et un langage de programmation obsolète.

Utilisé pour fonctionner dans NonStop / SQL qui était entièrement intégré à NonStop / C, NonStop / C ++, NonStop / Cobol, NonStop / Fortran, et probablement dans d'autres langues, ainsi qu'être entièrement intégré à NonStop / Guardian, le système d'exploitation sur lequel les ordinateurs couru.

Je pense que c'est probablement l'intégration la plus proche que vous pouvez obtenir, où la base de données EST le système de fichiers du système d'exploitation. C'est aussi une impasse, il n'y a aucun moyen de découpler les composants, la base de données, le système d'exploitation, le matériel et les logiciels écrits dessus ne peuvent jamais être utilisés séparément, portés vers un autre environnement.

Le plus proche que vous allez obtenir sur un PC serait probablement MS Access, Embarcadero / Borland Delphi étant une seconde proche.

Après cela, vous examinez les bases de données intégrées dans votre application, ce qui peut avoir un attrait limité pour ceux qui créent des applications autonomes qui ont besoin d'un ensemble de données hiérarchiques qui ne sont pas facilement stockées dans un fichier de configuration simple et / ou ont besoin d'une mise à jour régulière pendant l'exécution de l'application . Ou pour les personnes qui souhaitent avoir une version portable d'une application qui conserve un instantané d'une partie d'une base de données plus grande et peut-être synchronise celle-ci avec la plus grande base de données à des moments où l'application peut établir une connexion (pratique, par exemple, un vendeur qui est souvent hors de portée de le réseau d'entreprise a encore besoin de données de vente pour son groupe de clients, ou un médecin sur le terrain qui veut des dossiers de patients mais ne peut pas se connecter au réseau de l'hôpital car il n'y a pas d'accès au réseau où il doit aller).

En tant qu'ancien développeur de Visual Foxpro, j'ai du mal à comprendre qu'aucun langage traditionnel ne définisse le modèle relationnel comme faisant partie du langage.

Avoir le moteur de base de données complet n'est pas une bonne idée, mais avoir le langage "SQL" à la place pourrait être TRÈS utile.

En OO, il existe le décalage d'impédance. Cela est arrivé parce que les objets et les ensembles ne se ressemblent pas. Mais si un langage me permet de définir TABLES, FIELDS, RELATIONS, CONTRAINS, etc (sans le lier à un stockage particulier) sera très puissant. De plus, la création d'un ORM sera davantage un mappage 1 à 1.