名前を変更するオブジェクトを追跡するためのモデル

Question

興味深い問題が発生しました。私は、リモートの組み込みシステムからのレポートをポーリングして受け入れるデーモンプロセス用のデータベースを継承しました。これらのシステムの1つを持つ各サイトは、12種類の異なる燃料タンクを監視できます。 （実際にはほとんどの2,3または4つのタンクを監視しています）

タンクが補充されたり、タンクが最低レベルに達したときなどに、プログラムはそのイベントをPostgresデータベースに保存しました。データベースが元々構築された方法では、別の「タンク」テーブルがあったとしても、イベント記録に各燃料タンクの情報（燃料の種類など）を保存していました。特定の組み込みユニットに関連付けるために外部キーフィールドをテーブルに追加し、それを特定のタンクに関連付けるためにイベントテーブルの外部キーを追加しました。

ここに問題があります：タンクの追加、取り外し、または燃料の種類の変更はいつでも可能です。タンクを追加することは問題ではありませんが、削除された場合、記録されたイベントは「孤立しています」。さらに、燃料の種類が「ジェット」から「ロケット」に変更された場合、誰かが歴史を捜索する際に、「ロケット」燃料にこれらの古い出来事が起こったと考えられます。実際には、ジェット燃料。

私はオフラインでいくつかの提案を受けました：（1）タンクのアーカイブテーブルを作成し、何か変更があったら、ユニークなIDを持つそのタンクレコードをアーカイブテーブルに移動し、新しい（2）とタンクテーブルへの「アクティブ」フィールドの新しいIDを記録し、スペックが変更されたときでも新しい行を作成しますが、タンクの現在の状態を「アクティブ」としてフラグを立てます。

これらの提案されたソリューションや他のアイデアは誰でもありますか？

Answer 1

問題はどこですか？すべての関連情報がイベント記録にあります。またはタンクとイベントの間にリンクを作成したときにタンク情報を保持していない場合。孤立しているという事実は、問題を引き起こしたのはイベントテーブルから燃料タイプを取り除くことの問題ではないということです。

情報を前方に保持する理由はいくつかあります。その一つが歴史です。テーブルをタンクのエンティティにリンクすることにより、現在の状態を表示することができます。

は、ユーザーがさえ、すべてのイベントを見るために欠けている：「タイプ」は、タンクのテーブル上のタイプと異なる場合、イベントテーブルには、私は十分に問題を理解していないと思い

..あなたに履歴が表示されますタンクが削除されたら？

開始日と終了日を持つタンクタイプのタンクとイベントの間の関連テーブルを追加すると、問題は解決しますか？

イベントにタンクの情報を残しても何が問題になりますか？このようにして、イベントが発生した時点のタンクの状態を知ることができますか？

Answer 2

タンクを追加することは問題ではありませんが、1台が取り外されている場合は、それらの イベントが「孤立した」状態になります。さらに、燃料の種類が であれば、「ジェット」から「ロケット」に変更して、誰かが歴史を通して を検索すると、それらの古い出来事はすべて「ロケット」燃料 に起こったと思います。 「ジェット」燃料に供給される。

誰かが元のデザインを完全に理解することなく外部キー制約を追加したためです。あなたがその人を見つけることができるかどうかを見て、彼に激しく話してください。あなたの指をたくましく振る。