[フレーム]
はてなブックマークアプリ

サクサク読めて、
アプリ限定の機能も多数!

アプリで開く

気に入った記事をブックマーク

  • 気に入った記事を保存できます
    保存した記事の一覧は、はてなブックマークで確認・編集ができます
  • 記事を読んだ感想やメモを書き残せます
  • 非公開でブックマークすることもできます
適切な情報に変更

エントリーの編集

loading...

エントリーの編集は全ユーザーに共通の機能です。
必ずガイドラインを一読の上ご利用ください。

タイトルガイドライン

このページのオーナーなので以下のアクションを実行できます

タイトル、本文などの情報を
再取得することができます
コメントを非表示にできます コメント表示の設定

ブックマークしました

ここにツイート内容が記載されます https://b.hatena.ne.jp/URLはspanで囲んでください

Twitterで共有

ONにすると、次回以降このダイアログを飛ばしてTwitterに遷移します

179users がブックマーク コメント 26

ガイドラインをご確認の上、良識あるコメントにご協力ください

0 / 0
入力したタグを追加

現在プライベートモードです 設定を変更する

おすすめタグタグについて

よく使うタグ

なぜ気軽にテーブルにカラムを足してはいけないのか

179 users zenn.dev/mj2mkt

ガイドラインをご確認の上、良識あるコメントにご協力ください

0 / 0
入力したタグを追加

現在プライベートモードです 設定を変更する

おすすめタグタグについて

よく使うタグ

はてなブックマーク

はてなブックマークで
関心をシェアしよう

みんなの興味と感想が集まることで
新しい発見や、深堀りがもっと楽しく

ユーザー登録

アカウントをお持ちの方はログインページ

記事へのコメント26

  • 注目コメント
  • 新着コメント
paradoxparanoic
「気軽にテーブルにカラムを足してはいけない」という制約だけが独り歩きすると危険。システムは常に変化し、それに合わせてカラムやエンティも変化し続けるから

その他
circled
そうはいっても「そう簡単にカラムなんて増やさないぞ〜」と頑張られた結果、必要なデータの形にするのに100個もLEFT JOINとかして欲しくないんだよね

その他
secseek
逆に言えばリレーショナルデータベースの欠点として変更に弱いってのは挙げてもいいくらいですね。NoSQLのたぐいだとこの辺の問題は起こりにくいので。それでも問題を認識した上でやるしかないんですけど

その他
daaaaaai
カラムを足す行為の代替は、カラムを足さずに誤魔化すか、テーブルを増やすかになってしまってより微妙な結果を招きやすい気もする

その他
roshi
カラムを増やす事がNGじゃなくて、熟考した上の解決策がカラム追加なのかって事なんだよなー。Reactコンポーネントのprops足すのとは訳が違う。

その他
soxandcity
この思考は硬直化を招きかねない。 DBもコードも作った瞬間から陳腐化していくので、時間のかかる変更でも必要であれば実施できる環境の方が大事だと思う。

その他
ka-ka_xyz
設計の件、要件は変化するものなので"生きている"システムならカラム足すこともあるじゃろ感。コストと言えば大昔のMySQLは裏でテーブルフルコピーしてて、本番環境のカラム追加に5日ぐらいかかった苦い思い出が。

その他
lainof
現実世界で取り扱う項目が追加されたら、カラムを足すのはおかしくない(戸籍のシステムにふりがなが追加されたらカラムを足す)。シチュエーションを明確にした言い方にした方が良い。

その他
hatest
じゃあ気軽にテーブル増やせばいいかというとパフォーマンスの問題があるのでそうでもない。銀の弾丸などない

その他
cinq_na
カラム足すのは業務設計が甘い/仕様追加があったからであって、データベース設計や正規化が甘いからではない。製造段階以降ならテーブル追加は重いし、やむなく正規化崩す場面も多々ある。

その他
sigesaba
"一般的に、カラムが少ないほどインデックス設計は楽です。逆にカラム数が増えるほど、設計は難しいものになりやすいです。"

その他
sucelie
正規化を突き詰めた結果、1テーブル1フィールド(+ID)に切り出したアホを聞いたことがある

その他
PrivateIntMain
足すなとは言ってなくて、足すなら熟慮と検証の末に足そうねとの話。熟慮と検証がやってられん仕組みはカラムを足すまいが破綻している。

その他
YaSuYuKi
データベース変更を気軽に行うと長期間経って深刻な問題になる、ということで、カラムでもテーブルでも不用意に追加するのではなくちゃんと分析して的確な方法を選ぶ必要がある

その他
hatest
hatest じゃあ気軽にテーブル増やせばいいかというとパフォーマンスの問題があるのでそうでもない。銀の弾丸などない

2025年10月15日 リンク

その他
tasukuchan
"アトリビュート"

その他
ka-ka_xyz
ka-ka_xyz 設計の件、要件は変化するものなので"生きている"システムならカラム足すこともあるじゃろ感。コストと言えば大昔のMySQLは裏でテーブルフルコピーしてて、本番環境のカラム追加に5日ぐらいかかった苦い思い出が。

2025年10月15日 リンク

その他
soulfulmiddleagedman
勉強になる

その他
soxandcity
soxandcity この思考は硬直化を招きかねない。 DBもコードも作った瞬間から陳腐化していくので、時間のかかる変更でも必要であれば実施できる環境の方が大事だと思う。

2025年10月15日 リンク

その他
hasiduki
日々更新されるドメインモデルを表現できるように!!!!!!DBスキーマは更新されるのだ!!!!!!

その他
taruhachi
気軽にテーブル追加を繰り返すパターンとの比較がないのでほぼ無意味にも思える。

