Programmation unificatrice et requête de base de données [clôturé]

Considérez un didacticiel commun pour les langages de programmation orientés objet comme C ++ ou Java: créez un système de traitement des commandes simple avec des objets représentant des comptes, des commandes, des articles, etc. (ou quelque chose de plus ou moins équivalent). Cela a un sens intuitif parfait, mais l'éléphant à la table à manger est que ce n'est pas réel car ce sont des objets en mémoire; dans un système réel, les comptes, les ordres, etc. ne vivent pas réellement en mémoire en premier lieu, ils vivent dans une base de données, avec la représentation en mémoire seulement un miroir éphémère de celle-ci.

Vous pouvez écrire vous-même beaucoup de code pour lire et écrire à partir de la base de données, mais c'est tellement fastidieux et sujet aux erreurs que personne ne le fait réellement.

Tout le monde finit par utiliser un ORM, mais ceux-ci sont si problématiques en soi qu'un célèbre journal les appelle «le Vietnam de notre industrie».

Je ne pense pas que ce soit un décalage entre objet et relationnel autant qu'un décalage entre le langage de programmation et la base de données étant des choses distinctes qui ne se connaissent pas . Conjecture: la solution est d'avoir un seul langage qui soit à la fois le langage de programmation et de requête de base de données, ce qui nécessiterait à son tour que le runtime du langage soit également la base de données, et le compilateur JIT soit également l'optimiseur de requête.

Voilà donc le résumé des problèmes que je vois. Ma question est, a encore quelqu'un non plus,

1. En fait construit un tel système unifié

2. A essayé mais n'a pas réussi à construire un tel système unifié

3. A écrit quelque chose de substantiel sur le sujet de la façon dont vous vous y prendriez, ou pourquoi ou pourquoi pas

4. Trouvez une autre façon de résoudre le problème?

C'est mon opinion. Alors que je vois d'où vous venez, je ne peux tout simplement pas voir cela se produire du point de vue de la conception.

La persistance des données est un sujet extrêmement complexe. Et les langages de programmation aussi. La combinaison des deux entraînerait une explosion de complexité. Il faudrait beaucoup d'efforts pour rendre les deux suffisamment bons pour que les gens veuillent vraiment les utiliser. Je pense que MUMPS déjà mentionné est un bon exemple. Ou vous pouvez regarder différentes variantes SQL qui ont un langage complet boulonné sur eux. Ils pourraient être utilisables, mais je ne pense pas que les gens les utiliseraient volontiers.

Les séparer est donc un moyen clair de résoudre cette complexité. De plus, en ne les liant pas ensemble, cela permet à la fois de changer et d'évoluer avec le temps. Par exemple, SQL est ancien et n'a pas beaucoup changé depuis sa création. Mais les langues utilisées pour exécuter les applications ont radicalement changé au cours de la même période. Et maintenant, l'opposé se produit. Les langues restent essentiellement les mêmes pendant que les bases de données sont modifiées et évoluées.

Le déploiement à l'exécution est un autre problème. La combinaison des deux signifierait que la base de données et l'application ou le serveur Web devraient s'exécuter dans un même processus. Cela est extrêmement limitant, tant du point de vue de la maintenance que de la possibilité de les exécuter sur des ordinateurs distincts ou dans des relations plusieurs à un.

Diviser les deux en modules séparés avec une API claire entre eux est le meilleur moyen de réduire la complexité et de vous donner une flexibilité dans les technologies que vous souhaitez utiliser et comment les éléments finaux sont déployés.

Il semble que vous fassiez certaines hypothèses majeures. Par exemple, vous supposez que tout le monde écrit dans des bases de données relationnelles. Ce n'est tout simplement pas le cas, il existe de nombreux exemples de bases de données d'autres saveurs (objet dbs, document dbs, etc.) qui utilisent un langage de programmation natif pour écrire tout le code et gérer la persistance.

Par exemple, Db4O est compatible avec Java et C #, ObjectDB en Java, VelocityDB dans une variété de langages. Les pilotes de MongoDB finissent tous par vous faire écrire des trucs dans votre langage de programmation natif (bonus si vous faites du JavaScript, car cela signifie que le shell utilise également la même syntaxe), et ainsi de suite.

