この混乱を想像してみてください。あなたは NeonDB に 0.5GB のストレージを持つ無料のデータベースを作成し、「よし、テストには無料枠を使用してみよう」と考えたとします。 。そして数時間後、「ストレージが消費されました!」 という致命的なメールが届きます。うわー、どういう意味ですか？椅子を温める時間さえありませんでした。答えは？私は素晴らしい Prisma ORM を使用し、改善するために、スキーマのモデリングだけを行いながら、1 日を通して数回の移行を実行しました。

何が起こったのか、そしてもちろん、古き良き SQL が依然として千倍も優れている場合がある理由を理解しましょう。

まず、自分自身の状況を把握する必要があります。私は CrazyStack クラス 124 (Node および React ブートキャンプ) を記録していました。 ORM なしで postgres または mongodb を使用することも可能です。しかし、ある学生が WhatsApp で私に、プロジェクトに Prisma を含めるように頼んできたのです。やあ、実験してみることにしました。

Prisma ORM: シンプルだが高価

Prisma は完璧に見えるものです。 「データベース クエリを抽象化し、時間を節約します。これが新しい宣伝です。」しかし、びっくり！無料のランチはなく、このランゴはトーストされたストレージの形で提供されました。日中に maigrates を実行しましたが、neondb が重かっただけです。それは大規模なプロジェクトでもありませんでした。

Prisma は移行を作成するだけでなく、ボーナスとして追加のテーブルとログも残します。私と同じように、物事をテストし、左右に移行を実行している場合、この贈り物は最終的にギリシャからのものになります。

Prisma は非常に優れていますが、ストレージに関しては全力を尽くすのが好きです:

1. ラウンド移行: 移行を実行するたびに、Prisma は新しい移行を作成して保存しました。それぞれに、メタデータ、ログ、テーブルの独自の小さなパッケージが含まれています。

2. 増殖するログ: 問題が起こらないように (または問題が起こったときに作業を楽にするために)、Prisma は詳細なログを記録します。しかし、これらのログは蓄積され、私は「無制限」の銀行に加入していないので、すぐに問題になります。

3. 補助テーブルによるオーバーロード: 移行に加えて、Prisma は、特に Postgres などのリレーショナル データベースで、さまざまなことを追跡するための追加のテーブルも作成します。

結局のところ、生活を簡素化する魔法のツールのように見えたものが、私の無料の NeonDB を使い果たしてしまったのです。

SQL「Na Nail」: 少ない方が良い理由

ここで古き良き SQL アプローチが登場します。はい、Prisma は優れており、時間を節約しますが、場合によっては状況が複雑になるだけです。 ORM を放棄してクエリを手動で記述することの利点について話しましょう:

1. 絶対制御: この法案には驚くようなことはありません。コードの各行が何を行っているかを正確に把握でき、ログや隠しテーブルがスペースを消費することはありません。

2. No Dead Weight: 直接 SQL を使用すると、記述した内容がそのまま銀行に送金されます。負担となるメタデータ、移行、ログはありません。

3. パフォーマンスの向上: Direct SQL を適切に実行すると、消費するスペースとリソースが大幅に減ります。私のようなフリーガニストにとっては、NeonDB のような小規模銀行に最適です。

4. 隠れたビジネスはありません: ゼロから作成されたテーブルや蓄積されるトランザクション ログはありません。コントロールはあなたのものであり、あなただけのものです。

物語の教訓:

私と同じように、ツールをテストしたり簡単な実験をしたりするのが好きな人は、スペースが少ないデータベースに Prisma ORM を投入する前によく考えてください。プリズマは不思議ですか？そして。しかし、NeonDB のような限られた銀行では、パーティーを開いて自分が買ったビールでは全員に十分ではないことがわかるようなものです。

場合によっては、「オンザフライ」SQL が最も安全な方法であり、データベースに何を入れるかを正確に制御できます。教訓は次のとおりです。次回は、0.5GB バンクで移行を次々と実行する前に、もっとよく考えてみます。