はじめに
ソケット通信などの直接通信を使わず、データベースのテーブルを介してプロセス間の連携を行う設計の備忘録です。高速なリアルタイム処理はできませんが、データベースが整合性を保証し、状態確認も容易なため、プロセス側がシンプルな実装で済み、楽です。
改訂履歴
- 2026/04/15 : 初版公開。
本文
1. 概要
お題は生産ラインの管理システムです。レコードの状態遷移をトリガーに各プロセスが動作する設計になります。DB のテーブルがメッセージキューやステートマシンの役割を持つイメージです。
2. 処理ステップ
処理ステップは以下になります。
| ステップ | 処理主体 | 対象 | トリガー | 処理内容 |
|---|---|---|---|---|
| 1 | 上位システム連携プロセス / 生産管理アプリ | 生産予定 | 生産予定の登録要求 | 生産予定テーブルにレコードを登録する |
| 2 | 生産実行プロセス | 生産予定 | 開始条件成立 | 対象レコードを生産実行テーブルに移行する |
| 3 | 装置制御プロセス | 生産実行 | production_status = 0 |
生産を開始し production_status = 1 に更新する |
| 4 | 装置制御プロセス | 生産実行 | 生産中 |
current_quantity を更新する |
| 5 | 装置制御プロセス | 生産実行 | 生産完了 |
production_status = 2 に更新する |
| 6 | 生産実行プロセス | 生産実行 | production_status = 2 |
対象レコードを生産実績テーブルに移行する |
| 7 | 上位システム連携プロセス | 生産実績 | upload_status = 0 |
上位システムに送信する |
| 8 | 上位システム連携プロセス | 生産実績 | 送信成功 |
upload_status = 1 に更新する |
3. テーブル定義の例
この例では予定開始日時を実質的な優先順位として考えています。要件によっては優先度カラムを別途持たせてもよいと思います。インデックスは予定開始日時やステータスに付与します。
3-1. 生産予定テーブル
| 列名 | 型 | 説明 |
|---|---|---|
| order_id | INT | 主キー（シーケンス番号） |
| product_type_id | VARCHAR | 生産品種 ID |
| scheduled_start_at | DATETIME | 予定開始日時 |
| scheduled_quantity | INT | 予定生産数量 |
| created_at | DATETIME | 作成日時 |
| created_by | VARCHAR | 作成者 |
| updated_at | DATETIME | 更新日時 |
| updated_by | VARCHAR | 更新者 |
| remarks | VARCHAR | 備考 |
3-2. 生産実行テーブル
| 列名 | 型 | 説明 |
|---|---|---|
| order_id | INT | 主キー（シーケンス番号） |
| product_type_id | VARCHAR | 生産品種 ID |
| scheduled_start_at | DATETIME | 予定開始日時 |
| production_start_at | DATETIME | 生産開始日時 |
| scheduled_quantity | INT | 予定生産数量 |
| current_quantity | INT | 現在生産数量 |
| production_status | INT | 生産実行ステータス |
| created_at | DATETIME | 作成日時 |
| created_by | VARCHAR | 作成者 |
| updated_at | DATETIME | 更新日時 |
| updated_by | VARCHAR | 更新者 |
| remarks | VARCHAR | 備考 |
3-2-1. 生産実行ステータス (production_status) 定義
| 値 | 説明 |
|---|---|
| 0 | 未処理 |
| 1 | 処理中 |
| 2 | 処理完了 |
| 9 | 異常 |
3-3. 生産実績テーブル
| 列名 | 型 | 説明 |
|---|---|---|
| order_id | INT | 主キー（シーケンス番号） |
| product_type_id | VARCHAR | 生産品種 ID |
| scheduled_start_at | DATETIME | 予定開始日時 |
| production_start_at | DATETIME | 生産開始日時 |
| production_end_at | DATETIME | 生産完了日時 |
| scheduled_quantity | INT | 予定生産数量 |
| actual_quantity | INT | 最終生産数量 |
| upload_status | INT | 上位送信ステータス |
| created_at | DATETIME | 作成日時 |
| created_by | VARCHAR | 作成者 |
| updated_at | DATETIME | 更新日時 |
| updated_by | VARCHAR | 更新者 |
| remarks | VARCHAR | 備考 |
3-3-1. 上位送信ステータス (upload_status) 定義
| 値 | 説明 |
|---|---|
| 0 | 未送信 |
| 1 | 送信完了 |
| 9 | 異常 |
4. メリット
この設計の一番のメリットは、プロセス間の直接的な依存関係を減らせることです。例えば、装置制御プロセスが再起動したとしても、生産実行テーブルを確認すれば、現在どの生産を処理しているのかを判断できます。また各プロセスが DB 上の状態を共有するため、プロセス間で独自の通信プロトコルを実装する必要がありません。さらに処理状態が DB に残るため、障害発生時の調査や運用監視も比較的容易です。
5. デメリット
この設計のデメリットは、リアルタイム性に限界があることです。DB のポーリングが基本となるため、監視間隔による遅延が発生します。またプロセス間の連携を DB に集約するため DB がボトルネックになる可能性があります。プロセス数や処理量が増えるほど DB への負荷も増加します。
おわりに
だいたいいつもこんな感じの古典的な設計に落ち着きます。