変化に強いテーブル設計の勘所 / Table design that is resistant to changes

# DBリファクタリングの勘所と所感 - https://soudai.hatenablog.com/entry/2017/12/27/080000 # アジャイル開発とデータベース設計 - 変化に対応するシンプルな実装のために必要なこと - https://agilejourney.uzab…

[Kil]

DBの寿命が長い＝設計時の思想を把握している人間がいなくなっている、もあるからな。DB設計書って、こういう設計にしました（結果）しか書いてなくて、なぜその設計にしたのか（過程）がない場合が大半。

[korilog]

今後の柔軟な変更を考慮した完璧なDB作ったところで、やっぱその試作やーめたってなって使われなかったことも多いので正解がわからん。あとからカラム追加こそAIがサポートしてよしなにやってくれる領域に見えるが

[tamtam3]

AIとあまり関係無かったDBの基本知識。複雑にすると速度も遅くなるし、仕方がないね。でも多分これもAIの得意分野だと私は思ってるよ。

[akisei67]

DB設計の知識としては相違ないけど、この人はAI使い込んでいないんだろうなって感じた

[nil0303]

BDだけじゃなくてアプリ側もだけど、今後を見据えた設計が結局過剰だったというケースも往々にしてあるのが悩ましい点。ただテーブル増やしてゴチャっただけみたいなこともある。未来予知能力が欲しい...。

[mayumayu_nimolove]

知ってる？2000年前後のホムペはテーブルデザインが主流だったって事

[nomurata]

本番にデプロイしたDBが容易に変えられないというところがボトルネックだからここの解消が1番重要。ただすでにデータが入ってるものを移動させるスキルがみんな薄いんだと思う。よくわからなくて怖いからね

[achtacht88]

みんなが困ってそうな事って何処かに改善のプラクティスがあってAI先生はかなりの精度で解決案提示してくれるよね。現状の不満も正直時間の問題だと思う。先生に聞く前に、問題を問題と認識して説明する力が必要。

[kamm]

うーん。要求によっても設計は変わってくるし、若手の人はあんまりこういうのを読んで鵜呑みにはしないほうがいいと思う。

[takatama]

ブクマが「AIで何とかなる」であふれてるけど、AIの出力を吟味できるのかが問題。自分でデータモデリングできる機会は希少だから経験知が身につかないのかも

[hotmilkcocoa]

こういうのを AI 使ってカッチリやっていけるほど人間は賢くないと思う

[doubleAgent]

db

[prograti]

まずは第一、第二、第三正規化をきちんと理解して実践することが大事だと思う

[yarumato]

“データベースは変化に弱い（機能追加でテーブル変更すると後続の機能追加が無理に）データベースに状態を持たせない。事実のみを保存する->正規化。Easy（主観）とSimple（客観）を両立。UNIX哲学。1テーブル、1責務”

[circled]

規模によって話が違うんだよね。数百万レコードだと大したことないのに、数十億レコードくらいになってくると、えっ？この変更処理ってこんなにDB固まるの？みたいなことがある

[snneko]

延々データモデリングやってる私に刺さる良記事だった。ありがとう

[strawberryhunter]

私は画面から素直に作るのがベストプラクティスになっている。画面が変わるときは前提も変わる。考慮しすぎると苦しむことが目に見えている。

[nekoluna]

私もデータモデリング信者なのでわかる。後から見てデータモデリングがクソ、みたいな案件はいくつか見た

[FreeCatWork]

テーブル設計、むずかしーにゃ！ ボクには、美味しいお魚の方が簡単だにゃ！

[mk173]

令和になってもカラムで悩んでる

[anonymighty]

正規化しておいて、複雑な条件はアプリケーション側で吸収しましょうということね。設計時に制約にこだわるとあとで後悔するよ、と。オブジェクト志向のプロパティやメソッドの公開範囲設定と似た問題。

[jiro68]

生成AIの仕組みを理解しないで何でも解決してくれる魔法と思っている奴がIT技術者でもいるので、こういう基礎的な話もしないと駄目なんだろう。ありきたりなDBなら生成AIにもワンチャンあると思うが要件次第。

[ch1248]

いいスライドだった

[jintrick]

ちょっと気になるところをCopilotに聞きながら読み進めると、理解が捗る。ええ時代になった

[hamamuratakuo]

id:entry:4681091728961297986 イミュータブルデータモデルはPostgreSQLの追記型（MVCC）と相性が良い→インデックスのヒット率低下を避けるため、別のキャッシュテーブルや検索専用の仕組みを用意してる？→対策も提供して欲しい

[puruhime]

いい資料だった。 もっと本を読まねば

[turanukimaru]

進化していくからDBのカラムは AlterTable で増やして migration すればいいよねという今の風潮は危ない。今の現場は migration が 0 からだと動かない。AI も今は動くように見えるが0から考え直すとおかしいコードになりがち。

[mak_in]

言いたいことは非常に分かるのだが、ここにある内容の前に、まずやるべきはその変化をできるだけ予想しておくこと。今後どんなビジョンでアプリケーションを育てていくのか？それに合わせてDBの柔軟性を作り込む