Comment ajouter une base de données à votre application (sans perdre de données plus tard)
Pour ajouter une base de données à votre application, choisissez une base relationnelle gérée (Postgres est le choix habituel), gardez sa chaîne de connexion dans un secret côté serveur, créez une table par type d'élément que votre application stocke, et faites en sorte que votre serveur, jamais le navigateur, lise et écrive dans cette base. Si vous construisez avec un créateur d'applications IA, vous pouvez généralement simplement dire « enregistre ceci dans une base de données » et l'agent crée les tables et le code; votre rôle est de bien décrire les données et de vérifier qu'elles persistent vraiment.
Ce guide couvre quand vous avez besoin d'une base de données, les principales options, comment décrire vos données et les erreurs qui causent des pertes ou des fuites de données.
Quand votre application a besoin d'une base de données
Vous avez besoin d'une base de données lorsque votre application doit se souvenir de quelque chose après la fermeture de la page, ou partager des données entre des personnes. Signes typiques :
- Des visiteurs envoient quelque chose : un formulaire, une inscription, une réservation, une commande
- Les utilisateurs ont des comptes avec leur propre contenu enregistré
- Un administrateur doit voir ou modifier ce que d'autres ont créé
- Vous voulez des rapports ou des totaux dans le temps
Vous n'en avez pas besoin pour un site statique où tout le monde voit le même contenu, comme un portfolio ou une simple page d'accueil. Si vous ne savez pas exactement ce qu'est une base de données, lisez d'abord qu'est-ce qu'une base de données.
Vos options
| Option | Ce que c'est | Idéal pour | Compromis |
|---|---|---|---|
| Base de données intégrée à votre créateur d'applications | Une base créée et connectée pour votre projet | La plupart des applications créées avec un créateur IA | Liée à l'hébergement de cette plateforme; l'exportation et les sauvegardes dépendent de la plateforme |
| Postgres ou MySQL géré | Une base relationnelle hébergée que vous souscrivez séparément | Les applications que vous hébergez vous-même, ou que plusieurs services partagent | Vous gérez les clés, les limites de connexion et les forfaits |
| Backend-as-a-service | Base de données, authentification, stockage et API dans un seul produit | Les applications surtout côté interface qui veulent une connexion prête à l'emploi | Plus de concepts propres au fournisseur à apprendre |
| Base de données documentaire (NoSQL) | Stocke des documents flexibles de type JSON | Des données très irrégulières | Les relations et les rapports sont plus difficiles |
| Un tableur comme base de données | Google Sheets ou similaire via une API | Petits outils internes, prototypes | Lent, sans véritables contraintes, se brise lors de modifications simultanées |
Pour la plupart des petites et moyennes applications web, une base relationnelle comme Postgres est le bon choix par défaut. Elle gère bien les relations (un client a plusieurs commandes), garde les données cohérentes et vous permet de répondre plus tard à des questions avec SQL. Consultez qu'est-ce que Postgres pour un aperçu en langage simple.
Décrivez vos données avant de construire
La chose la plus utile que vous puissiez faire est d'écrire les éléments que votre application stocke et comment ils sont liés. Vous n'avez pas besoin de jargon de base de données. Pour une application de réservation :
- Clients : nom, courriel, téléphone
- Services : nom, durée, prix
- Réservations : quel client, quel service, heure de début, statut (en attente, confirmée, annulée)
Cela fait trois tables. « Quel client » et « quel service » deviennent des liens (clés étrangères) entre elles. Bien faire cela tôt compte beaucoup plus que n'importe quel choix technologique, car modifier la structure de données qui contient déjà de vraies lignes est plus difficile que de changer la mise en page d'une page.
Quelques règles empiriques :
- Une table par type d'élément. Ne mettez pas les commandes dans une colonne de texte du client.
- Donnez à chaque ligne un identifiant et une date de création. Vous en aurez besoin plus tard.
- Utilisez les bons types. Les dates comme dates, l'argent en cents entiers ou en type décimal, pas en texte.
- Marquez les champs obligatoires comme tels. Laissez la base de données rejeter les données erronées, pas seulement le formulaire.
Exemples de requêtes
Commencez par une fonctionnalité à la fois plutôt que de décrire tout un schéma d'un coup :
Ajoute une base de données à cette application. Crée une table de réservations avec le nom du client, le courriel, le service, l'heure de début et le statut (en attente, confirmée, annulée; par défaut en attente). Enregistre les soumissions du formulaire de réservation dans cette table, affiche un message de succès, et ajoute une page d'administration qui liste les réservations, de la plus récente à la plus ancienne.
Puis élargissez-la :
Ajoute une table de services (nom, durée en minutes, prix en cents). Remplace le champ de service en texte libre des réservations par un lien vers les services, et migre les réservations existantes sans en supprimer aucune.
Et renforcez-la :
Assure-toi que toutes les lectures et écritures de la base se font sur le serveur. Le navigateur ne doit jamais recevoir la chaîne de connexion à la base. Valide le courriel et l'heure de début sur le serveur avant l'insertion.
Étape par étape
- Listez vos données comme ci-dessus : éléments, champs, liens entre eux.
- Créez la base de données. Dans un créateur IA, demandez-la dans le clavardage. Ailleurs, créez une instance Postgres gérée et copiez sa chaîne de connexion.
- Enregistrez la chaîne de connexion comme secret (une variable d'environnement sur le serveur), jamais dans le code. Consultez variables d'environnement et secrets.
- Créez les tables. Utilisez des migrations, c'est-à-dire des scripts versionnés qui modifient le schéma, pour que les changements soient répétables et réversibles.
- Construisez les routes serveur qui créent, lisent, modifient et suppriment des lignes (CRUD). Le navigateur appelle ces routes; il ne parle jamais directement à la base.
- Reliez l'interface à ces routes : formulaires qui enregistrent, listes qui se chargent, états vides quand il n'y a encore rien.
- Testez la persistance. Soumettez quelque chose, rechargez la page, ouvrez-la dans un autre navigateur. Si les données ne sont pas là, elles n'ont pas été enregistrées dans la base.
- Vérifiez les accès. Connectez-vous avec un deuxième utilisateur et confirmez que vous ne pouvez pas voir ni modifier les données du premier.
- Publiez, puis testez à nouveau sur l'URL en ligne, car l'application publiée peut utiliser une connexion différente de votre aperçu.
Erreurs courantes
- Enregistrer dans le navigateur et croire que c'est sauvegardé. localStorage semble fonctionner jusqu'à ce que quelqu'un ouvre l'application sur un autre appareil. Testez toujours dans un second navigateur.
- Mettre la chaîne de connexion dans le code de l'interface. N'importe qui peut lire le code de l'interface. Cela donne accès à toute votre base de données.
- Aucune vérification d'accès. « Afficher mes commandes » doit filtrer par l'utilisateur connecté côté serveur, pas dans l'interface. C'est la faille de sécurité la plus courante dans les applications créées avec l'IA; notre liste de contrôle de sécurité la couvre.
- Modifications destructives du schéma. Demander de « renommer la table » ou de « changer la structure » peut la supprimer puis la recréer. Quand il existe de vraies données, dites « migre les lignes existantes, ne supprime rien ».
- Stocker des fichiers dans la base. Les images et les PDF doivent aller dans un stockage de fichiers, avec seulement leur URL ou leur clé dans une table. Consultez comment ajouter le téléversement de fichiers.
- Aucune sauvegarde. Sachez comment votre plateforme sauvegarde les données et comment les restaurer avant d'avoir des clients.
Liste de vérification
- Chaque type d'élément a sa propre table avec un identifiant et une date de création
- Les champs obligatoires et les types sont imposés par la base de données
- La chaîne de connexion ne se trouve que dans des secrets côté serveur
- Toutes les lectures et écritures passent par des routes serveur
- Chaque utilisateur ne peut lire et modifier que ses propres lignes
- Les données survivent à un rechargement et apparaissent dans un autre navigateur
- Les changements de schéma utilisent des migrations et conservent les lignes existantes
- Vous savez comment fonctionnent les sauvegardes et les restaurations
- L'application en ligne a été testée après la publication
Ajouter une base de données dans Mythex
Dans Mythex, chaque projet peut obtenir sa propre base de données Postgres dédiée, dans les forfaits Free et Pro. Vous n'avez généralement pas à cliquer sur un bouton séparé pour la « rattacher » : demandez-la dans le clavardage (« enregistre les courriels de la liste d'attente dans une base de données ») ou tapez /database, et les détails de connexion sont injectés dans l'espace de travail et dans votre application publiée. Les paramètres du projet indiquent si une base est active.
La base de données se met en veille après 5 minutes d'inactivité et se réveille à la requête suivante. L'utilisation publiée est facturée pour le temps pendant lequel elle a été réellement active, à partir du même solde de crédits que celui utilisé pour créer. Si vous ajoutez une base de données après avoir déjà publié, publiez de nouveau pour que l'application en ligne en tienne compte.
Consultez Base de données et la recette Créer une application CRUD dans la documentation. Pour la partie connexion des données propres à chaque utilisateur, lisez comment ajouter une connexion à votre application.
Questions
Ai-je besoin d'une base de données pour mon application?
Vous en avez besoin dès que votre application doit se souvenir de quelque chose après la visite ou partager des données entre utilisateurs : inscriptions, commandes, réservations, publications ou paramètres. Un site statique qui montre le même contenu à tout le monde n'en a pas besoin.
Quelle base de données utiliser pour une petite application web?
Une base relationnelle comme Postgres est un choix sûr pour la plupart des petites applications web. Elle gère bien les utilisateurs, les commandes, les relations et les rapports, elle est largement prise en charge, et vous la dépasserez rarement à petite échelle.
Puis-je stocker les données dans le navigateur plutôt que dans une base de données?
Le stockage du navigateur, comme localStorage, n'existe que sur un appareil, dans un seul navigateur, et l'utilisateur peut le vider à tout moment. C'est acceptable pour des préférences comme le choix du thème, mais pas pour ce que vous ou d'autres utilisateurs devez retrouver plus tard.
Mythex inclut-il une base de données?
Oui. Un projet Mythex peut obtenir sa propre base de données Postgres dédiée, dans les forfaits Free et Pro. Vous la demandez dans le clavardage ou avec la commande /database, et les détails de connexion sont injectés pour vous. L'utilisation est payée à partir du même solde de crédits que la création.