A l'inverse, la complexité du SQL vient du fait qu'il essaye de cacher que parfois que l'accès se fait avec une table de hash, et parfois, il parcourt entièrement les tables.
Avec la mode des μservices, dont il est possible de tout réécrire entre 2 versions d'un logiciel ( ce qui est un impossible pour un gros monolithe et qui rend douloureux tout changement de technologie), il y a un peu de code avec une BDD (genre un modèle DDD persisté, et qui sort en API REST HTTP JSON ou XML ou en protobuf ou les 3).
Est-ce qu'il serait délirant d'avoir un vrai langage classique lié avec une BDD dans le but de faire un microservice complet ? L'API devrait être simplifié pour fournir les garanties ACID, mais on pourrait éviter les acrobaties dés qu'il faut faire un truc un peu compliqué.
[^] # Re: N'importe quoi !
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Interview de Dimitri Fontaine, contributeur majeur à PostgreSQL. Évalué à 6.
A l'inverse, la complexité du SQL vient du fait qu'il essaye de cacher que parfois que l'accès se fait avec une table de hash, et parfois, il parcourt entièrement les tables.
Avec la mode des μservices, dont il est possible de tout réécrire entre 2 versions d'un logiciel ( ce qui est un impossible pour un gros monolithe et qui rend douloureux tout changement de technologie), il y a un peu de code avec une BDD (genre un modèle DDD persisté, et qui sort en API REST HTTP JSON ou XML ou en protobuf ou les 3).
Est-ce qu'il serait délirant d'avoir un vrai langage classique lié avec une BDD dans le but de faire un microservice complet ? L'API devrait être simplifié pour fournir les garanties ACID, mais on pourrait éviter les acrobaties dés qu'il faut faire un truc un peu compliqué.
On éviterait ainsi la communication réseau.
"La première sécurité est la liberté"