Utilisez simplement Postgres

• La plupart des applications web ont besoin d’un stockage de données persistant ; il est donc recommandé de choisir Postgres par défaut quand on crée une nouvelle application

Pourquoi pas sqlite ?

• sqlite est une bonne base de données, mais les données sont stockées dans un seul fichier
• Cela signifie que l’application ne s’exécute que sur une seule machine
• C’est adapté aux applications desktop ou mobiles, mais cela peut ne pas convenir à un site web
  • Il existe des cas de réussite avec sqlite pour des sites web, mais il s’agit généralement d’équipes qui ont construit elles-mêmes leurs serveurs et leur infrastructure
• Vous devrez peut-être renoncer aux sauvegardes automatiques de base de données fournies par la plateforme ainsi qu’à la possibilité de configurer plusieurs serveurs applicatifs

Pourquoi pas DynamoDB, Cassandra ou MongoDB ?

• Ces bases de données offrent d’excellentes performances, mais elles supposent beaucoup de prérequis :
  • connaître précisément ce que l’application doit faire et ses schémas d’accès
  • avoir besoin de monter à une très grande échelle de données
  • pouvoir renoncer à une partie de la cohérence
• Ces bases fonctionnent d’une manière proche d’une table de hachage distribuée ; il faut donc intégrer la connaissance des schémas de requête dans la manière de stocker les données
• Si les schémas d’accès (requêtes) changent, il peut être nécessaire de retraiter l’ensemble des données
• Dans une base relationnelle, on peut facilement ajouter des index pour exécuter des requêtes ; dans une base NoSQL, c’est plus difficile
• Elles sont peu adaptées aux requêtes analytiques
• Si un étudiant ou un développeur junior utilise MongoDB, il aura probablement besoin d’aide

Pourquoi pas Valkey ?

• Cette base de données, connue sous le nom de Redis, est surtout réputée comme cache très efficace
• Elle peut servir de base de données principale, mais cela pose plusieurs problèmes :
  • toutes les données sont stockées en RAM, ce qui la rend rapide, mais la capacité de RAM est limitée
  • elle impose des compromis en matière de modélisation des données

Pourquoi pas Datomic ?

• Si vous connaissez déjà cela, vous méritez une « étoile d’or »
• Datomic est une base NoSQL relationnelle qui n’a pas le problème de la « conception en amont » et possède quelques propriétés élégantes
  • elle stocke les données sous forme de paires EAVT (entity-attribute-value-time) au lieu de tables, et utilise des index génériques
  • quand on écrit une requête, il n’est pas nécessaire de se coordonner avec son auteur. Il suffit d’interroger la base telle qu’elle existe à un instant donné. Les nouvelles données, et même les suppressions (aussi appelées « retractions »), ne suppriment pas réellement les données précédentes
• Mais il y a aussi plusieurs inconvénients :
  • cela ne fonctionne qu’avec les langages de la JVM
  • en dehors de Clojure, l’API n’est pas bonne
  • les messages d’erreur provoqués par des requêtes mal structurées sont très peu utiles
  • l’outillage est limité, faute d’un écosystème comparable à celui des outils SQL

Pourquoi pas XTDB ?

• Les utilisateurs de Clojure créent beaucoup de bases de données
• C’est proche de Datomic, mais avec les caractéristiques suivantes :
  • une API HTTP est fournie, ce qui évite la dépendance à la JVM
  • les requêtes peuvent se faire selon deux axes : le « temps système » et le « temps de validité »
  • une API SQL est prise en charge
• Mais le plus gros problème, c’est que le projet est encore jeune. L’API SQL est arrivée l’an dernier, et le modèle de stockage complet a récemment changé
  • sera-t-il encore là dans 10 ans ? Le support à long terme reste incertain

Pourquoi pas Kafka ?

