ロギングの部分はその通りだね。「ああ、これをログに残しておけばよかった」と思うことが何度もあったし、問題やインシデントに直面したときに結局ログを導入することになる。

そうそう。みんな少しの時間を使ってロギングやメトリクスを整備すべきだよ。テストみたいなもので、0から1のテストを作るのは心理的に難しいけど、1から1000になると「これなしでどうやって生きてたんだろう」ってなる。Grafanaにはそこそこ使える無料プランがあるし、自分でホスティングすることもできるよ。

その発言をそのまま受け取ると、基本的にデータベースにブール値を保存するのは悪臭だと言えるね。彼の言う通りだと思う。ただ、これが広く良い原則かどうかは疑問だし、on_atの場合でもそう。もしこういうことを気にするなら、適切に監査テーブルに保存すべきだよ。ブール値をタイムスタンプに切り替えるのは、実際にはあまり役に立たない奇妙な怠け者のハックだと思う。なぜなら、そんな風に追跡されるのはランダムなデータのサブセットだけだから。ブールデータ型が更新時間を追跡するのに重要かどうかを決める要因ではないし。これが提案される主な理由は、たぶん「無料」だからだと思う。ブール値にタイムスタンプを忍ばせることができるし、偶然にいくらかの手間を省いたんだろうけど、解決しようとしている問題のセットに対する完全な解決策ではないと思う。ソフトデリートにも同じ疑念を抱いている。実際には役に立たないと確信しているし、適切な監査を避けるための精神的に怠惰な解決策に過ぎない。確実に「元に戻す」ことはできないし、更新履歴を解決するわけでもないから、実際に守っているのは偶発的な一括削除を即座にキャッチすることだけ？それがバックアップの半分の目的だよね。

その状況では、Bearと他のカテゴリを含むenum値を持つことができると思うよ。

でも、なぜブール値を特別扱いして、これを持たない整数に対してタイムスタンプを保持するの？: isDarkTheme: {timestamped} paginationItems: 50 ダークテーマがいつ有効になったかはわかるけど、ページネーションが50に設定されたのはわからないし、ダークテーマが無効になった時もわからない。貧乏人の変更履歴みたいだ。使い道はあるかもしれないけど、正直言って思いつかないな。

こういう一般的なアドバイスは全然役に立たないし、何百万ものアスタリスクが必要だよ。良いシステム設計は、目の前の問題に最適なシステムを設計することなんだ。

ほとんどのケースでブール値は悪いものだと思う。ブール値の代わりにタイムスタンプや整数フィールド（後で拡張可能）を使うべきだ。is_aの場合、ほとんど常にタイプや種類の方が良い。たとえ最初はクマだけでも、クマだけの状態はあまりないし、ステータスフィールドも（オンかオフだけではなく）通常はサスペンド、削除、スリープなどに広がるからね。だから、一般的にはブール値は避けるべきだと思う。相互排他的な状態（ライブ、削除、サスペンドなど）をカバーする時に、ブール値は増殖して複雑さを増すことが多いから。is_visible、is_deleted、is_suspendedが同じテーブルにあって（ステータスなしで）、その結果のコードやクエリは見栄えが良くない。代わりにタイムスタンプではなく整数を使うべきだと思う。

ブール値はサイズが小さいから、特定のワークロードには重要な考慮事項だよ。例えば、関連するタイムスタンプを気にしない分析クエリのセットに対して、大量のデータを事前に集計している場合がある。その場合、小さいデータ型の方がストレージとクエリ実行の両方で効率的なんだ。さらに、ブール値を保存するのが論理的な状況もあるよ。例えば、ブール値が結果を示す場合：process_executed_at タイムスタンプは null でない、process_succeeded ブール値は null でない。

ビューは、チェックインできるときには理にかなっているよ。DBマイグレーションはその不変性のために良い方法ではないし。コードベースが採用するエコシステムによっては、良いORMを使ってJOINする方が良い選択かもしれないね。

