次のテーブルを含むアプリを作成しています: (1) employee_type、(2) employee、(3) employee_action。
Employee_action は employee への外部キーであり、予想どおり、何が起こったかの説明とイベントの日付が含まれています。
ただし、従業員は時間の経過とともにタイプを変更できます (昇進、降格、異動など)。私のスキーマがこれと同じくらい単純である場合、John が 10 年前にピザを配達していたとき、John が会社の CEO であったことを示す履歴レポートを生成できます。
従業員がアクションを実行した時点で特定の一連の特性を持っていたという事実を保存するための最良の方法は何ですか?
ここで私の問題を簡単に述べています。私は 3 つよりも多くのテーブルを持っており、私が心配しているのは従業員の位置だけではありません。すべてを非正規化して、可能なすべての従業員フィールドを含む履歴テーブルを作成することは、私にとって選択肢ではありません。
ありがとう、これが明確であることを願っています。
SQL で時間データを表現するのは難しいです。このテーマに関する非常に優れた本があり、著者からオンラインで無料で入手することもできます: http://www.cs.arizona.edu/people/rts/tdbbook.pdf。
Amazon ページはhttp://www.amazon.com/Developing-Time-Oriented-Database-Applications-Management/dp/1558604367にありますが、絶版になっています。
時間の経過に伴う SQL の変更のモデリングに真剣に取り組んでいる場合、この本は必読です。私はそれから多くのことを学びましたが、一度読んだだけでおそらく 25% しか理解できません :)
employee_type と従業員をリンクする遷移 (多対多) テーブルを導入し、次に従業員アクションをこの遷移テーブルにリンクすることを検討しましたか? 遷移テーブルには、タイムスタンプ用の追加の列を含めることができます。これにより、物事を時系列で追跡できます。
そして、あなたの質問に答えるには、(スキーマの再設計ができない場合) 唯一のオプションは、特定の条件が真である期間を格納するテーブルを追加することだと思います。役職 (「CEO」、「配達員」、またはテーブルに正規化されている場合はそれらの役職の ID) と、従業員がその役職に就いた開始日と終了日のフィールド。そうすれば、employment_history テーブルに参加して、人々が現在持っている役職を取得できます。もちろん、指数関数的に成長する PITA になる位置だけでなく、より多くの「プロパティ」を保存する必要がある場合。詳細については、上記の本をお読みください :)