「リストの要素に使われない区切り文字は？」──日常的な会話に現れるアンチパターンのサイン
では、アンチパターンにいち早く気づくには、どうすればよいのか。和田氏によれば、アンチパターンが厄介なのは「完成した設計図を一目見ただけでは判断できない場合が多い」点にあるという。
和田氏は重ねて、「その兆しは設計レビューや日常的な会話の中に現れる」と指摘する。たとえば、「このリストでサポートしなきゃいけない最大のエントリー数はいくつだっけ？」という問いかけ。リレーショナルデータベースを使っているにもかかわらず、リストの長さを気にし始めた時点で、設計は怪しくなっている。また、「SQLで単語境界を一致させる方法ってどうやるんだっけ？」という発言も危険なサインだ。「なぜこの文脈で単語境界が必要になるのか？」と立ち止まるべき場面である。さらに、「リストの要素に絶対使われない区切り文字って何だろう？」という議論も典型例だ。区切り文字を探し始めた時点で、設計は本来の構造から外れ始めている。
こうした「むむっ？」と感じるセリフも、本書では各章ごとに丁寧に整理されている。完成物のレビューだけでなく、会話そのものを手がかりにアンチパターンを察知できる点は、本書の実践的な価値の一つだと和田氏は語る。
一方で和田氏は、アンチパターンを絶対悪として扱う姿勢にも否定的だ。アンチパターンもパターンである以上、「使ってよい場合」も存在する。現実のシステム開発では、制約やコスト、時間の都合から、「打てる手の中で一番マシな選択」を迫られる場面も少なくない。ジェイウォークアンチパターンに該当する設計も、非正規化という文脈で、意図的に選ばれるケースはあり得る。
重要なのは、その選択を無自覚に行うか、トレードオフを理解したうえで行うかだ。少なくとも、最初から安易に文字列型でのカンマ区切りを選ぶべきではない。まずは正規化されたテーブル設計を検討し、それでも要件を満たせない場合に限って、例外として扱うべきだと和田氏は強調した。
このような説明からも、本書が単なる「べからず集」ではないことが分かる。パターンとは常にコンテキスト依存の解決策であり、絶対解ではない。制約が変われば、導かれる解も変わる。その前提に立って整理されているからこそ、本書は「実務で使える本」として長く評価され続けているのだ。
ここで和田氏は「答え合わせ」として、先ほどのジェイウォークアンチパターンを修正する方法を提示した。解決策は、極めてオーソドックスなものだ。アカウントとプロダクトが多対多の関係にあるなら、交差テーブルを導入する。Contactsのような中間テーブルを設けることで、検索、集約、更新のすべてをシンプルに扱えるようになる。
正規表現や文字列トリックは不要になり、インデックスも正しく機能する。COUNT関数を素直に使え、INSERTやDELETEで関連付けを管理できる。本来リレーショナルデータベースが備えている力を、そのまま活かせる設計に戻るわけだ。
参照整合性制約を設定すれば、不正なアカウントIDの混入も防げる。区切り文字を気にする必要も、リスト長の制限を心配する必要もなくなる。こうした「当たり前」の構造に立ち返ることが、アンチパターンからの脱出だと和田氏は述べる。
章末に付随するミニアンチパターンも示唆に富む。既存のジェイウォーク列を無理やり縦持ちに見せかけるため、再帰SQLなどの技巧を駆使する例が紹介されている。SQLとしては正当であっても、設計上の歪みを別の複雑さで覆い隠しているにすぎない。正しい構造を採用していれば、より単純なSQLで済んだはずだという対比が、設計の重要性を際立たせる。
第2章の結論は明快だ。一つの値は、一つの行と一つの列に格納する。これはリレーショナルデータベースの基本原則であり、最終的にはデータのアトミック性という原点に帰着する。
セッションの締めくくりとして、和田氏はビスマルクの言葉を引用した。「愚者は経験に学び、賢者は歴史に学ぶ」。その真意は、他人の失敗から学ぶことで、自分の失敗を回避することにあるという。アンチパターンとは、まさにそのために編み上げられた知識体系だ。
データベース設計の失敗は、過去のデータと未来のデータの両方に影響を及ぼし、リカバリーのコストも極めて大きい。だからこそ、よくある失敗にはあらかじめ名前を与え、落ちなくていい落とし穴を避ける。その積み重ねが、無駄な手戻りを減らし、エンジニアの生産性を高め、結果として事業への貢献につながっていく。
本書は、そうした振り返りを促すための実践的な道具であり、「社内読書会にもおすすめできる一冊」だ。単に知識を得るだけでなく、自分たちのプロダクトに引き寄せて読み解くことで、それぞれのアンチパターンが血の通った経験知へと変わってゆくのだ。
