Database
ふにゃ
DBの作りが良いとアプリ開発が楽なんだけど、データは長寿命なのと日々機能追加要望は出てくるので長期的には汚くなる運命。なので何年か毎にDB内のデータのリファクタリングもした方が良いんだよね
LLMは難しいクエリも書いてくれるから助かる！！！！！！！でもテーブル設計の勘所をLLMに伝えるのは難しい！！！！！！！
「しばらく」があと5年くらいかもしれなくて、震えている。
データベーステーブル設計にAIを活用する方法について教えてください。データベースのドメイン（定義域）の定義や、将来の拡張を見据えたかたちでお願いします
プロデューサーが思いつきで機能を追加→やっぱりウケが悪くて数ヶ月後に戻す を繰り返してDBはどんどん汚くなる
AI時代もテーブル設計は大事にゃ！ボクがデータ整理しちゃうにゃ！🐾
そもそもUserじゃなくてMemberなんだけど「ユーザー」と呼びたがる、CompanyじゃなくてOrganizationなんだけど「会社」と呼びたがる、ただの表意コードなのに「ID」と呼びたがる問題への適切な対処法が知りたい…
テーブル設計の正規化、中長期的な目線、現実の汚さへの対応、単一責務、小さく作るなど
テーブルを細かく分ける正規化推しみたいだけど、JOINコストを避けるためにあえて正規化しない設計もあるからなぁ
プロジェクト設定をゴリゴリに書いて、AIが「よしemailのテーブルを分けよう」と判断して全自動で進められても、それはそれで怖くて嫌だ。プロジェクトのコードが1000行ぐらいしかなかったら任せられるけどね…。
面白かった。
DBのスキルで生き残る技術 - AI時代におけるテーブル設計の勘所
Database
ふにゃ
DBの作りが良いとアプリ開発が楽なんだけど、データは長寿命なのと日々機能追加要望は出てくるので長期的には汚くなる運命。なので何年か毎にDB内のデータのリファクタリングもした方が良いんだよね
LLMは難しいクエリも書いてくれるから助かる！！！！！！！でもテーブル設計の勘所をLLMに伝えるのは難しい！！！！！！！
「しばらく」があと5年くらいかもしれなくて、震えている。
データベーステーブル設計にAIを活用する方法について教えてください。データベースのドメイン（定義域）の定義や、将来の拡張を見据えたかたちでお願いします
プロデューサーが思いつきで機能を追加→やっぱりウケが悪くて数ヶ月後に戻す を繰り返してDBはどんどん汚くなる
AI時代もテーブル設計は大事にゃ！ボクがデータ整理しちゃうにゃ！🐾
そもそもUserじゃなくてMemberなんだけど「ユーザー」と呼びたがる、CompanyじゃなくてOrganizationなんだけど「会社」と呼びたがる、ただの表意コードなのに「ID」と呼びたがる問題への適切な対処法が知りたい…
テーブル設計の正規化、中長期的な目線、現実の汚さへの対応、単一責務、小さく作るなど
テーブルを細かく分ける正規化推しみたいだけど、JOINコストを避けるためにあえて正規化しない設計もあるからなぁ
プロジェクト設定をゴリゴリに書いて、AIが「よしemailのテーブルを分けよう」と判断して全自動で進められても、それはそれで怖くて嫌だ。プロジェクトのコードが1000行ぐらいしかなかったら任せられるけどね…。
面白かった。