Discussion :

[MivGabin]

Bonjour à tous,

De plus en plus de clients s'intéressent au "NO SQL", plus particulièrement avec Azure. Que l'idée soit bonne ou non, les faits sont là et les besoins que mon outil puisse s'y connecter se créent.
Seulement voilà, si j'ai bien trouvé quelques infos sur l'utilisation de Delphi et des "Comptes de stockage" sur Azure, mes recherches sont vaines concernant Cosmos DB (qui semble aujourd'hui être le gros mot derrière le No SQL selon Azure).

Avez-vous déjà expérimenté quelque chose sur le sujet ? Des articles intéressants à ce propos ? Que ce soit en français ou en anglais, je n'ai vraiment rien trouvé d'intéressant pour le moment.

Merci d'avance pour votre aide !

[SergioMaster]

Bonjour,

je ne connais pas CosmosDB et très peu NO SQL. La curiosité l'emportant j'ai quand même fait un petit tour sur le site cosmos db
Ce que je retiens surtout c'est

Développement d’application rapide et flexible avec des kits de développement logiciel (SDK) pour les langages populaires, une API Core (SQL) native et des API MongoDB, Cassandra et Gremlin, ainsi qu’une analytique sans ETL (extraction, transformation et chargement)

en particulier le mot API. Ce dernier me fait écrire que cela pourrait être abordé en utilisant les divers composants REST (il faut dire que je suis à fond dedans en ce moment)
Autre piste, j'ai vu ceci, or du Delphi<->Phyton ça c'est possible
https://blogs.embarcadero.com/fr/get...python4delphi/ traduit ! c'est rare. Cela dit n'en déplaise au traducteur la plupart des ressources Python4Delphi (vidéos,blogs restent en anglais)

Que de choses intéressantes pour ma future retraite ! je rajoute à mon agenda contenant déjà PHP,Firebase,Raspberry ...

[ShaiLeTroll]

De plus en plus de clients s'intéressent au "NO SQL", plus particulièrement avec Azure. Que l'idée soit bonne ou non, les faits sont là et les besoins que mon outil puisse s'y connecter ...

C'est du développement spécifique, non parce qu'un client qui impose comme ça une contrainte technique à un éditeur de logiciel c'est plutôt particulier.
Tu n'as pas la possibilité de répondre à ton client, proposer moi une API REST pour consommer vos données et je me ferais un plaisir de le faire ?

Sinon, tu es bien parti pour acheter chez CDATA un Driver FireDAC

[SergioMaster]

CDATA un Driver FireDAC

Tiens, j'avais oublié ça tu pensais à celui là https://www.cdata.com/drivers/mongodb/firedac/ ou les différents trucs Azure ?
Je ne vois rien sur CosmosDB

[ShaiLeTroll]

Plutôt celui là : https://cdn.cdata.com/help/EHG/fire/default.htm et https://www.cdata.com/kb/tech/cosmos...ad-vcl-app.rst via https://www.cdata.com/drivers/cosmosdb/firedac/


Et sinon, un TRESTClient doit aussi fonctionner mais faut s'accrocher car ça va être assez musclé de le faire à la main, déjà bien maitrisé l'accès Azure OAuth2, trouver le bon scope Graph et comprendre les requêtes JSON a envoyer, voir CRUD associé aux verbes HTTP

[pprem]

Sinon, tu es bien parti pour acheter chez CDATA un Driver FireDAC

Attention : ils ne sont toujours disponibles que pour Windows sur processeurs x86 ou X86_64.

L'accès aux "bases de données" No SQL se fait uniquement par des API de programmation, mais en fait c'est aussi le cas des bases de données relationnelles SQL classiques. La différence c'est que le No SQL est en général utilisable par le web avec des requêtes http/s ou en sockets directement selon le cas.

Partir sur l'utilisation de bases No SQL sur des applications de gestion de données "standards" n'a aucun sens.

C'est essentiellement fait pour du stockage de gros volumes de données indépendantes les unes des autres. Toutes les relations et index sont à faire à la main comme dans l'ancien temps (ce qui est assez cohérent en fait puisque c'est un gros retour en arrière), sauf sur certains moteurs qui proposent quand même une classification des données proposées.

[SergioMaster]

Plutôt celui là https://www.cdata.com/drivers/cosmosdb/firedac/

Je suis bigleux ! je ne l'avais pas vu !

Attention : ils ne sont toujours disponibles que pour Windows sur processeurs x86 ou X86_64.

et pour l'instant pas encore portés pour Delphi 11

[MivGabin]

Bonjour,

je ne connais pas CosmosDB et très peu NO SQL. La curiosité l'emportant j'ai quand même fait un petit tour sur le site cosmos db
Ce que je retiens surtout c'est

en particulier le mot API. Ce dernier me fait écrire que cela pourrait être abordé en utilisant les divers composants REST (il faut dire que je suis à fond dedans en ce moment)
Autre piste, j'ai vu ceci, or du Delphi<->Phyton ça c'est possible
https://blogs.embarcadero.com/fr/get...python4delphi/ traduit ! c'est rare. Cela dit n'en déplaise au traducteur la plupart des ressources Python4Delphi (vidéos,blogs restent en anglais)

Que de choses intéressantes pour ma future retraite ! je rajoute à mon agenda contenant déjà PHP,Firebase,Raspberry ...

Très intéressant comme article, au delà du NO SQL, j'aurais appris quelque chose concernant ce Delphi<->Python.

C'est du développement spécifique, non parce qu'un client qui impose comme ça une contrainte technique à un éditeur de logiciel c'est plutôt particulier.
Tu n'as pas la possibilité de répondre à ton client, proposer moi une API REST pour consommer vos données et je me ferais un plaisir de le faire ?

Je me suis sûrement mal exprimé... Ce n'est pas une demande précise d'UN client, mais nous constatons de plus en plus ce mouvement vers Azure et son No SQL... De ce fait, nous cherchons à l'intégrer dans notre logiciel, toujours dans l'optique d'être le plus en avance possible sur les technos actuelles et futures !

Attention : ils ne sont toujours disponibles que pour Windows sur processeurs x86 ou X86_64.

L'accès aux "bases de données" No SQL se fait uniquement par des API de programmation, mais en fait c'est aussi le cas des bases de données relationnelles SQL classiques. La différence c'est que le No SQL est en général utilisable par le web avec des requêtes http/s ou en sockets directement selon le cas.

Partir sur l'utilisation de bases No SQL sur des applications de gestion de données "standards" n'a aucun sens.

C'est essentiellement fait pour du stockage de gros volumes de données indépendantes les unes des autres. Toutes les relations et index sont à faire à la main comme dans l'ancien temps (ce qui est assez cohérent en fait puisque c'est un gros retour en arrière), sauf sur certains moteurs qui proposent quand même une classification des données proposées.

Merci pour les infos et conseils...
Ça correspond donc bien à ce que j'avais cru comprendre, un univers pour le moment relativement fermé, si ce n'est ce composant pour FireDac, qui semble un peu mystérieux.