2026年7月5日 DB設計エンティティ設計venuesmeetings
今日はコードを1行も書いていない。その代わり、まじまじさんと一緒にDBの基礎を勉強し直した。リレーショナルDBとは何か、テーブルとマスタの違い、クラスとインスタンスの違い。一見遠回りに見えたこの時間が、最後には断酒でGO!!が抱えている一番根深い設計課題の核心にたどり着くことになった。
最初はシンプルな疑問から始まった。「venues（会場）とmeetings（例会）の2つのテーブルだけで足りるんじゃないか」と。実際に本番のdanshu.dbを見てみると、テーブルは11個あった。
danshu_sites, meetings, raw_meetings events, national_sources, schedule_exceptions meeting_master, org_hierarchy, venues meeting_types, raw_events, zendanren_organizations
多く見えるが、仕分けてみると3つの軸が混ざっているだけだった。「生データか確定データか」（raw_meetings/meetings、raw_events/events）、「定期活動か単発イベントか」（meetings系/events）、「組織構造」（org_hierarchy、zendanren_organizations）。1つのエンティティに1つの責務だけを持たせる、という原則からすると、11個は多すぎるどころか、まだ足りない領域（会員機能、公開範囲の管理）がある。
実際に .schema venues と .schema meetings を並べて見たとき、venuesテーブルの中に meeting_name, schedule, next_date, start_time, end_time, recurrence という「例会っぽいカラム」が存在していることに気づいた。これは以前から「技術的負債」として認識していたfallback系フィールドの実物だった。
今日一番大きな気づきはここだった。まじまじさんの言葉を借りると、こうなる。
例会は組織の中でユニーク名がつけられていて、例会はクラスでありインスタンスでもある。例会クラスは定期開催パターンを持っている。例会インスタンスは日時と会場を持った実態。
「立川例会」という名前そのものは、組織が定めた継続的な"型"（例会クラス）。そこから生まれる「2026年7月15日19時、立川市民会館で開催」という1回分は、日時と会場が確定した"実態"（例会インスタンス）。この2つを混同すると、会場変更のたびに「これは同じ例会の継続なのか、別の新しい例会なのか」を判断できなくなる。
実は本番の meeting_master テーブルには、すでに match_facility, match_address といった「マッチング用」のカラムが存在していた。最初は「会場変更があるならマッチングは不要では」と思ったが、逆だった。会場が変わっても"同じ例会である"という連続性を保つために、このマッチングという仕組みが必要だったのだ。
断酒会の組織構造も整理した。全日本断酒連盟（全断連）を頂点に、ブロック、都道府県断酒会、エリア断酒会、そして支部制を取る細分化された断酒会まで存在する。ただし都道府県ごとに階層の深さも呼び方もまちまちで、エリア制の県もあれば、月1回1会場だけの小規模な組織もある。
この多様性を固定段数のテーブルで表現しようとすると必ず破綻する。代わりに、組織同士の親子関係だけを持つ自己参照型のテーブル（organizations / organization_hierarchy）として設計すれば、どんな深さの階層でも表現できる。org_typeを自由記述にしておけば、「ブロック」のような新しい階層単位が将来出てきても構造を変えずに済む。
なお、断酒でGO!!は全日本断酒連盟に加盟している断酒会の例会情報を第一優先で集めている。データ収集の方針として、これは今日整理した組織階層の設計にもそのまま反映される。
今日の勉強と議論を、以下の2本の設計メモとしてdocsに残した。どちらも未実装の設計段階のものだが、TBD（未確定事項）も含めて明記してある。
| ファイル | 内容 |
|---|---|
| docs/future-member-features.md | 会員登録・Myカレンダー・例会登録機能のエンティティ設計 |
| docs/phase1-organizations-design.md | 組織マスタ（organizations）新設のPhase 1設計 |
会員登録機能は、断酒でGO!!に会員登録することで、利用者一人一人に合わせたサービス提供を可能にするための土台になる。そこから派生するMyカレンダー機能は、所属団体やお気に入り例会を登録して表示をカスタマイズできるようにするもの。例会登録機能は、それよりもさらに厳密な本人確認を前提に、所属断酒会の例会そのものを登録・変更・削除できるようにする機能だ。どちらも、アルコール依存症からの回復を目指す人が、自分に合った例会・ミーティングに継続してアクセスできるようにするための拡張として位置づけている。
今日の議論で浮かんだ、次に手をつけるべき論点をメモしておく。
今日はコードは書かなかったが、次に実装するときに迷わないための地図は、確実に一枚描けたと思う。