Mettre en place une base de données #9

New Issue

florian_briand · 2024-07-06T19:46:28+02:00

florian_briand commented

2024-07-06 19:46:28 +02:00

Définir le moteur de DB utilisé
- SQLite
Définir l'ORM utilisé
- SeaORM
Mettre en place la base de donnée
Documenter le setup & le run
Mettre en place une transaction simple

Description des techno possibles

SQL ou NoSQL ?

Je pense qu'au regard de la culture du milieu de la santé, s'appuyer sur une BDD relationnelle (SQL) sera plus approprié que de partir sur des technologies "NoSQL" comme MongoDB ou Redis.

Le gain "initial" de souplesse apporté par du NoSQL pourrait nous couter ultérieurement, et n'est plus aussi flagrant qu'il y a 10 ans, en particulier si l'on passe par un ORM.

ORMs

Diesel & SeaORM : les "gold standards" en Rust

Les deux principaux ORMs en Rust qu'on peut brancher sur des bases SQL sont Diesel et SeaORM. Ce sont des techno assez mature, avec des communautés grandissantes, qui paraissent donc tout à fait adapté à un projet industriel.

Une comparaison + détaillée de ces deux techno et de leurs paradigmes principaux sont disponibles ici : https://chatgpt.com/share/ab626995-737a-424b-a61f-6a4cc589547f

Les deux techno permettent de faire directement appel à des requêtes SQL bas niveau en cas de besoin, pour des situations où l'on souhaiterait se passer de l'ORM.

Les deux techno sont compatibles avec PostgreSQL, MySQL et SQLite.

Autres ORM

