Justification DB

Postgresql

Vu que l'information que l'on compte utiliser aura un format bien précis, il nous est plus intéressant d'utiliser une base de données relationnelle pour pouvoir être plus stricts avec les données à stocker et pouvoir mettre des validations côté DB. D'autres fonctionnalités des DB SQL que l'on utilisera sont les foreign keys, JOIN et transactions pour mettre en lien les différents types de données et rendre atomique une série d'actions, avec la possibilité de rollback.

On a donc dû choisir entre MySQL et Postgres, étant les deux db relationnelles les plus utilisées, on a fini par choisir Postgres pour les raisons suivantes :

• Data types avancés : Postgres prend en charge les types de MySQL et ajoute des types plus avancés tels que du JSON, des Array d'autres types. Alors que pour avoir une relation 1-N il faudrait normalement faire une table supplémentaire.

• Réplication : Postgres permet d'avoir 2 ou plus DB répliquées, pour avoir du load-balancing et de la redondance.

• Performance en concurrence : Postgres est optimisé pour effectuer des requêtes en parallèle, notamment en lecture grâce aux index. Vu que sur une app web, on aura des connexions simultanées pour chaque utilisateur, cette optimisation est très nécessaire.

• Intégration dans python (async) : Python a une libraire codée en Cython qui implémente les interactions avec l'API postgres de façon asynchrone asyncpg. FastAPI, notre backend, est optimisé pour travailler en asynchrone, pour pouvoir gérer les requêtes simultanément. MySQL n'a pas cette intégration et donc à chaque interaction avec la DB, FastAPI devra "attendre" que l'opération soit exécutée avant de passer à autre chose.

• Légèreté & performances: une base de donnée légère est plus adaptée à notre client et à l'hébergement partagé. Postgres est moins gourmand que ses concurrents, à la fois pour la RAM et également pour le CPU. Malgré une basse consommation de RAM, il reste très puissant comparé à MySQL. source