UPDATE をやめる — EF Core でマスタをバージョン管理する

C# Kaigi 2026 登壇資料

Transcript

1. UPDATE をやめる — EF Core で マスタをバージョン管理する バージョン管理型マスタ C# Kaigi 2026 北尾英之
2. 自己紹介 ： 北尾英之 サカタウエアハウス株式会社 （倉庫業・物流センター運営） システム部所属 約10年前 WMS を設計・実装。数社で安定運用 現在 基幹システム移行に従事 （IBM iSeries [AS/400][COBOL] → C#） 2
3. 自己紹介（つづき） ： 北尾英之 NuGet C# ライブラリを公開（主に自分用）。 直近の FlatXlsx は クラスをエクセル(.xlsx)化 Cysharp の WebSerializer の設計に倣ったもの X @kitaohx 技術書の感想を投稿 ドメイン駆動設計など設計関連の学びを中心に 3
4. 本日は、まず画面イメージの紹介から その後 データモデル → EF Coreの順に説明 ※技術的な話は後半となります 業務や設計の話は、なるべく手短に 4
5. Demo 1 ： 検索(最新一覧) 業務システムのマスタ管理画面になります。 （本画面は Blazor Server。設計思想を伝えて AI 生成） 全体 5
6. Demo 1（拡大） ： 検索(最新一覧) 左側 6
7. Demo 2 ： 追加・変更・削除 追加、変更、削除の画面イメージ 全体 7
8. Demo 2（拡大） ： 追加・変更・削除 左側 8
9. Demo 2（拡大） ： 追加・変更・削除 右側 9
10. Demo 3 ： 変更履歴と、誤削除からの復元 全体 削除されたマスタを（変更前含む）任意の時点へ復元する ※マスタ管理で履歴追記型を採用 10
11. Demo 3（拡大） ： 変更履歴と、誤削除からの復元 左側 11
12. Demo 3（拡大） ： 変更履歴と、誤削除からの復元 削除も復元も、新しい行として履歴に追記される 右側 12
13. なぜマスタ管理に手間をかけるのか 従来の課題と、目指したものについて 13
14. （従来）WHEREをつけると最新版が取得できる 以前、構築したシステムは 開始日・終了日で判定する方式（SCD Type2） select ... from MasterShipper s join MasterBillTo b on b.BillToCode = s.BillToCode and b.StartDate <= @asOf and @asOf < b.EndDate -- JOIN 先にも where s.StartDate <= @asOf and @asOf < s.EndDate -- 本体にも -- 削除は日付で表現する ここで気を使うのは、検索条件の漏れ 書き漏れにより、行の重複やデータの取得につながってしまう SCD Type 2（Slowly Changing Dimension Type 2) 14
15. 長くなるので割愛しますが （←時間があれば最後に） その後、運用で苦労した経験から 私が欲しいのは 最新版を WHERE なしで読める システムが変更の経緯を説明できる そんな"マスタ管理"の仕組み 15
16. 設計の比較 ： 従来型／バージョン管理型 従来型：1テーブルで完結 従来のマスタ（SCD Type2） コード 荷主名 2列の役割は 請求先 履歴が果たす 開始⽇ 終了⽇ 読む側が毎回 WHERE ＋ 基準⽇を書く ※いわゆる削除フラグの場合も同じ構図 全体 バージョン管理型：3テーブルで分担 ‧マスタは従来どおりの形。 マスタ（最新版のみ） 最新版の取得に WHERE 不要 コード ‧開始⽇‧終了⽇はマスタから消え、 荷主名 履歴側で捌く 請求先 ‧未来⽇付の改定は、 （従来どおりの形） タイムラインの分岐で再現する 反映 （Git の Refs を輸⼊） （履歴から最新版を作る） 履歴（追記専⽤） タイムライン（Git 的 Refs） 最新を指す ID（連番） main ⽇時‧担当 操作: 登録‧変更‧削除‧復元 apply-20260901（予約） 変更後の値の⼀式 UPDATE も DELETE もしない 予約＝分岐。当⽇に main へ合流 16
17. 左側 従来の設計 従来型：1テーブルで完結 従来のマスタ（SCD Type2） コード 荷主名 請求先 開始⽇ 終了⽇ 読む側が毎回 WHERE ＋ 基準⽇を書く ※いわゆる削除フラグの場合も同じ構図 2列の役割は 履歴が果たす 17
18. 採用した設計１ ： 最新版マスタ 右側・上 バージョン管理型：3テーブルで分担 ‧マスタは従来どおりの形。 マスタ（最新版のみ） 最新版の取得に WHERE 不要 コード ‧開始⽇‧終了⽇はマスタから消え、 荷主名 履歴側で捌く 請求先 ‧未来⽇付の改定は、 （従来どおりの形） タイムラインの分岐で再現する 反映 （Git の Refs を輸⼊） （履歴から最新版を作る） 18
19. 採用した設計２ ： 履歴 ＋ タイムライン 反映 右側・下 （Git の Refs を輸⼊） （履歴から最新版を作る） 履歴（追記専⽤） タイムライン（Git 的 Refs） 最新を指す ID（連番） main ⽇時‧担当 操作: 登録‧変更‧削除‧復元 apply-20260901（予約） 変更後の値の⼀式 UPDATE も DELETE もしない 予約＝分岐。当⽇に main へ合流 19
20. 試作からの 1人ハッカソン 業務とは別の時間で、まずストアドで実装した ストアド版はうまく動いた しかしマスタが増えるたびに 手続き一式の複製が必要なため、実装がつらい そこで テーブル定義をそのままに、手続きを EF Core で書き直す 20
21. 1人ハッカソン(つづき) 制約： テーブル定義（DDL）は既存まま。 EF Core を既存テーブルに合わせるスタイル 課題： 手続き（履歴に追記する・最新版へ反映する）は、 どのマスタでも同じ。違うのは「列の構成」 21
22. 手続き一式（6操作） 分類 メソッド 備考 追加・更新 CommitAsync 新規と更新（デモ2.） 削除 RemoveAsync 削除（デモ2.） 復元 RevertAsync 履歴の任意時点へ復元。削除後復元も可（デモ3.） ブランチ BranchAsync 別タイムライン作成（予約登録など） 〃 ブランチを main へ MergeAsync ブランチの起点替え ReapplyAsync 〃 (ブランチ中に変更が起きた場合) 22
23. EF Core とは ： テーブルの1行 ＝ C# のクラス1つ まずは一般論として // mdm.MasterShipper の1行 ＝ Shipper クラスのインスタンス1つ var shipper = new Shipper { ShipperCode = "S001", ShipperName = "サンプル商事" }; // 1. オブジェクトを渡す（INSERT の予約） db.Add(shipper); // 2. ここで INSERT 文が組み立てられ、実行される await db.SaveChangesAsync(); SQL 文は書かない。クラスの操作を記述する SQL 列名の記述は、クラスのプロパティから EF Core が解決 23
24. 実装 ： 最新一覧の読み取り（Demo 1.画面の実装） // Shippers.razor 最新一覧タブの読み取り（抜粋） // 1. DBへの接続を用意 await using var db = await DbFactory.CreateDbContextAsync(); // 2. 最新版テーブルから読む（読み取り専用） var q = db.Shippers.AsNoTracking(); // 3. 画面に検索語があれば、絞り込み if (_search != "") q = q.Where(x => x.ShipperCode.Contains(_search) || x.ShipperName.Contains(_search)); // 4. コード順に並べ、先頭200件 _list = await q.OrderBy(x => x.ShipperCode) .Take(200).ToListAsync(); // ここで SELECT が流れる 24
25. 実装 ： 最新一覧の読み取り（つづき） 特徴： 状態を判定する Where なし。Where は検索条件のみ。 最新版であることはテーブルが保証する。 （開発者の注意力に頼らない） 25
26. 再掲）Demo 3 ： 変更履歴（削除済み含む） 26
27. 実装 ： 削除済みを含む一覧（Demo 3・左側） // Shippers.razor 1. 履歴から、キーごとの最新行（削除の行も並ぶ） var latestIds = db.ShipperCommits.AsNoTracking() .Where(c => c.TimelineName == "main") .GroupBy(c => c.ShipperCode) .Select(g => g.Max(c => c.CommitId)); var rows = await db.ShipperCommits.AsNoTracking() .Where(c => latestIds.Contains(c.CommitId)) .OrderBy(c => c.ShipperCode).Take(500).ToListAsync(); // 2. 参照（main）に無ければ「削除済み」。削除フラグの列は無い var mainCodes = (await db.ShipperRefs.AsNoTracking() .Where(r => r.TimelineName == "main") .Select(r => r.MasterCode).ToListAsync()).ToHashSet(); _ledger = rows.Select(c => new LedgerRow(c, IsDeleted: !mainCodes.Contains(c.ShipperCode), …)).ToList(); デモ用に、削除済みを含むすべてのキーを取得 27
28. 実装 ： 削除済みを含む一覧（つづき） 特徴： 削除済みの行にも全項目（名前など）を出す。 履歴が一式の情報を持っている 「削除済み」は導出（削除フラグは持たない） GroupBy でキーの一覧を取得するのは管理画面専用。 最新版は別テーブル 28
29. 再掲 ： 復元は、履歴への追記と HEAD の付け替え 従来型：1テーブルで完結 従来のマスタ（SCD Type2） コード 荷主名 2列の役割は 請求先 履歴が果たす 開始⽇ 終了⽇ 読む側が毎回 WHERE ＋ 基準⽇を書く ※いわゆる削除フラグの場合も同じ構図 全体 バージョン管理型：3テーブルで分担 ‧マスタは従来どおりの形。 マスタ（最新版のみ） 最新版の取得に WHERE 不要 コード ‧開始⽇‧終了⽇はマスタから消え、 荷主名 履歴側で捌く 請求先 ‧未来⽇付の改定は、 （従来どおりの形） タイムラインの分岐で再現する 反映 （Git の Refs を輸⼊） （履歴から最新版を作る） 履歴（追記専⽤） タイムライン（Git 的 Refs） 最新を指す ID（連番） main ⽇時‧担当 操作: 登録‧変更‧削除‧復元 apply-20260901（予約） 変更後の値の⼀式 UPDATE も DELETE もしない 予約＝分岐。当⽇に main へ合流 29
30. 再掲 ： 復元は、履歴への追記と HEAD の付け替え 反映 右側・下 （Git の Refs を輸⼊） （履歴から最新版を作る） 履歴（追記専⽤） タイムライン（Git 的 Refs） 最新を指す ID（連番） main ⽇時‧担当 操作: 登録‧変更‧削除‧復元 apply-20260901（予約） 変更後の値の⼀式 UPDATE も DELETE もしない 予約＝分岐。当⽇に main へ合流 30
31. 再掲 ： Demo 3（拡大） 右側 31
32. 実装 ： 復元（Demo 3の実装） // RevertAsync（抜粋） target は「復元先のバージョン」の行 // 1. 過去の版の値で、新しい行を作る（マスタ固有の列情報） var revert = _adapter.NewSnapshotFrom(target); // 2. 復元先のクラスを生成（いつ・誰が・どの操作で、などの管理情報を編集） FillEvent(revert, MasterEventType.Revert, …); // 3. 追記（EF Core: Add = INSERT の予約） _db.Add(revert); await SaveAsync(ct); // ここで INSERT が1本だけ流れる // 4. HEAD を新しい行へ付け替える AdvanceRef(@ref, key, timeline, revert.CommitId); // 5. 最新版テーブルへ反映 await UpsertEntityAsync(key, revert, ct); await SaveAsync(ct); 32
33. 実装 ： 復元（つづき） 特徴： 復元＝過去のバージョンの値で新しい行を Add。 履歴は UPDATE しない 「戻す」行為も1つの変更として記録 経緯は履歴が説明する 33
34. 実装 ： 復元は、履歴から（削除済みでもよい） // 4. AdvanceRef 参照が無ければ、作り直す if (@ref is null) _db.Add(new TRef { MasterCode = key, TimelineName = timeline, HeadCommitId = newHeadId }); else @ref.HeadCommitId = newHeadId; // 同時実行トークン付き UPDATE // 5. UpsertEntityAsync 最新版に無ければ、作り直す var entity = await FindEntityAsync(key, ct); if (entity is null) _db.Add(_adapter.NewEntityFrom(commit)); else _adapter.ApplyToEntity(commit, entity); 復元操作1本で、削除済みも生きている行も扱うことができる 34
35. 実装 ： 履歴の1行に、経緯を「管理項目」として残す // FillEvent 復元実装2.の中身。履歴の行に書き添える列（抜粋） commit.EventTypeId = eventTypeId; // 登録・変更・削除・復元 commit.TimelineName = timelineName; // どのタイムラインで commit.ParentId = parentId; // 直前の HEAD（何の次か） commit.CopiedFromId = copiedFromId; // 何を元に（復元先のバージョン） commit.ChangedBy = cmd.ChangedBy; // 誰が commit.ChangedAt = now; // いつ commit.BizIntentType = cmd.BizIntentType; // 業務上の意図 保守担当が調べていたことが、管理項目のデータとして残る 35
36. 検証機能：発行される SQL の取り方 optionsBuilder.LogTo(output.WriteLine, // テスト側の DbContext 構成 new[] { RelationalEventId.CommandExecuted }); -- 復元時の INSERT（テストログから採取・整形のみ） INSERT INTO [mdm].[MasterShipperCommits] ([BillToCode], [BizIntentType], [ChangedAt], [ChangedBy], [CopiedFromId], [EventTypeId], [MergeParentId], [ParentId], [ShipperCode], [ShipperName], [ShipperNameShort], [TimelineName]) OUTPUT INSERTED.[CommitId] VALUES (@p0, ..., @p11); 36
37. ストアドと EF Core の比較 EF Core（全マスタ共通の書き込み。これだけ） _db.Add(snapshot); await SaveAsync(ct); // 列名は、共通処理のどこにも現れない ストアド（マスタごとに複製。列の一覧を人が書き写す） insert into mdm.MasterShipperCommits ( ChangedBy, ChangedAt, EventTypeId, ..., CopiedFromId, ShipperCode, ShipperName, ShipperNameShort, BillToCode ) values ( @changedBy, @now, ..., @shipperName, @shipperNameShort, @billToCode ); -- 同じ列挙が、この下の update と insert にも続く 37
38. マスタを1つ追加するとき（横展開）再掲 従来型：1テーブルで完結 従来のマスタ（SCD Type2） コード 荷主名 2列の役割は 請求先 履歴が果たす 開始⽇ 終了⽇ 読む側が毎回 WHERE ＋ 基準⽇を書く ※いわゆる削除フラグの場合も同じ構図 全体 バージョン管理型：3テーブルで分担 ‧マスタは従来どおりの形。 マスタ（最新版のみ） 最新版の取得に WHERE 不要 コード ‧開始⽇‧終了⽇はマスタから消え、 荷主名 履歴側で捌く 請求先 ‧未来⽇付の改定は、 （従来どおりの形） タイムラインの分岐で再現する 反映 （Git の Refs を輸⼊） （履歴から最新版を作る） 履歴（追記専⽤） タイムライン（Git 的 Refs） 最新を指す ID（連番） main ⽇時‧担当 操作: 登録‧変更‧削除‧復元 apply-20260901（予約） 変更後の値の⼀式 UPDATE も DELETE もしない 予約＝分岐。当⽇に main へ合流 38
39. 横展開：マスタが増えても、手続きは増えない ストアドの場合 : 列定義が異なる6操作を追加 MasterShipper_W_Commit.sql MasterShipper_W_Rm.sql MasterShipperCommits_W_Revert.sql MasterShipperCommits_W_Branch.sql MasterShipperCommits_W_Merge.sql MasterShipperCommits_W_Reapply.sql EF Core の場合 : クラス定義を追加すればよい 6操作は書かない（振る舞いは増えない） 39
40. DB側で扱うとして残したもの 1. GC（履歴の整理） = 古い履歴を Archive テーブルへ移す処理 履歴テーブルには archive テーブルがある （モデルでは省略したが） 定期的に、古いデータや不要になった履歴を、 archive へ移す DBとEF Core を使い分けられると安上がりになる ※集合で扱う処理は、DB 内で完結する方が安価 40
41. Aspire で処理内容をトレース 全体 「復元」操作が、クリック → コマンド → SQL のツリーに 41
42. （拡大）Aspire で処理内容をトレース 導入直後は SQL のみだが、 アプリ側に計測を追加すると操作が見える 左側・上 42
43. （拡大）Aspire で処理内容をトレース 左側・下 43
44. （拡大）Aspire で処理内容をトレース 分散システムでも安心 右側 44
45. まとめ １．履歴を UPDATE しない。削除も復元も追加で表現 経緯（いつ・誰が・何を・何を元に）は、列データが語る ２．最新版は別テーブル。削除フラグも基準日の WHERE も不要 最も利用回数の多い「最新版の取得」にコストをかけない 最新版であることは、テーブルが保証する ３．振る舞いを一元化（EF Core）。マスタを足しても増えない 列名は EF Core が捌く。コードは Add と SaveChanges を書く 45
46. 少し深掘り ： 残り時間しだいで A1 楽観ロック ： 同時に操作がぶつかったら壊れないか A2 適用範囲 ： どこまで使えるか・Code First は A3 計測の前後 ： 計測を足す前はどう見えるのか A4 背景 ： なぜ、マスタ管理に手間をかけるのか？ 時間の許す範囲で 46
47. 深掘り A1 ｜ 楽観ロック ： IsConcurrencyToken 楽観ロック＝ロックで待たせない。 更新時に「読み取ったときから変わっていないか」を検査 変わっていたら失敗させる方式 ↩ 本編「復元実装」— RevertAsync(key, targetCommitId, expectedId, cmd) の expectedId 47
48. 深掘り A1 ｜ 楽観ロック ： メソッドが、WHERE 句になる // ShipperMaster.cs b.Property(x => x.HeadCommitId).IsConcurrencyToken(); -- 実行時の UPDATE（テストログから採取・整形のみ） UPDATE [mdm].[MasterShipperRefs] SET [HeadCommitId] = @p5 WHERE [ShipperCode] = @p6 AND [TimelineName] = @p7 AND [HeadCommitId] = @p8; -- ★ @p8 = 読み取ったときの HEAD（expectedId） 他者が先に HEAD を進めていれば0件更新 → DbUpdateConcurrencyException → 業務例外 [50002] ↩ 本編「復元実装」— RevertAsync(key, targetCommitId, expectedId, cmd) の expectedId 48
49. 深掘り A2 ｜ 適用範囲1：増やすのは手軽に、変更は慎重に 今回紹介した設計は、更新頻度が低い前提 例えば、毎秒1回を超える用途には最適化した設計が必要 ↩ 本編「1人ハッカソン」の制約（DDL は既存を活用）と「まとめ」 49
50. 深掘り A2 ｜ 適用範囲2：Code First スキーマ変更（列の追加など）の実行者はコードの外側 「EF Core は追従するだけ」という使い方もできる。 だが「データベース変更も含めて自動化の対象」 とする考え方は重要で、別途ツールを検討（例：flyway） (参考書籍)マイクロサービスアーキテクチャ 第2版 (Sam Newman著) ↩ 本編「1人ハッカソン」の制約（DDL は既存を活用）と「まとめ」 50
51. 深掘り A3 ｜ 計測を足す前の姿 ： SQL が平らに並ぶだけ ↩ 本編「Aspire が便利」： 同じ「復元」1回を、アプリ側の計測を外して撮ったもの 左側・上 51
52. 深掘り A3 ｜ 計測を足す前の姿 ： SQL が平らに並ぶだけ 導入直後は、インフラの自動収集のみ表示される アプリ側に意図・コマンドの2層を足すことで、 操作が可視化できる ↩ 本編「Aspire が便利」： 同じ「復元」1回を、アプリ側の計測を外して撮ったもの 52
53. 深掘り A3 ｜ 計測を足す前の姿 ： SQL が平らに並ぶだけ ↩ 本編「Aspire が便利」： 同じ「復元」1回を、アプリ側の計測を外して撮ったもの 全体 53
54. 深掘り A4 ｜ （従来）保守担当である「私」が払ってきた コスト 「なぜこの値になったのか」を、保守担当が説明している ・追加・更新・削除にかかわる問い合わせ （いつ、だれがを調べるのは保守担当の仕事） マスタの状態変更はログ調査など、地味な調査が必要 ↩ 設計方針採用の背景 54
55. 深掘り A4 ｜ （従来）「保守担当の責務」という、設計判断 かつては、ディスク容量単価も高く 今よりも保守担当者を確保しやすかった状況だった しかし、現代は ・安価になったディスク容量単価 ・人材不足 状況が逆転しているのでは？ ↩ 設計方針採用の背景 55
56. 深掘り A4 ｜ 私が欲しいのは 最新版を WHERE なしで読める システムが変更の経緯を説明できる ＝ 開発コストを先払いし、本稼働後の負担を軽減する 56
57. ご清聴ありがとうございました 北尾 英之 (@kitaohx)