Il y a BEAUCOUP de discussions à divers endroits sur les moteurs DB qui conviennent le mieux dans quels contextes, et pourquoi, beaucoup trop pour la portée de cette réponse, pour inclure une question fermée sur ce site même. Le résultat est qu'ils sont chacun optimisés pour différentes choses, et jusqu'à récemment, SQL était considéré comme une sorte de `` plus petit dénominateur commun '' pour les applications commerciales, car vous obtenez beaucoup gratuitement en termes d'ACID et de performances (bien que les deux changent récemment à mesure que les architectures et les exigences changent).

Il convient également de noter qu'il existait auparavant de nombreuses approches «tout en un». Les langages mainframe avaient souvent leur propre logique de persistance intégrée, et il existe des langages comme Smalltalk qui ne font aucune différence entre le code et les données. Encore une fois, ils sont souvent bons pour certains cas d'utilisation, mais pas tous.

1. Oui (pas moi). Cela s'appelait MUMPS .

2. D'après cette ancienne question SE.SE , ou cet article , MUMPs n'était pas très bien conçu. Mais il a en effet été utilisé dans l'industrie de la santé (et je suppose qu'il existe encore des systèmes qui l'utilisent), donc pas un échec total.

3. Vous trouverez sûrement des informations à ce sujet maintenant que vous savez quoi chercher. Commencez avec le lien Wikipedia ci-dessus.

4. Recherchez des bases de données orientées objet, beaucoup d'entre elles sont spécifiques au langage. Ils ont essayé de remédier à l'inadéquation relationnelle-objet de manière plus simple que les ORM.

Il existe en effet plusieurs systèmes qui unifient la base de données et le langage de programmation en un seul environnement.

Smalltalk est probablement le plus proche de ce que vous décrivez. Les objets en mémoire sont conservés dans une "image", de sorte que l'environnement linguistique peut être utilisé une base de données (objet) prête à l'emploi. Et la plupart des langages modernes ont une sorte de mécanisme de persistance intégré qui signifie que les objets dans l'environnement linguistique peuvent être persistés et interrogés en utilisant le langage lui-même.

Ceci est très pratique pour les applications mono-utilisateur. Mais l'approche ne s'adapte pas à plusieurs utilisateurs, car ils auront besoin de partager le même espace mémoire, ce qui limite évidemment le nombre d'utilisateurs. Une solution évolutive nécessite un serveur de base de données distinct qui gère la concurrence. Même dans ce cas, il existe plusieurs bases de données NoSql qui s'intègrent à un environnement linguistique spécifique et vous permettent de persister et d'interroger des objets dans le langage lui-même.

Du côté relationnel des choses, nous avons des langages comme T-SQL qui est un langage de programmation à part entière qui est un surensemble de SQL, de sorte que l'interrogation et le DML peuvent être entremêlés avec une logique procédurale complexe arbitraire. Des applications métier complexes ont été construites à l'aide de T-SQL, c'est donc certainement faisable, mais la tendance actuelle est à la logique métier procédurale loin de la base de données.

Dans ces cas, il est en effet très élégant et pratique d'avoir la base de données intégrée au langage de programmation et d'éviter le "décalage d'impédance". Alors, pourquoi les gens utilisent-ils toujours des bases de données relationnelles distinctes de l'environnement de programmation et essaient-ils de faire le pont avec certains ORM-kludge?

Il s'avère qu'il existe un certain nombre d'avantages à séparer les données et les requêtes de tout langage et environnement de programmation spécifiques.

• Indépendance des données. Dans la plupart des organisations, les données sont en fait accessibles par plusieurs applications. Une boutique peut avoir une base de données utilisée par le frontend Web, par un outil de support client, un moteur de reporting, etc. Les données elles-mêmes ont souvent une longue durée de vie, tandis que les applications vont et viennent. Le couplage des données à un environnement de programmation spécifique serait verrouillé dans un environnement de programmation spécifique. Mais les langages de programmation vont et viennent, tandis que les données vivent pour toujours.
• Requête ad hoc. Il est extrêmement pratique de pouvoir ouvrir une invite de base de données et écrire une requête. Si l'interrogation était étroitement couplée à l'environnement de programmation, ce serait une tâche de programmation et seuls les développeurs seraient en mesure de le faire.
• Évitez le verrouillage. SQL étant une norme, plusieurs fournisseurs peuvent proposer des systèmes de gestion de base de données plus ou moins interchangeables. Cela évite le blocage des fournisseurs et facilite la comparaison des produits.
• Couplage lâche. Le fait d'avoir une interface bien définie entre la couche d'application et la base de données permet de régler et d'optimiser la base de données indépendamment de la logique d'application.
• Interface partagée. L'interface de base de données étant indépendante de la logique d'application, des outils standard peuvent être utilisés pour le profilage, la réplication, l'analyse, etc.