その他
juejue
そこでマイクロサービスですよ!(適当)

その他
cinq_na
cinq_na カラム足すのは業務設計が甘い/仕様追加があったからであって、データベース設計や正規化が甘いからではない。製造段階以降ならテーブル追加は重いし、やむなく正規化崩す場面も多々ある。

2025年10月15日 リンク

その他
hhungry
AIが良しなにちゃっちゃかやってくれよ

その他
roshi
roshi カラムを増やす事がNGじゃなくて、熟考した上の解決策がカラム追加なのかって事なんだよなー。Reactコンポーネントのprops足すのとは訳が違う。

2025年10月15日 リンク

その他
chamind
文脈による

その他
daaaaaai
daaaaaai カラムを足す行為の代替は、カラムを足さずに誤魔化すか、テーブルを増やすかになってしまってより微妙な結果を招きやすい気もする

2025年10月14日 リンク

その他
cl-gaku
気軽に減らしたい

その他
circled
circled そうはいっても「そう簡単にカラムなんて増やさないぞ〜」と頑張られた結果、必要なデータの形にするのに100個もLEFT JOINとかして欲しくないんだよね

2025年10月14日 リンク

その他
quabbin
KVSだとむしろアンチパターンになるもじょが推奨されているのだけど、しかし正規化の観点からはそうだよなぁって感じだし、なぁ

その他
daichirata
気軽に足してはいけないというか気軽に足せないというか

その他
chikurou
釣りタイトル/末尾に出てくるけど、いまだにERDは「楽々ERDレッスン」と「実践的データモデリング入門」がオススメ書籍なのか

その他
buriburiuntitti
どの段階の話なのかよな。

その他
lainof
lainof 現実世界で取り扱う項目が追加されたら、カラムを足すのはおかしくない(戸籍のシステムにふりがなが追加されたらカラムを足す)。シチュエーションを明確にした言い方にした方が良い。

2025年10月14日 リンク

その他
secseek
secseek 逆に言えばリレーショナルデータベースの欠点として変更に弱いってのは挙げてもいいくらいですね。NoSQLのたぐいだとこの辺の問題は起こりにくいので。それでも問題を認識した上でやるしかないんですけど

2025年10月14日 リンク

その他
paradoxparanoic
paradoxparanoic 「気軽にテーブルにカラムを足してはいけない」という制約だけが独り歩きすると危険。システムは常に変化し、それに合わせてカラムやエンティも変化し続けるから

2025年10月14日 リンク

その他

注目コメント算出アルゴリズムの一部にLINEヤフー株式会社の「建設的コメント順位付けモデルAPI」を使用しています

リンクを埋め込む

以下のコードをコピーしてサイトに埋め込むことができます

プレビュー
アプリのスクリーンショット
いまの話題をアプリでチェック!
  • バナー広告なし
  • ミュート機能あり
  • ダークモード搭載
アプリをダウンロード

関連記事

usersに達しました!

さんが1番目にブックマークした記事「なぜ気軽にテーブ...」が注目されています。

気持ちをシェアしよう

ツイートする

なぜ気軽にテーブルにカラムを足してはいけないのか

この設計は、注文エンティティと発送エンティティの一部が混在してしまっている状態です。発送エンティ... この設計は、注文エンティティと発送エンティティの一部が混在してしまっている状態です。発送エンティティが混在しているのであとから発送に関する情報をもっと入れたいとなったときに、ここに追加し続けてしまうことになるでしょう。この場合も発送は別のテーブルとして切り出すのが適切です。 よくある失敗パターンとしては安直に日時(xxx_at / xxx_on)やフラグ(xxx_flag)やステータス(xxx_status)のカラムを追加することです。これらを追加したくなったときには他のエンティティではないかと疑いましょう。 変更のコストが大きい アプリケーションのリファクタリングと比べて、データベースのリファクタリングはコスト(時間・工数・リスク)が大きいです。影響範囲がどの程度あるか、既存データがどの程度あるか、ダウンタイムがどの程度許容されるか、などを考慮する必要があります。データベースのリファクタ

ブックマークしたユーザー

  • Xibalba2025年10月20日 Xibalba
  • tech04032025年10月17日 tech0403
  • sigesaba2025年10月16日 sigesaba
  • knj29182025年10月16日 knj2918
  • skypenguins2025年10月16日 skypenguins
  • kattsuk22025年10月16日 kattsuk2
  • caramelcoffee2025年10月16日 caramelcoffee
  • klim08242025年10月16日 klim0824
  • kamada-math2025年10月16日 kamada-math
  • rudo1082025年10月16日 rudo108
  • xmobile2025年10月15日 xmobile
  • maple_magician2025年10月15日 maple_magician
  • imyutaro2025年10月15日 imyutaro
  • harxki2025年10月15日 harxki
  • yug12242025年10月15日 yug1224
  • dev0000_12025年10月15日 dev0000_1
  • chopwave2025年10月15日 chopwave
  • midas365452025年10月15日 midas36545
すべてのユーザーの
詳細を表示します

ブックマークしたすべてのユーザー

同じサイトの新着

同じサイトの新着をもっと読む

いま人気の記事

いま人気の記事をもっと読む

いま人気の記事 - テクノロジー

いま人気の記事 - テクノロジーをもっと読む

新着記事 - テクノロジー

新着記事 - テクノロジーをもっと読む

同時期にブックマークされた記事

いま人気の記事 - 企業メディア

企業メディアをもっと読む

はてなブックマーク

公式Twitter

はてなのサービス

Copyright © 2005-2025 Hatena. All Rights Reserved.
設定を変更しましたx

AltStyle によって変換されたページ (->オリジナル) /