Backend, API et données · Mixte

Bases de données : choisir et ne pas regretter

En une ligne : Dans la plupart des cas, une base de données relationnelle est la bonne réponse, et tout autre choix nécessite une raison qu'on peut énoncer en une phrase.

Pourquoi le relationnel par défaut

Cohérence, requêtes flexibles, contraintes qui préviennent les données cassées et des outils matures. La plupart de ce qui est considéré comme une « limitation relationnelle » se résout avec un bon schéma et des index.

Les magasins de documents conviennent quand la structure varie vraiment entre les enregistrements ; les clé-valeur pour le cache et l'état transitoire ; les séries temporelles pour les métriques. Ce sont des ajouts, pas des remplaçants.

Des décisions qui fixent l'avenir

Clés. Stables et immuables ; n'utilisez pas d'information commerciale comme clé.

Contraintes. Clés étrangères, unicité et non-nullité. Une contrainte dans le magasin vaut mieux qu'une vérification dans le code — elle attrape aussi le chemin auquel vous n'avez pas pensé.

Heures. Stockez dans un fuseau horaire cohérent et explicite, avec une heure de création et de mise à jour par enregistrement.

Ce qui casse vraiment les systèmes

Les requêtes en boucle qui créent des centaines d'appels au lieu d'un, un index manquant sur une colonne par laquelle vous filtrez, et les longues transactions qui bloquent. Les trois ne se révèlent qu'à volume réel.

Pour aller plus loin

Activez la journalisation des requêtes lentes dès le premier jour et vérifiez-la chaque semaine. Et quand vous ajoutez un index, mesurez — un index inutile ralentit les écritures et prend de la place, et tout plan de requête ne s'améliore pas de lui.