  |
お前の反論、自分が引き算の美学で事業コストを語れてると勘違いしてるパターン。
でも実態は、事業規模に対する思考スコープの狭さがにじみ出てる。
まず最初に、
それ、論点でもロジックでもなくて、ただの願望自己放尿。中身が一切ない。
これは一見合理的に見えるが、実際は「過剰な単純化」の自己放尿にハマってる。
言ってるのはただ1つ。「JOINを安易に使うな。構造が持つリスクには最初から備えろ」。
将来のトラブルを「避けられる形にしておく」ってだけの話。
たとえば、JOIN構造を避けて辞書キャッシュを設けるのは、初期では数行のコード差。その数行で未来の地獄が避けられるなら、やる価値はある。
JOINを使った全クエリの洗い出し、クエリの再設計、DBインデックス再構成、アプリコードの再配備、キャッシュ整備、パフォーマンステスト、ロールバック対応。
事業全体の工数で見たら、圧倒的に最初に避けとくほうが安いんだよ。
それが見えてない時点で、「事業全体のコスト」とか語らないほうがいい。
言ってることが逆。
しかもね、「事業の初期だから雑でもいい」って、それ本気で言ってるならプロダクトの成功を前提にしてないってこと。
リクエスト数が伸びたら死ぬ設計でリリースして、「伸びたらそのとき直せばいいでしょ」とか言うやつに限って、死んでる間に顧客も信用も消えてる。
初期だからこそ、「伸びたときに対応できる構造」は最低限持たせる。
「JOINは便利だが地雷になりやすい」というのは経験則に基づいた設計判断。
「初期はシンプルに」というのは同意だが、それは未来を無視していいという免罪符じゃない。
「将来の死を回避する設計」＝「複雑化」ではなく、保険と投資。
事業全体のコストを考えるなら、障害で燃える運用コスト・再開発工数も含めろ。
巨大なテーブルを扱っているというのが誤解です 今後巨大なテーブルになるというのも誤解です 本当に巨大なら手元に辞書作るのも無理なので問題ありません
「巨大なテーブルじゃない」「今後も巨大にならない」「だから辞書じゃなくてJOINでも問題ない」 全部甘い。現場知らないヤツの脳内放尿だな。 まず、もしテーブルが小さいならそ...
JOINの動きが分かりづらいから自分がわかるエンジニアリングに逃げてるだけなのでは
あー、なるほどね。「JOINが難しくて避けてるだけなんじゃね？」ってわけか。 甘い。構造わかってない奴ほどそういう浅い自己放尿をしたがる。 まず前提を修正しろ。JOINの動きなんて...
DBにはこだわりは有るようだが、事業全体のコストとかは見えてないエンジニアなんだろうなと。 まあ、少数のシステムしか経験のない飼い殺しエンジニアみたいな感じだろうが。 事業...
お前の反論、自分が引き算の美学で事業コストを語れてると勘違いしてるパターン。 でも実態は、事業規模に対する思考スコープの狭さがにじみ出てる。 まず最初に、 「事業全体の...
あなたの不安が大きいのはわかりましたが、現実としてデータは大きくならないし、joinは破綻しません 思い込みで無駄に複雑にするのが一番よくありません まずはシンプルにコードを...
そうよね リリース前に負荷試験で危ないクエリ洗い出しておけば安心してリリース迎えられるのに 後でデータが巨大になって死ぬって話を繰り返してて 負荷試験やらない素人がでかい...
あー、出た出た。「負荷試験で全部検出できる」っていう過信系エンジニアの典型的自己放尿ね。 それっぽい口ぶりしてるけど、中身はかなり雑。 「リリース前に負荷試験で危ないク...
「負荷試験で現実からかけ離れた雑なデータしか作れない素人です」って札を首から下げて生きた方がいいよ RDB扱ってるのにマトモな負荷試験やったことない奴って本当に多いよね
「負荷試験で現実からかけ離れた雑なデータしか作れない素人です」 それ、お前の妄想上の素人に向かって自己放尿してるだけで、俺の話には一切当たらない。 こっちは負荷試験その...
あー、それ完全に自己放尿のマジックワード連打だな。「現実として〜」「破綻しません」「シンプルにしましょう」中身ゼロ。 こっちが挙げた定量的リスク（件数増加、I/O負荷、JOINの...
17