C'est une assez bonne question que je traitais plusieurs fois dans ma tête. Un exemple de solution existante résolvant votre problème est une base de données graphique ArangoDB dans laquelle vous utilisez JavaScript (fonctionnant sur un moteur interne) pour écrire des contrôleurs qui peuvent générer des pages Web entières. Les données sont transmises vers / depuis le stockage à l'aide de JSON, elles sont donc accessibles en natif en JavaScript et les requêtes sont effectuées dans un langage de requête intégré. Ce cas est donc un exemple d'extension de JavaScript à exécuter dans la base de données.

Dans la pratique, ces contrôleurs ne doivent pas être exposés au public pour des raisons de sécurité, car une faille dans la configuration de la base de données ou un bogue entraînera l'exposition de vos précieuses données au public.

À mon avis, c'est une bonne approche et à considérer si la base de données prend en charge une sorte de fonctionnalité de carte / réduction qui mettra à jour les données agrégées / index de texte et d'autres données fréquemment interrogées en temps réel, en ajoutant une fine couche de sécurité entre les deux (appelez-la charger équilibreur) rendrait une application fonctionnelle exécutée dans une base de données distribuée.

1. En fait construit un tel système unifié

Oui, je l'ai fait dans Sciter .

Le script de Sciter est un " JavaScript ++ " qui a une persistance intégrée:

var ndb = Storage.open(pathname);
ndb.root = { ... root object ... };

Où ndb.rootest l'objet normal en termes de JS. Toutes ses propriétés et sous-objets accessibles depuis celui-ci sont persistants - stockés et récupérés dans la base de données en cas de besoin - de manière transparente pour le code:

ndb.root.accounts[2].firstName = "John";
var name = ndb.root.accounts[3].firstName;

Les données sont stockées dans la base de données soit sur le cycle GC, lorsque la mémoire est insuffisante, soit sur ndb.commit()appel explicite .

Storageclasse est accompagné par Indexclasse - collections persistables objets commandés avec des clés uniques / non-unique.

L'ensemble de fonctionnalités est similaire à MongoDB ou à d'autres bases de données NoSQL, mais l'ID ne nécessite pas d'ORM séparé - l'accès à la base de données se fait uniquement à l'aide de scripts.

Je suis absolument pour ça et je n'ai aucune idée par où commencer. SQL peut être génial et j'imagine que ce serait génial d'avoir toute cette puissance et les garanties transactionnelles directement dans votre langage de programmation polyvalent (au lieu d'avoir à écrire des requêtes sous forme de collections de chaînes ou d'utiliser, Dieu nous en garde, un ORM).

Le seul système qui se rapproche de votre idée que je connaisse s'appelle aquameta (slogan: "pile de développement Web construite dans PostgreSQL"; voir https://github.com/aquametalabs/aquameta , http://aquameta.org ). Il y a quelques vidéos d'introduction qui ne sont pas un peu moins folles que l'idée elle-même (youtube.com/watch?v=jz74upW7TN0, youtube.com/watch?v=cWGm9eYUYUk&t=29s, youtube.com/watch?v=xRoUQGUmiMg), et quand je dis fou, je veux dire qu'ils ont implémenté leur propre éditeur et leur propre système de contrôle de version dans Postgres.

Je pense que c'était exactement la raison d'être de l'invention de LINQ par Microsoft. Il est utilisé à grande échelle depuis plusieurs années, il est donc facile de trouver de la littérature à ce sujet et des réflexions sur des expériences du monde réel, à la fois positives et négatives. (La plupart des boutiques de développement .net l'adoptent.)

Un bon point de départ sur linq: https://docs.microsoft.com/en-us/dotnet/csharp/linq/