環境
私は現在、注文を管理し、技術者とサービスの間で通信するためのツールを開発しています。産業の文脈は、放送とテレビです。それぞれが独自の仕様に合わせて作成されたメディア ファイルを期待する複数のクライアントは、単一のクライアントの注文の制限された範囲内であっても、ワークフローが大きく異なることを意味します。
あるクライアントは、ある日は 1 つの SD ファイルを要求し、次の日には最大 14 個のファイルを含む本格的な HD パッケージを要求することができます... MySQL データベースでは、ワークフローを構成するすべての小さなタスクに関する正確な情報を保存しようとしています。複数のフォーム:
- 正確な追跡のために、タスクが完了するたびに DATETIME 値
- VARCHAR の会社のファイル システムで新しく作成されたファイルへのパス
- 背景情報を TEXT 値でアーカイブします (ユーザー コメントなどの情報。たとえば、インシデントが発生して前進が妨げられた場合、ユーザーはこのフィードでそれについてコメントできます)
これに 30 個の異なるファイル タイプを掛けると、1 つのテーブルには多すぎます。したがって、クライアントごとに分割すると思いました。クライアントごとに1つのテーブルを作成して、15を超えるフィールドを操作しない1つのテーブルを使用するだけで注文できるようにします。それでも、クライアントが 9 つの異なるトランスコーディング仕様を持っていて、特定の注文が 1 つしか必要としない場合、これはかなり厳格なソリューションです。各トランスコーディング フィールドにフラグ フィールドを追加して、その特定の注文に必要なフィールドを示す必要があると思います。
概念
次に、注文が実行されている間 (約 1 日から 1 か月の範囲) の一時テーブルを作成できるのではないかというクレイジーなアイデアを思いつきました。25 を超える注文が同時に実行されることはめったにないため、混雑することはありません。
アイデアは、注文ごとに調整されたテーブルを作成し、フラグや不必要な永遠に空のフィールドを排除することです。注文が完了すると、テーブルはフラッシュされ、JSON エンコードされて TEXT または BLOB に変換されるため、後で変更が必要になった場合に復元できます。
DBMS (特に MySQL) がそのような慣行に苦しんでいる経験はありますか? これは実行可能なオプションのように聞こえますか? 私は喜んで試してみて（私はすでに始めています）、ここで続けるかやめるかについてアドバイスを求めています.
ご意見ありがとうございます。