Imaginez le chaos : vous créez une base de données gratuite dans NeonDB avec 0,5 Go de stockage et vous vous dites : "bien, je vais utiliser un niveau gratuit pour les tests" . Puis, quelques heures plus tard, arrive l'e-mail fatal : "Votre espace de stockage a été consommé !". Wow, qu'est-ce que tu veux dire ? Nous n'avons même pas eu le temps de réchauffer la chaise ! La réponse ? J'ai utilisé le glorieux Prisma ORM et, pour m'améliorer, j'ai effectué plusieurs migrations tout au long de la journée, en modélisant simplement le schéma.

Comprenons ce qui s'est passé et, bien sûr, pourquoi parfois le bon vieux SQL est encore mille fois meilleur.

Vous devez d’abord vous contextualiser. J'enregistrais la classe 124 de CrazyStack (mon bootcamp Node et React). Et il est possible d'utiliser postgres ou mongodb sans ORM. Cependant, un étudiant m'a demandé sur WhatsApp d'inclure Prisma dans le projet. Hé, j'ai décidé de faire l'expérience.

Prisma ORM : simple mais cher

Prisma est cette chose qui semble parfaite. "Je vais faire abstraction des requêtes de base de données, gagner du temps, c'est le nouveau battage médiatique." Mais surprise ! Il n’y a pas de déjeuner gratuit, et ce rango se présentait sous forme de stockage grillé. J'ai exécuté migrates pendant la journée, et c'était tout simplement lourd sur neondb. Et ce n'était même pas un énorme projet.

Et Prisma crée non seulement les migrations, mais laisse également des tables et des journaux supplémentaires en bonus. Si, comme moi, vous testez des choses et effectuez des migrations à gauche et à droite, ce cadeau finit par venir du grec.

Prisma est très bien, mais en matière de stockage, il aime tout mettre en œuvre :

1. Migrations rondes : chaque fois que j'exécutais une migration, Prisma créait et stockait de nouvelles migrations. Chacun avec son propre petit paquet de métadonnées, de journaux et de tables.

2. Journaux qui se multiplient : Pour garantir que tout se passe bien (ou pour vous faciliter la vie lorsque cela se produit), Prisma enregistre des journaux détaillés. Mais ces logs s'accumulent et, comme je ne suis pas sur une banque "illimitée", ils deviennent vite un problème.

3. Surcharge avec des tables auxiliaires : En plus des migrations, Prisma crée également des tables supplémentaires pour suivre diverses choses, en particulier dans les bases de données relationnelles, telles que Postgres.

En fin de compte, ce qui semblait être un outil magique pour simplifier la vie a fini par manger mon NeonDB.

SQL "Na Nail" : Pourquoi moins c'est plus

Et c'est là qu'intervient la bonne vieille approche SQL. Oui, Prisma est génial et fait gagner du temps, mais parfois cela complique les choses. Parlons des avantages d'abandonner ORM et d'écrire vos requêtes à la main :

1. Contrôle Absolu : Il n'y a pas de surprise dans l'addition. Vous savez exactement ce que fait chaque ligne de code et vous ne trouverez pas de journaux ou de tables cachées occupant votre espace.

2. Aucun poids mort : en utilisant du SQL direct, ce que vous écrivez est ce qui va à la banque. Aucune métadonnée, migration ou journal n'alourdit les enjeux.

3. Plus de performances : Direct SQL, lorsqu'il est bien exécuté, consomme beaucoup moins d'espace et de ressources. C'est idéal pour les petites banques comme NeonDB pour ceux qui sont freeganistes comme moi.

4. Aucune affaire cachée : pas de tables créées à partir de zéro ni de journaux de transactions qui s'accumulent. Le contrôle vous appartient, et à vous seul.

Morale de l'histoire :

Si, comme moi, vous aimez tester des outils et faire des expériences rapides, réfléchissez-y à deux fois avant de lancer un Prisma ORM dans votre base de données avec peu d'espace. Le Prisma est-il une merveille ? ET. Mais, dans une banque limitée comme NeonDB, c'est comme organiser une fête et découvrir que la bière que vous avez achetée ne suffira pas à tout le monde.

Parfois, SQL « à la volée » est le moyen le plus sûr, vous donnant un contrôle exact sur ce qui entre dans la base de données. Et la leçon est la suivante : la prochaine fois, je réfléchirai mieux avant d'exécuter une migration après l'autre sur une banque de 0,5 Go.