• Kafka est un excellent log « append-only », bien adapté au traitement de données à l’échelle du téraoctet
• Si vous voulez faire un travail de type event sourcing avec des données provenant de plusieurs services gérés par plusieurs équipes, cela fonctionne remarquablement bien
• Cependant
  • à petite échelle, une table Postgres suffit souvent largement en remplacement
  • créer des consommateurs Kafka est plus sujet aux erreurs qu’on ne le pense, car il faut au final suivre soi-même sa position dans le log
  • cela impose de gérer une infrastructure supplémentaire

Pourquoi pas ElasticSearch ?

• Si la recherche de données est une fonctionnalité centrale du produit, ElasticSearch est un bon choix
  • il faut ETL les données et gérer l’ensemble du processus, mais ElasticSearch a été conçu pour la recherche et le fait bien
• Mais si la recherche n’est pas la fonction principale, la recherche textuelle intégrée de Postgres suffit généralement
  • on pourra toujours ajouter plus tard un moteur de recherche dédié

Pourquoi pas MSSQL ou Oracle DB ?

• La vraie question à se poser est : « est-ce que cela vaut le prix demandé ? »
• Il faut prendre en compte non seulement le coût des licences, mais aussi celui du verrouillage fournisseur
• Si vous stockez vos données chez Oracle, vous paierez Oracle pour toujours et devrez continuer à former vos développeurs
  • il faut choisir pour toujours entre les fonctionnalités enterprise et son portefeuille
• Mieux vaut éviter de les utiliser sauf si certaines fonctions spécifiques sont absolument nécessaires
  • n’utilisez pas MSSQL à moins qu’il n’ait une fonctionnalité indispensable dont vous ne pouvez pas vous passer

Pourquoi pas MySQL ?

• Cette partie demande un peu l’aide du lecteur
• MySQL appartient à Oracle, et certaines fonctionnalités sont verrouillées dans l’édition enterprise
  • bien sûr, MySQL est utilisé depuis longtemps et dispose d’une édition gratuite largement répandue
• Je pense que Postgres est un meilleur choix, mais il me faudrait davantage d’informations sur MySQL

Pourquoi pas une base vectorielle IA ?

• La plupart des bases vectorielles IA sont des technologies récentes, avec les risques que cela implique
  • il faut être prudent avec les entreprises fondées sur la bulle de l’IA
• Même si votre entreprise n’est qu’un nouvel attrape-nigaud autour de l’IA, un simple import openai devrait suffire

Pourquoi pas Google Sheets ?

• Pas d’inconvénient particulier ; si vous en avez besoin, vous pouvez l’utiliser

[hilft]

Firestore...

[wedding]

Les articles qui affirment cela de manière aussi catégorique sont en général une erreur que commettent les juniors...

[nemorize]

À la place, je vais vous donner un C SV adorable.

[roxie]

zzz

[bus710]

Ça me fait penser à cette blague qui dit que, pour obtenir de bonnes informations, il faut d’abord faire du bait… haha.
Quoi qu’il en soit, comme postgresql est souvent la toute première chose que la plupart des développeurs backend utilisent…

[dicebattle]

Je pense que Postgres est le meilleur choix, mais j’ai besoin d’informations supplémentaires sur MySQL

Mdr;;;;

[koxel]

Le vrai problème de MySQL Enterprise, ce n’est pas la licence, c’est que même pour les clients payants, le support est vraiment à chier quand il y a un incident.
Avant, l’index de MySQL s’était corrompu et ça ne démarrait plus ; même en demandant de l’aide, Oracle se contentait de dire qu’ils ouvriraient un ticket de support et qu’ils feraient une assistance téléphonique.
Au final, le client a dit que ça n’irait pas, donc on a dû régler le problème nous-mêmes.
Plutôt que de faire confiance à Oracle et d’utiliser l’édition Enterprise, le gratuit, c’est ce qu’il y a de mieux..

[kaydash]

Pourquoi pas MariaDB, Impala, Hive ou Kudu ?

[koxel]

