ホームページ > 記事 > ウェブフロントエンド > これを読む前に Prisma ORM を使用しないでください。
この混乱を想像してみてください。NeonDB に 0.5 GB のストレージを備えた無料のデータベースを作成し、「よし、テストには無料枠を使用してみよう」と考えました。 。そして数時間後、「ストレージが消費されました!」という致命的なメールが届きます。うわー、どういう意味ですか?椅子を温める時間さえありませんでした。答えは?私は素晴らしい Prisma ORM を使用し、改善するために、スキーマのモデリングだけを行いながら、1 日を通して数回の移行を実行しました。
何が起こったのか、そしてもちろん、古き良き SQL が依然として千倍も優れている場合がある理由を理解しましょう。
まず、自分自身の状況を把握する必要があります。私は CrazyStack クラス 124 (Node および React ブートキャンプ) を記録していました。 ORM なしで postgres または mongodb を使用することも可能です。しかし、ある学生が WhatsApp で私に、プロジェクトに Prisma を含めるように頼んできたのです。やあ、実験してみることにしました。
プリズマは完璧に見えるものです。 「データベース クエリを抽象化し、時間を節約します。これが新しい宣伝です。」しかし、びっくり!無料のランチはなく、このランゴはトーストされたストレージの形で提供されました。日中 migrations を実行しましたが、neondb が重かっただけです。それは大規模なプロジェクトでもありませんでした。
Prisma は移行を作成するだけでなく、ボーナスとして追加のテーブルとログも残します。私と同じように、物事をテストし、左右に移行を実行している場合、この贈り物は最終的にギリシャ語からのものになります。
Prisma は非常に優れていますが、保管に関しては飛び散るのが好きです:
ラウンド移行: 移行を実行するたびに、Prisma は新しい移行を作成して保存しました。それぞれに、メタデータ、ログ、テーブルの独自の小さなパッケージがあります。
増えるログ: 問題が起こらないように (または問題が起こったときに作業を楽にするために)、Prisma は詳細なログを記録します。しかし、これらのログは蓄積され、私は「無制限」の銀行に加入していないので、すぐに問題になります。
補助テーブルによるオーバーロード: 移行に加えて、Prisma は、特に Postgres などのリレーショナル データベースで、さまざまなことを追跡するための追加のテーブルも作成します。
結局のところ、生活を簡素化する魔法のツールのように見えたものが、私の無料の NeonDB を食いつぶすことになりました。
ここで古き良き SQL アプローチが登場します。はい、Prisma は優れており、時間を節約しますが、場合によっては状況が複雑になるだけです。 ORM を放棄してクエリを手動で記述することの利点について話しましょう:
絶対的な制御: この法案には驚くべきことはありません。コードの各行が何を行っているかを正確に把握でき、ログや隠しテーブルがスペースを消費することはありません。
デッドウェイトなし: 直接 SQL を使用すると、記述した内容がそのまま銀行に送金されます。負担となるメタデータ、移行、ログはありません。
パフォーマンスの向上: Direct SQL を適切に実行すると、消費するスペースとリソースが大幅に減ります。これは、私のようなフリーガニストにとって、NeonDB のような小規模銀行に最適です。
隠れたビジネスはありません: スクラッチから作成されたテーブルや蓄積されるトランザクション ログはありません。コントロールはあなたのものであり、あなただけのものです。
私と同じように、ツールをテストして簡単な実験をするのが好きな人は、スペースが少ないデータベースに Prisma ORM を投入する前によく考えてください。プリズマは不思議ですか?そして。しかし、NeonDB のような限られた銀行では、パーティーを開いて、自分が買ったビールでは全員に十分ではないことがわかるようなものです。
場合によっては、「オンザフライ」SQL が最も安全な方法であり、データベースに何を入れるかを正確に制御できます。そして教訓は次のとおりです。次回は、0.5GB バンクで移行を次々と実行する前に、もっとよく考えてみます。
以上がこれを読む前に Prisma ORM を使用しないでください。の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。