論理削除

データベースから実際にデータを削除するのではなく、フラグを持たせて削除されているように見せること！

Linux

$：プロンプト
⬜︎：カーソル

Node.js と Nitro の「違い」や「役割の本質」

• Node.js：サーバー上で動くコードを実行するための「エンジン」
  →例）Node.js：app.listen(3000) で HTTP サーバー起動できる
• Nitro：Nuxt3専用のアプリ実行エンジンで、「ビルド・最適化・実行」を行ってくれる
  • SSRのロジック（HTML生成）を最適化
  • APIルーティングをサーバレス化
  • ビルド成果物をAWS Lambda / Node.js / Cloudflare Workers など向けに変換
  • 必要なルーティング構造、ミドルウェア、エントリポイントを生成

ミドルウェア

リクエストとレスポンスの間に入って、「共通の処理」をする関数や仕組みのこと！

具体的に、

• 認証：ログインしていない人を/loginにリダイレクトする
• ログ：誰がどこにアクセスしたかを記録する
• エラーハンドリング：エラーがでたら共通のエラーメッセージを返す

ブラウザには「実行エンジン」が最初から搭載されている

• ブラウザ 実行エンジン名
• Chrome V8
• Firefox SpiderMonkey
• Safari JavaScriptCore
• Edge (新) V8（Chromiumベース）

ORM

SQLを自分で書かなくても、通常のプログラミング言語のコード（関数や変数）でデータベース操作ができる！
→ そのコードをORMが裏でいい感じにSQLに変換して実行してくれる💡

例：Prismaでユーザー一覧を取得（TypeScript）

const users = await prisma.user.findMany()

裏では、こんなSQLに変換されてる

SELECT * FROM users;

•	SQL文を勉強する前から、データベースが扱える
•	ミスの少ない安全な書き方ができる（型付きなど）
•	大規模なプロジェクトでも再利用しやすい

⚠️ ORMの限界・注意点

① 複雑なクエリに弱い
• 複雑なJOIN、ネスト、サブクエリなどは ORMの記述が逆に分かりづらくなったり
• ORMで表現できないSQLもある（特に最適化された特殊なクエリ）

→ そんなときは「生のSQL（Raw SQL）」を書くしかない。
⸻

② パフォーマンスの落とし穴
• ORMは「よしなにやってくれる」ぶん、不要に重たいSQLが生成されることもある
• 例：ループ内でDB呼び出し → N+1問題（1つずつSQLを投げてしまう）

⸻

③ 抽象化ゆえのブラックボックス化
• SQLを知らないと「なぜこの処理が遅いのか」「何をやっているのか」が見えにくくなる
• ORMに頼りすぎると、DB設計や最適化の力がつかないリスク

⸻

④ ORMが隠している仕様に依存しすぎると移行が大変
• 他のDBへの移行が大変になることも（例：MySQL→PostgreSQL）
• ORMがマイナーアップデートで仕様変更 → 予期せぬバグ