Les fonctionnalités enterprise de Mysql sont des fonctions pas vraiment nécessaires, comme son propre pool de connexions..
Si on est vraiment dans de l’enterprise, au lieu d’utiliser ça, installer un proxy SQL en frontal est bien plus efficace pour la répartition de charge.
J’aime bien Pgsql, mais balayer Mysql sans même se renseigner.. lol

[iolothebard]

Utilisez simplement MySQL…

• Pourquoi pas Postresql ? J’aurais besoin d’un petit coup de main sur ce point.

[love7peace]

Et MariaDB ??

[aer0700]

Voilà un post qui risque de susciter un très grand débat...

[aer0700]

La raison d’utiliser SQLite, c’est sa simplicité et le fait qu’il fonctionne très bien pour des tailles raisonnables.
Il suffit d’implémenter d’abord avec SQLite, puis, si besoin plus tard, passer à Postgres ne devrait pas poser de difficulté particulière.

[xguru]

Un énième article à la gloire de Postgres qui revient dès qu’on l’oublie. Maintenant, profitez-en simplement !

Utilisez simplement Postgres partout
PostgreSQL suffit largement
À partir de quand Postgres est-il devenu cool ?

[GN⁺]

Avis Hacker News

• Il y a beaucoup d’avis négatifs sur MongoDB, mais la plupart reposent sur des informations erronées

  • MongoDB convient bien aux premières phases
  • Il fonctionne aussi sans problème quand le volume de données augmente
  • Les problèmes de cohérence sont également bien résolus
  • MongoDB n’est pas une table de hachage distribuée comme Dynamo
  • Beaucoup de gens ne connaissent pas bien les fonctionnalités d’agrégation de MongoDB
  • Dire qu’il ne faut pas utiliser MongoDB sous prétexte qu’un développeur junior doit apprendre SQL est injustifié

• Avantages de SQLite

  • Comme il est basé sur un fichier, les sauvegardes sont faciles
  • Avec un ORM, on peut facilement passer de SQLite à Postgres

• Signaler des défauts techniques n’a pas vraiment de sens

  • Rick Houlihan de MongoDB travaille actuellement chez MongoDB

• Raisons de migrer de MySQL vers Postgres

  • MySQL, détenu par Oracle, présente un risque métier
  • Postgres offre davantage d’outils pour maintenir la cohérence des données
  • Les extensions de Postgres permettent de gagner du temps de développement
  • L’écosystème d’outils de Postgres est plus mature et plus complet

• Le support des tables temporelles dans Postgres est insuffisant

  • Il faut un versioning « bi-temporel » avec le temps système et le temps applicatif de SQL:2011
  • Dans les secteurs réglementés avec des exigences de reporting complexes, les tables temporelles sont idéales

• Je ne comprends pas pourquoi utiliser SQLite

  • Installer Postgres n’est pas difficile
  • Il faut expliquer la différence entre SQLite et Postgres

• Excuses pour avoir mal mentionné le nom de Rick Houlihan

  • La comparaison entre DynamoDB/Cassandra et MongoDB venait de sa conférence
  • MongoDB est une base de données qui stocke des informations dénormalisées et n’est pas flexible lorsque les schémas d’accès changent

• L’important est d’utiliser ce que l’on connaît et de déployer ce qui est utile

• MySQL est comme Javascript

  • Il y a beaucoup de mauvaises décisions et de facteurs de risque
  • Ça fonctionne bien, mais il n’y a pas vraiment de raison de l’utiliser quand Postgres existe

[touguy]

Postgres dispose de davantage d’outils pour maintenir la cohérence des données
=> Auriez-vous éventuellement un exemple ?

[leftliber]

Un inconvénient de SQLite par rapport à Postgres, c’est apparemment qu’il ne prend pas en charge les schémas. Quand on a plusieurs dizaines de tables, voire plus, il est plus propre de les organiser par schéma, mais comme SQLite ne le permet pas, on est obligé d’inclure toutes les distinctions dans les noms de table.