Prisma possède un ORM Rust maintenu par la communauté ( https://github.com/Brendonovich/prisma-client-rust ). Prisma permet de construire facilement des API Rest ou GraphQL par dessus une base de donnée. C'est approprié quand on a besoin de générer rapidement / facilement des "façades" requetables par dessus des bases complexes. Ça ne me semble pas être notre besoin, je ne pense donc pas que Prisma soit approprié

SGBD SQL

Le "gold standard" en SQL est aujourd'hui PostgreSQL. C'est libre (BSD), gratuit, puissant. C'est versatil en permettant du stockage relationnel et du stockage objet
C'est, par contre, plus lourd à mettre en place et faire tourner qu'un SGBD sous forme de "fichier" comme SQLite
Je ne vois pas d'intérêt à partir sur un autre moteur libre, comme MariaDB
On notera que les ORM listées plus haut ont, généralement, la possibilité de se brancher sur les 3 moteurs (MariaDB/SQLite/PostgreSQL), ce qui laisse la possibilité de démarrer avec un SQLite pour le POC et migrer vers une base Postgres plus tard.

- [x] Définir le moteur de DB utilisé - SQLite - [x] Définir l'ORM utilisé - SeaORM - [x] Mettre en place la base de donnée - [x] Documenter le setup & le run - [x] Mettre en place une transaction simple # Description des techno possibles ## SQL ou NoSQL ? Je pense qu'au regard de la culture du milieu de la santé, s'appuyer sur une BDD relationnelle (SQL) sera plus approprié que de partir sur des technologies "NoSQL" comme MongoDB ou Redis. Le gain "initial" de souplesse apporté par du NoSQL pourrait nous couter ultérieurement, et n'est plus aussi flagrant qu'il y a 10 ans, en particulier si l'on passe par un ORM. ## ORMs ### Diesel & SeaORM : les "gold standards" en Rust Les deux principaux ORMs en Rust qu'on peut brancher sur des bases SQL sont [Diesel](https://diesel.rs/) et [SeaORM](https://www.sea-ql.org/SeaORM/). Ce sont des techno assez mature, avec des communautés grandissantes, qui paraissent donc tout à fait adapté à un projet industriel. Une comparaison + détaillée de ces deux techno et de leurs paradigmes principaux sont disponibles ici : https://chatgpt.com/share/ab626995-737a-424b-a61f-6a4cc589547f Les deux techno permettent de faire directement appel à des requêtes SQL bas niveau en cas de besoin, pour des situations où l'on souhaiterait se passer de l'ORM. Les deux techno sont compatibles avec PostgreSQL, MySQL et SQLite. ### Autres ORM - Prisma possède un ORM Rust maintenu par la communauté ( https://github.com/Brendonovich/prisma-client-rust ). Prisma permet de construire facilement des API Rest ou GraphQL par dessus une base de donnée. C'est approprié quand on a besoin de générer rapidement / facilement des "façades" requetables par dessus des bases complexes. Ça ne me semble pas être notre besoin, je ne pense donc pas que Prisma soit approprié ## SGBD SQL - Le "gold standard" en SQL est aujourd'hui PostgreSQL. C'est libre (BSD), gratuit, puissant. C'est versatil en permettant du stockage relationnel et du stockage objet - C'est, par contre, plus lourd à mettre en place et faire tourner qu'un SGBD sous forme de "fichier" comme SQLite - Je ne vois pas d'intérêt à partir sur un autre moteur libre, comme MariaDB - On notera que les ORM listées plus haut ont, généralement, la possibilité de se brancher sur les 3 moteurs (MariaDB/SQLite/PostgreSQL), ce qui laisse la possibilité de démarrer avec un SQLite pour le POC et migrer vers une base Postgres plus tard.

florian_briand added the

enhancement

module/frontend

labels 2024-07-06 19:46:28 +02:00

florian_briand added this to the 0 - POC project 2024-07-06 19:46:28 +02:00

florian_briand added this to the 0 - POC milestone 2024-07-26 21:55:10 +02:00

nicolas_floquet commented

2024-07-26 22:08:26 +02:00

Pour info, je sais de source sûre --- une formation à ce logiciel--- que Winpharma se base sur MariaDB.

Pour info, je sais de source sûre --- une formation à ce logiciel--- que _Winpharma_ se base sur _MariaDB_.

theo commented

2024-07-26 22:21:49 +02:00

Tu aurais les raisons derrière ce choix @nicolas_floquet ?

👎 1

florian_briand commented

2024-07-28 00:05:20 +02:00

Ça paraît ug choix assez logique pour un logiciel de cet âge là, en mode serveur local : Oracle c'est uh peu overkill pour un tel contexte, et MySQL (qui a, depuis, été forké pour devenir MariaDB) était largement leader à l'époque.

Postgres est devenu une référence industrielle ces 10 dernières années seulement, avant c'était nu peu un truc geek :p

Ça paraît ug choix assez logique pour un logiciel de cet âge là, en mode serveur local : Oracle c'est uh peu overkill pour un tel contexte, et MySQL (qui a, depuis, été forké pour devenir MariaDB) était largement leader à l'époque. Postgres est devenu une référence industrielle ces 10 dernières années seulement, avant c'était nu peu un truc geek :p

florian_briand closed this issue

2024-07-28 00:05:20 +02:00

florian_briand reopened this issue

2024-07-28 00:05:25 +02:00

florian_briand referenced this issue

2024-08-17 15:40:08 +02:00

Afficher les informations d'un médicament #13

florian_briand added a new dependency 2024-08-17 15:41:10 +02:00

#13 Afficher les informations d'un médicament

kosssi commented

2024-08-17 16:44:26 +02:00

Nous avions parlé de DuckDB qui est une base de données type fichier comme SQLite mais avec une implémentation plus stricte du SQL, dont voici un wrapper pour Rust. Les avantages de cette base de données est d'être très rapide surtout lors de grosse base de données. Il est aussi possible d'utiliser un support S3 (seulement en read only pour l'instant ou en mode copie par exemple pour la base de données des médicaments). Il est aussi possible d'utiliser PostgreSQL en backend.

OMOP a mis en place un schéma pour DuckDB.

Je pose la question naïvement mais pourquoi vouloir mettre en place un ORM plutôt que l'implémentation direct d'un wrapper autour de la base de données que l'on aura choisi ?

Merci @florian_briand pour tes explications entre les 2 ORMs je préfère SeaORM pour le côté async mais aussi le côté moins verbeux et donc plus lisible.

SeaORM n'est pas compatible pour l'instant avec DuckDB, n'hésitez pas à mettre un +1 à la demande.

Nous avions parlé de [DuckDB](https://duckdb.org/) qui est une base de données type fichier comme _SQLite_ mais avec une implémentation plus stricte du _SQL_, dont voici un [_wrapper_](https://github.com/duckdb/duckdb-rs) pour _Rust_. Les avantages de cette base de données est d'être très rapide surtout lors de grosse base de données. Il est aussi possible d'utiliser un support S3 (seulement en read only pour l'instant ou en mode copie par exemple pour la base de données des médicaments). Il est aussi possible d'[utiliser _PostgreSQL_ en backend](https://duckdb.org/docs/extensions/postgres). OMOP a [mis en place un schéma pour DuckDB](https://github.com/OHDSI/CommonDataModel/tree/main/ddl/5.4/duckdb). Je pose la question naïvement mais pourquoi vouloir mettre en place un ORM plutôt que l'implémentation direct d'un wrapper autour de la base de données que l'on aura choisi ? Merci @florian_briand pour tes explications entre les 2 ORMs je préfère SeaORM pour le côté async mais aussi le côté moins verbeux et donc plus lisible. [SeaORM n'est pas compatible pour l'instant avec DuckDB](https://github.com/SeaQL/sea-orm/discussions/2330), n'hésitez pas à mettre un +1 à la demande.

florian_briand commented

2024-08-17 22:51:58 +02:00

Je pose la question naïvement mais pourquoi vouloir mettre en place un ORM plutôt que l'implémentation direct d'un wrapper autour de la base de données que l'on aura choisi ?

En Rust, l'avantage d'un ORM c'est le typage des requêtes et des résultats de requêtes.
Ça offre donc des garanties + fortes sur la validité des interactions avec la DB que si on écrit du SQL brut. C'est donc + robuste et + facile à maintenir, tout en ne nous bloquant pas dans les situations où l'ORM est trop limité (ou dans les situations où VIDAL nous file des requêtes SQL pré-écrites)

Merci @florian_briand pour tes explications entre les 2 ORMs je préfère SeaORM pour le côté async mais aussi le côté moins verbeux et donc plus lisible.

J'ai aussi une petite préférence pour SeaORM, en particulier pour l'async et divers petits indices qui me font penser que l'API est un peu plus "moderne" que Diesel.

SeaORM n'est pas compatible pour l'instant avec DuckDB, n'hésitez pas à mettre un +1 à la demande.

Ah, merci, j'ai cherché sans succès :)

> Je pose la question naïvement mais pourquoi vouloir mettre en place un ORM plutôt que l'implémentation direct d'un wrapper autour de la base de données que l'on aura choisi ? En Rust, l'avantage d'un ORM c'est le typage des requêtes et des résultats de requêtes. Ça offre donc des garanties + fortes sur la validité des interactions avec la DB que si on écrit du SQL brut. C'est donc + robuste et + facile à maintenir, tout en ne nous bloquant pas dans les situations où l'ORM est trop limité (ou dans les situations où VIDAL nous file des requêtes SQL pré-écrites) > Merci @florian_briand pour tes explications entre les 2 ORMs je préfère SeaORM pour le côté async mais aussi le côté moins verbeux et donc plus lisible. J'ai aussi une petite préférence pour SeaORM, en particulier pour l'async et divers petits indices qui me font penser que l'API est un peu plus "moderne" que Diesel. > [SeaORM n'est pas compatible pour l'instant avec DuckDB](https://github.com/SeaQL/sea-orm/discussions/2330), n'hésitez pas à mettre un +1 à la demande. Ah, merci, j'ai cherché sans succès :)

florian_briand commented

2024-08-17 23:09:57 +02:00

Nous avions parlé de DuckDB qui est une base de données type fichier comme SQLite mais avec une implémentation plus stricte du SQL, dont voici un wrapper pour Rust. Les avantages de cette base de données est d'être très rapide surtout lors de grosse base de données. Il est aussi possible d'utiliser un support S3 (seulement en read only pour l'instant ou en mode copie par exemple pour la base de données des médicaments). Il est aussi possible d'utiliser PostgreSQL en backend.

J'avais, en effet, zappé cette discussion autour de DuckDB. Le gros inconvénient, ça me parait être l'absence d'ORM compatible, qui oblige à utiliser le wrapper que tu as identifié, et qui est très bas niveau.

Je vois l'avantage de la "simplicité" de setup de DuckDB : pas besoin d'installer un serveur de DB dans chaque poste client, par exemple. Ce qu'offre aussi SQLite ... mais sans la puissance de calcul que semble offrir DuckDB (cela dit, il faudrait vérifier si ces promesses valent sur des machines "modestes" ; car ils annoncent tout traiter en mémoire ... je me demande ce que ça donne sur des PC avec peu de RAM)

> Nous avions parlé de [DuckDB](https://duckdb.org/) qui est une base de données type fichier comme _SQLite_ mais avec une implémentation plus stricte du _SQL_, dont voici un [_wrapper_](https://github.com/duckdb/duckdb-rs) pour _Rust_. Les avantages de cette base de données est d'être très rapide surtout lors de grosse base de données. Il est aussi possible d'utiliser un support S3 (seulement en read only pour l'instant ou en mode copie par exemple pour la base de données des médicaments). Il est aussi possible d'[utiliser _PostgreSQL_ en backend](https://duckdb.org/docs/extensions/postgres). J'avais, en effet, zappé cette discussion autour de DuckDB. Le gros inconvénient, ça me parait être l'absence d'ORM compatible, qui oblige à utiliser le wrapper que tu as identifié, et qui est très bas niveau. Je vois l'avantage de la "simplicité" de setup de DuckDB : pas besoin d'installer un serveur de DB dans chaque poste client, par exemple. Ce qu'offre aussi SQLite ... mais sans la puissance de calcul que semble offrir DuckDB (cela dit, il faudrait vérifier si ces promesses valent sur des machines "modestes" ; car ils annoncent tout traiter en mémoire ... je me demande ce que ça donne sur des PC avec peu de RAM)

florian_briand self-assigned this 2024-08-18 23:48:38 +02:00

kosssi commented

2024-09-02 15:52:19 +02:00

Après réflexion, je pense que partir sur SeaORM avec SQLite me parait être le plus pragmatique, nous simplifiant dans un premier temps le dev/déploiement.

Après réflexion, je pense que partir sur _SeaORM_ avec _SQLite_ me parait être le plus pragmatique, nous simplifiant dans un premier temps le dev/déploiement.

theo closed this issue

2024-09-08 20:52:35 +02:00

theo commented

2024-09-08 20:52:43 +02:00

Ca me convient 👍

theo reopened this issue

2024-09-08 20:52:43 +02:00

florian_briand referenced a pull request that will close this issue

2024-09-16 23:09:07 +02:00

Setup de SeaORM + SQLite comme base de données #64

florian_briand added

module/backend