N'utilisez pas Prisma ORM avant de lire ceci !

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 s’est présenté sous forme de stockage grillé. J'ai exécuté migrates pendant la journée, et c'était juste lourd sur neondb. Et ce n'était même pas un énorme projet.

Et Prisma ne se contente pas de créer les migrations, il 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 quand il s'agit de stockage, il aime éclabousser :

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, notamment dans les bases de données relationnelles, comme Postgres.

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

SQL "sur le clou" : 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 surprises dans la facture. Vous savez exactement ce que fait chaque ligne de code et vous ne trouverez pas de journaux ou de tables cachées encombrant votre espace.

2. Pas de poids mort : En utilisant du SQL direct, ce que vous écrivez est ce qui va à la banque. Il n’y a pas de métadonnées, de migrations ou de logs alourdissant les enjeux.

3. Plus de performances : Direct SQL, lorsqu'il est bien fait, 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. Pas d'affaires cachées : Pas de tables créées de toutes pièces ni de journaux de transactions qui s'accumulent. Le contrôle est à vous, 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 faire 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.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!