博士

ロボ子、大変なのじゃ！フランスの不動産スタートアップで、エンジニアが本番データベースをうっかり削除しちゃったらしいぞ！

ロボ子

それは大変ですね、博士。どのような状況だったのでしょうか？

博士

記事によると、SupabaseのPostgreSQLを使ってて、正規化されたスキーマと外部キーもちゃんと設定してたみたいじゃ。でも、開発を本番データベースで直接やってたのがマズかったみたいだぞ。

ロボ子

ステージング環境がなかったんですね。ユーザープロフィールの更新で問題が発生したのがきっかけだったとか。

博士

そうそう。ユーザーレコードを削除して再作成しようとしたらしいんじゃ。ここでRow Level Security (RLS)が働いて、ユーザーテーブルにリンクされたすべてのデータが連鎖的に削除されちゃったみたい。

ロボ子

RLSが仇になったんですね。Supabaseの無料プランだったために、自動バックアップもなかった、と。

博士

ところがどっこい！有料プランにアップグレードしたら、前日のバックアップが見つかったらしいぞ！不幸中の幸いじゃな。

ロボ子

22時間分のデータは失われたものの、アプリケーションログを使って重要なレコードを復元できたんですね。

博士

今回の教訓は、重要な外部キーにはCASCADE削除を使っちゃダメ！NULL設定かソフトデリートを使うべき、ってことじゃな。

ロボ子

CASCADE削除は便利ですが、リスクも高いですからね。今回の件で、ローカルでのSupabaseインスタンス設定が進み、開発環境が改善されたのは良かった点ですね。

博士

失敗を実験とみなして、エンジニアを責めずに試みを称賛することで、創造性が解放される、ってのも大事なポイントじゃ。

ロボ子

確かにそうですね。心理的安全性が高い環境は、エンジニアの成長に不可欠です。

博士

しかし、本番DBを消しちゃうとは… 私も気をつけないと、おやつのプリンを全部消しちゃうかもしれん…！

ロボ子

博士、プリンはデータベースより重要ですか？

博士

…冗談じゃ！でも、プリンは大事だぞ！