俺はここに正反対のことを言いに来たんだ。重いJOINがうまくいかないことが何回かあったけど、何を試してもダメだった。だから、goroutinesを使ってデータを読み込んだり結合したりする方が早かったんだ。結局、そのやり方を選んだよ。SQLは簡単だけど、インデックスやプランナーのことを理解するのは難しいよね。

このルールを最初の目安として持つのはいいと思うけど、デザインルールは破るタイミングを理解しておくべきだよね。たくさんのテーブルをJOINするアプリケーションに関わったことがあるけど、数十件のレコードが何千件にも膨れ上がって、結果に大きな冗長性が出てしまった。例えば、ある概念的な結果が、テーブル1からA、B、C、テーブル2からX、Y、テーブル3から1、2、3を持っているとする。結果として8行（メインテーブルのトップレベルを含めると9行）ではなく、18行（AX1、AX2、AX3、AY1…）になっちゃう。テーブルが増えると指数関数的に悪化するんだ。そこで、異なるテーブルごとに別のクエリを使うことにしたんだ。重要なのは、同じ条件でフィルタリングできたから、トップレベルの結果がたくさんあるときに子テーブルに対して複数のクエリを作る必要がなかったこと。結果的に、ネットワークのオーバーヘッドがクエリ処理と返されるデータ量の節約に隠れて、ずっと速くなった。アプリケーションコードも実際にはシンプルになったし、大きなJOINからユニークな子結果を選ぶのは面倒だったからね。全ての面でメリットしかなかった。後で、全てのデータを一つのテーブルのJSONBに詰め込んだんだけど、それもさらに良かった。でも、それも古い正規化ルールを破る一例だね。

これがORMが問題になる大きな要因だよね。SSRのアレンジメントでMVCビューごとに生のSQLビューやクエリを書くのは、複雑なウェブプロダクトを構築するための最もエレガントでパフォーマンスの良い方法の一つなんだ。RDBMSにデータの重い処理を任せよう。古いエンタープライズ系のMSSQLやOracleを使っていると、最適化がたくさんあって思い出せないこともある。ウェブサーバーは、各行ごとにラウンドトリップしたり、追加のメモリ内結合操作を行うことなく、SQLの結果セットを対応する要素に直接補完できるべきなんだ。典型的なORMの実装はこれとは真逆で、どこでも使わなきゃいけない厳格なオブジェクトモデルになってる。これ以上柔軟性がないってくらいだね。

「データベースでやる」っていうのにどれだけ頼るかには注意が必要だよ。そうしないと、アプリケーションが一つの値を挿入して、全然違う形で保存されるなんてことになりかねないから。

それには同意できないな。現代のスケーラブルなアーキテクチャでは、データベースの前の層（バックエンド）でジョインを行う方がいいと思う。バックエンドはデータベースよりもスケールしやすいからね。シンプルなインデックス（例えば、user_id）でデータを読み込んでバックエンドでジョインすることで、DBを速く保てる。バックエンドのインスタンスを追加するのは簡単だけど、DBインスタンスはそうはいかないから。もし、データが大きすぎてバックエンドのメモリに読み込めないからDBでジョインしなきゃならないと思ってるなら、構造を見直してみて。フロントエンドにジョインを移動させると、データがキャッシュしやすくなって、読み込みも速くなるし、サーバー側のリソースも解放されるよ。

本当にそう思ってるの？例えば、ウェブショップを運営していて、1つは5フィールドの注文テーブル、もう1つは20フィールドの顧客テーブルがあるとしよう。顧客が1万、注文が100万あると仮定して、これらをフルジョインして全データを取得するクエリだと、2500万フィールドが送信されることになる。一方で、2つの別々のクエリとクライアント側での手動ジョインだと、注文は500万、顧客は20万で済むよ。

