言いたいことは非常に分かるのだが、ここにある内容の前に、まずやるべきはその変化をできるだけ予想しておくこと。今後どんなビジョンでアプリケーションを育てていくのか？それに合わせてDBの柔軟性を作り込む
進化していくからDBのカラムは AlterTable で増やして migration すればいいよねという今の風潮は危ない。今の現場は migration が 0 からだと動かない。AI も今は動くように見えるが0から考え直すとおかしいコードになりがち。
今後の柔軟な変更を考慮した完璧なDB作ったところで、やっぱその試作やーめたってなって使われなかったことも多いので正解がわからん。あとからカラム追加こそAIがサポートしてよしなにやってくれる領域に見えるが
いい資料だった。 もっと本を読まねば
うーん。要求によっても設計は変わってくるし、若手の人はあんまりこういうのを読んで鵜呑みにはしないほうがいいと思う。
id:entry:4681091728961297986 イミュータブルデータモデルはPostgreSQLの追記型（MVCC）と相性が良い→インデックスのヒット率低下を避けるため、別のキャッシュテーブルや検索専用の仕組みを用意してる？→対策も提供して欲しい
ちょっと気になるところをCopilotに聞きながら読み進めると、理解が捗る。ええ時代になった
知ってる？2000年前後のホムペはテーブルデザインが主流だったって事
AIとあまり関係無かったDBの基本知識。複雑にすると速度も遅くなるし、仕方がないね。でも多分これもAIの得意分野だと私は思ってるよ。
DBの寿命が長い＝設計時の思想を把握している人間がいなくなっている、もあるからな。DB設計書って、こういう設計にしました（結果）しか書いてなくて、なぜその設計にしたのか（過程）がない場合が大半。
いいスライドだった
DB設計の知識としては相違ないけど、この人はAI使い込んでいないんだろうなって感じた
生成AIの仕組みを理解しないで何でも解決してくれる魔法と思っている奴がIT技術者でもいるので、こういう基礎的な話もしないと駄目なんだろう。ありきたりなDBなら生成AIにもワンチャンあると思うが要件次第。
BDだけじゃなくてアプリ側もだけど、今後を見据えた設計が結局過剰だったというケースも往々にしてあるのが悩ましい点。ただテーブル増やしてゴチャっただけみたいなこともある。未来予知能力が欲しい...。
正規化しておいて、複雑な条件はアプリケーション側で吸収しましょうということね。設計時に制約にこだわるとあとで後悔するよ、と。オブジェクト志向のプロパティやメソッドの公開範囲設定と似た問題。
みんなが困ってそうな事って何処かに改善のプラクティスがあってAI先生はかなりの精度で解決案提示してくれるよね。現状の不満も正直時間の問題だと思う。先生に聞く前に、問題を問題と認識して説明する力が必要。
令和になってもカラムで悩んでる
テーブル設計、むずかしーにゃ！ ボクには、美味しいお魚の方が簡単だにゃ！
私もデータモデリング信者なのでわかる。後から見てデータモデリングがクソ、みたいな案件はいくつか見た
私は画面から素直に作るのがベストプラクティスになっている。画面が変わるときは前提も変わる。考慮しすぎると苦しむことが目に見えている。
DBリファクタリングを知らなかった
本番にデプロイしたDBが容易に変えられないというところがボトルネックだからここの解消が1番重要。ただすでにデータが入ってるものを移動させるスキルがみんな薄いんだと思う。よくわからなくて怖いからね
https://www.utgop.org/jaduu
延々データモデリングやってる私に刺さる良記事だった。ありがとう
規模によって話が違うんだよね。数百万レコードだと大したことないのに、数十億レコードくらいになってくると、えっ？この変更処理ってこんなにDB固まるの？みたいなことがある
“データベースは変化に弱い（機能追加でテーブル変更すると後続の機能追加が無理に）データベースに状態を持たせない。事実のみを保存する->正規化。Easy（主観）とSimple（客観）を両立。UNIX哲学。1テーブル、1責務”
まずは第一、第二、第三正規化をきちんと理解して実践することが大事だと思う
db
ブクマが「AIで何とかなる」であふれてるけど、AIの出力を吟味できるのかが問題。自分でデータモデリングできる機会は希少だから経験知が身につかないのかも
こういうのを AI 使ってカッチリやっていけるほど人間は賢くないと思う
変化に強いテーブル設計の勘所 / Table design that is resistant to changes
言いたいことは非常に分かるのだが、ここにある内容の前に、まずやるべきはその変化をできるだけ予想しておくこと。今後どんなビジョンでアプリケーションを育てていくのか？それに合わせてDBの柔軟性を作り込む
進化していくからDBのカラムは AlterTable で増やして migration すればいいよねという今の風潮は危ない。今の現場は migration が 0 からだと動かない。AI も今は動くように見えるが0から考え直すとおかしいコードになりがち。
今後の柔軟な変更を考慮した完璧なDB作ったところで、やっぱその試作やーめたってなって使われなかったことも多いので正解がわからん。あとからカラム追加こそAIがサポートしてよしなにやってくれる領域に見えるが
いい資料だった。 もっと本を読まねば
うーん。要求によっても設計は変わってくるし、若手の人はあんまりこういうのを読んで鵜呑みにはしないほうがいいと思う。
id:entry:4681091728961297986 イミュータブルデータモデルはPostgreSQLの追記型（MVCC）と相性が良い→インデックスのヒット率低下を避けるため、別のキャッシュテーブルや検索専用の仕組みを用意してる？→対策も提供して欲しい
ちょっと気になるところをCopilotに聞きながら読み進めると、理解が捗る。ええ時代になった
知ってる？2000年前後のホムペはテーブルデザインが主流だったって事
AIとあまり関係無かったDBの基本知識。複雑にすると速度も遅くなるし、仕方がないね。でも多分これもAIの得意分野だと私は思ってるよ。
DBの寿命が長い＝設計時の思想を把握している人間がいなくなっている、もあるからな。DB設計書って、こういう設計にしました（結果）しか書いてなくて、なぜその設計にしたのか（過程）がない場合が大半。
いいスライドだった
DB設計の知識としては相違ないけど、この人はAI使い込んでいないんだろうなって感じた
生成AIの仕組みを理解しないで何でも解決してくれる魔法と思っている奴がIT技術者でもいるので、こういう基礎的な話もしないと駄目なんだろう。ありきたりなDBなら生成AIにもワンチャンあると思うが要件次第。
BDだけじゃなくてアプリ側もだけど、今後を見据えた設計が結局過剰だったというケースも往々にしてあるのが悩ましい点。ただテーブル増やしてゴチャっただけみたいなこともある。未来予知能力が欲しい...。
正規化しておいて、複雑な条件はアプリケーション側で吸収しましょうということね。設計時に制約にこだわるとあとで後悔するよ、と。オブジェクト志向のプロパティやメソッドの公開範囲設定と似た問題。
みんなが困ってそうな事って何処かに改善のプラクティスがあってAI先生はかなりの精度で解決案提示してくれるよね。現状の不満も正直時間の問題だと思う。先生に聞く前に、問題を問題と認識して説明する力が必要。
令和になってもカラムで悩んでる
テーブル設計、むずかしーにゃ！ ボクには、美味しいお魚の方が簡単だにゃ！
私もデータモデリング信者なのでわかる。後から見てデータモデリングがクソ、みたいな案件はいくつか見た
私は画面から素直に作るのがベストプラクティスになっている。画面が変わるときは前提も変わる。考慮しすぎると苦しむことが目に見えている。
DBリファクタリングを知らなかった
本番にデプロイしたDBが容易に変えられないというところがボトルネックだからここの解消が1番重要。ただすでにデータが入ってるものを移動させるスキルがみんな薄いんだと思う。よくわからなくて怖いからね
https://www.utgop.org/jaduu
延々データモデリングやってる私に刺さる良記事だった。ありがとう
規模によって話が違うんだよね。数百万レコードだと大したことないのに、数十億レコードくらいになってくると、えっ？この変更処理ってこんなにDB固まるの？みたいなことがある
“データベースは変化に弱い（機能追加でテーブル変更すると後続の機能追加が無理に）データベースに状態を持たせない。事実のみを保存する->正規化。Easy（主観）とSimple（客観）を両立。UNIX哲学。1テーブル、1責務”
まずは第一、第二、第三正規化をきちんと理解して実践することが大事だと思う
db
ブクマが「AIで何とかなる」であふれてるけど、AIの出力を吟味できるのかが問題。自分でデータモデリングできる機会は希少だから経験知が身につかないのかも
こういうのを AI 使ってカッチリやっていけるほど人間は賢くないと思う