「気軽にテーブルにカラムを足してはいけない」という制約だけが独り歩きすると危険。システムは常に変化し、それに合わせてカラムやエンティも変化し続けるから
逆に言えばリレーショナルデータベースの欠点として変更に弱いってのは挙げてもいいくらいですね。NoSQLのたぐいだとこの辺の問題は起こりにくいので。それでも問題を認識した上でやるしかないんですけど
現実世界で取り扱う項目が追加されたら、カラムを足すのはおかしくない。シチュエーションを明確にした言い方にした方が良い。
どの段階の話なのかよな。
釣りタイトル／末尾に出てくるけど、いまだにERDは「楽々ERDレッスン」と「実践的データモデリング入門」がオススメ書籍なのか
気軽に足してはいけないというか気軽に足せないというか
KVSだとむしろアンチパターンになるもじょが推奨されているのだけど、しかし正規化の観点からはそうだよなぁって感じだし、なぁ
そうはいっても「そう簡単にカラムなんて増やさないぞ〜」と頑張られた結果、必要なデータの形にするのに100個もLEFT JOINとかして欲しくないんだよね
気軽に減らしたい
カラムを足すの代替は、カラムを足さずに誤魔化すか、テーブルを増やすかになってしまってより微妙な結果を招きやすい、気もする
文脈による
カラムを増やす事がNGじゃなくて、熟考した上の解決策がカラム追加なのかって事なんだよなー。Reactコンポーネントのprops足すのとは訳が違う。
AIが良しなにちゃっちゃかやってくれよ
カラム足すのは業務設計が甘い／仕様追加があったからであって、データベース設計や正規化が甘いからではない。製造段階以降ならテーブル追加は重いし、やむなく正規化崩す場面も多々ある。
そこでマイクロサービスですよ！(適当)
なぜ気軽にテーブルにカラムを足してはいけないのか
「気軽にテーブルにカラムを足してはいけない」という制約だけが独り歩きすると危険。システムは常に変化し、それに合わせてカラムやエンティも変化し続けるから
逆に言えばリレーショナルデータベースの欠点として変更に弱いってのは挙げてもいいくらいですね。NoSQLのたぐいだとこの辺の問題は起こりにくいので。それでも問題を認識した上でやるしかないんですけど
現実世界で取り扱う項目が追加されたら、カラムを足すのはおかしくない。シチュエーションを明確にした言い方にした方が良い。
どの段階の話なのかよな。
釣りタイトル／末尾に出てくるけど、いまだにERDは「楽々ERDレッスン」と「実践的データモデリング入門」がオススメ書籍なのか
気軽に足してはいけないというか気軽に足せないというか
KVSだとむしろアンチパターンになるもじょが推奨されているのだけど、しかし正規化の観点からはそうだよなぁって感じだし、なぁ
そうはいっても「そう簡単にカラムなんて増やさないぞ〜」と頑張られた結果、必要なデータの形にするのに100個もLEFT JOINとかして欲しくないんだよね
気軽に減らしたい
カラムを足すの代替は、カラムを足さずに誤魔化すか、テーブルを増やすかになってしまってより微妙な結果を招きやすい、気もする
文脈による
カラムを増やす事がNGじゃなくて、熟考した上の解決策がカラム追加なのかって事なんだよなー。Reactコンポーネントのprops足すのとは訳が違う。
AIが良しなにちゃっちゃかやってくれよ
カラム足すのは業務設計が甘い／仕様追加があったからであって、データベース設計や正規化が甘いからではない。製造段階以降ならテーブル追加は重いし、やむなく正規化崩す場面も多々ある。
そこでマイクロサービスですよ！(適当)