ストアドプロシージャは良さそうに見えるけど、大きな問題は、残りのソフトウェアをRustみたいな素晴らしいモダンな言語で書けるのに、ストアドプロシージャを書くときはTransact-SQLで書かなきゃいけないことだよ。これが唯一の選択肢だからね。T-SQLは、ぼんやりと現役だった時代には良いプログラミング言語ではなかったし、だから大規模なコードをT-SQLで書きたくないんだ。私の罪として、巨大なT-SQLプロシージャを持つソフトウェアを維持しているけど（本当にこの手のものが好きな人による多ページの elaboration）、それは悪夢だよ。ツールはバージョン管理を信じていないし、間違いを犯したときの診断は存在しないか、C++スタイルの役に立たないゴミ情報だ。私たちは非常に若い開発者をたくさん雇っている。リリース時にコードをコメントアウトしないように言われる必要がある人たちで、変数の数字は人間が読むためのもので、機械のためではない、みたいなことを教えなきゃいけない。物理学者を雇ってソフトウェアを書くわけではないけど（スタートアップでやったことはある）、それに近いね。でも、新しく雇った人のマージリクエストで見る「私の初めてのプログラム」コードは、すでに持っているT-SQLよりも読みづらくはないよ。

一番大事な質問は、結局どれくらい高いのか、どれくらいの頻度でやらなきゃいけないのか、そしてそのスピードがどれくらい重要なのかってことだと思う。もし、毎回のページロードで複雑なクエリがあって、ユーザーがめっちゃ多いなら、できるだけDBに入れた方がいいよ。もし、たくさんのレコードを繰り返し処理して、いくつかの値の組み合わせに基づいて何かをする必要があるなら、週次報告用のやつだったら、複雑なSQL文を2日かけて作るよりも、早めに抜けられる3重のforeachループの方が全然いいと思う。

だけど、コンテナで動いているステートレスアプリケーションで、そんなに多くのことを間違えることはないよ。 > 悪いマイグレーションや悪いデータベースコードでデータセットを壊さない限り、このレベルでのほとんどの悪いことは、数分でいくつかの再デプロイで修正できるよ。これらの発言の間で、ステートレスからステートフルに切り替わったみたいだけど、その後の議論がついていけないな。

ビル・カーワインの「SQL Antipatterns」っていう素晴らしい本があって、そこでこの特定のアンチパターンについて議論されてるんだよね。とはいえ、ざっくりとしたスキーマ（例えば、フロントエンドに返す設定オブジェクトみたいな）すら思いつかないときは、PostgresのJSONBカラムを使うこともあるよ。ただ、基本的には、何かを正規化できるなら、すべきだと思う。結局、PostgresにはJSON(B)の便利さや最適化があっても、まだリレーショナルデータベースなんだから。

監査データを同じDBに保存して、それに対して機能が書かれてしまうと、監査データがビジネスロジックの一部になってしまう。 これを「適切に」やる方法は？別のDB？別のデータストア？

特に、ドキュメンテーションやテストを生成するのが、例えばClaude Codeを使うとすごく早いからね。

著者が言いたかったのは、一般的に言って、異なるサービスからの同時書き込みは避けた方がいいってことだと思う。これはレースコンディションを引き起こす簡単な方法だからね。

消費されるインターフェースはデータベースで、設計や実装は必要ない あなたは絶対にそれを設計し、実装すべきだよ。なぜなら、それが今やあなたのインターフェースだから。実際、これにより設計にもっと制約が加わることになる。なぜなら、異なる消費者や潜在的なライターが同じリソースを異なるアクセスパターンで競い合うことになるから。さらに、共有テーブルのマイグレーションに伴うメンテナンスオーバーヘッドもあるし、最終的にはこのテーブルに含まれるデータが一部のサービスにしか必要ない場合もあるから、DBレベルでビューやアクセス制御を実装する必要が出てくる。理想的には、実装する機会があれば、APIの方がクリーンで柔軟だよ。ほとんどの場合の問題は、ビジネスがより早い機能を求めていることで、これがしばしば迅速なハックにつながる。例えば、別のサービスからDBテーブルに直接アクセスを与えることになるから、代替案はもっと時間がかかるし、時間がないから、今すぐ機能が欲しいってなる。でも、最後の段落のあなたの考えには同意するよ。新しい設計や再設計を行う努力を避けて、既存のDBに新しいテーブルを追加することでパッチを当てることが非常に多いからね。