2011-12-15 9 views
2

したがって、私はMYSQLデータベースを構築しています。このデータベースにはpendingArchivesというテーブルが存在します。管理者がアーカイブされたファイルを承認できるようになるまでは、「未承認」または整数フィールドであるため「0」のままです。しかし、私があなたに質問したのは、承認されたレコードをpendingArchivesテーブルから削除する必要があるかどうかということです。現時点では、approvedフィールドの値を「1」に設定するだけで、承認されたことになります。データベースに保存するかどうかを指定する

もっと合意された方法で、承認された値を1に設定するか、完全に新しいapprovedテーブルにレコードを移動するだけで、私に教えてください。

おかげで、

エヴァン

+0

項目が承認された後、未承認になることはできますか?承認者の身元とタイムスタンプも記録しますか? – wallyk

+1

これは非常に良い点です。今、私はそれについて考えています - そうです。ちょうどあなたなかった私の質問に答え;) –

答えて

1

これは履歴テーブルとして機能させ、それはarchiveStatus

という名前の新しいテーブルを作成し、そこで移動することができます。または、archiveHistoryという名前の新しいテーブルを作成してそこに移動することができます。

どちらの場合も、承認日の日付列があることを確認し、status列(承認された値と承認されていない値)が変更されたときにトリガーを修正してください。活動を追跡

[編集/追加]私の経験で

は、私が働いていたDBAが持っているしたい最高の楽しみの一つです。ほとんどの場合、レポートに疑問を抱くデータウェアハウスや他のVLDB、ユーザーは、アクションが実行され、確認された後、ユーザーにバックアップまたは実装されるという証拠を示したいと考えています。ジョブやSSISパッケージの実行のみが変更、データの読み込み、データの修正、データの挿入がログに記録されるセキュリティ保護されたテーブル、データベースバックアップの開始時刻と終了時刻、実行結果、そこから...物事を追跡する方法があるのは常に良いことです。状況がそれを必要としない場合(例えば誤った挿入により重複を招くなど)、活動を記録しない限りは削除しないでください。そのような場合は、是正措置が確認され、それをバックアップする確かな証拠がある限り、間違いを認めても大丈夫です。 DBAのチームと管理者にとっては、適切に設定されたトラッキング・テーブルを使用してレポートを作成することもできます。

+0

にも適用することが長所/短所があり、可能なすべての問題をカバーしています。 –

+0

私はそれが助けてくれることを願っています。過去の経験に基づいてさらに情報を追加しました。トラッキングテーブルを適切に設定することは、あるテーブルから別のテーブルにデータを移動する必要を避けるための鍵です。ジョブを管理したり、要件を再確認したりするのに使用できる適切な履歴/追跡テーブルとして機能するようにテーブルを再構築してください。 – Nonym

+0

よく分かりやすい決定は、各オプションの長所/短所を軽視し、それに応じて選択するようです。 –

1

私はそれがで読み取り/動作するように容易だから、組織の新しいテーブルにレコードを移動する移動します。そうすれば、承認されていない人物を除外する必要はありません。

+0

1あなたは良い答え –

+0

ために始めるために、私はもちろん、しかし、別のユーザーとして、このことを考慮さ巧み項目がいくつかの時間後に未承認になるという可能性がある、と指摘しました。これは私が想定している元のテーブルにレコードが必要です。 –

+0

@エヴァン各テーブルがどのくらい大きく成長するかを考え、各オペレーションがどのくらいの頻度で実行されるかを検討します。 10年後には、データの99%が1つのテーブルに収まると思っています。それは必要ですか? –

1

ほとんどのMYSQL設計上の質問と同様に、これはどのような操作の種類とデータセットのサイズに関するものです。他のテーブルに移動することは余分なオーバーヘッドのように見えます。承認されたもので他のインデックスを必要とする操作をしない限りです。

1

このようなレコードを削除するのではなく、IsActive/IsValid /などを設定します。このようなレコードが他のテーブルから参照される場合や、後で履歴分析で必要となる場合は、特に重要です。

0

これは本当にデータ保持/監査要件が何であるかによって異なります。両方に多くの賛否両論/意見があります - 私は "ソフト削除対ハード削除"のGoogleを検索することをお勧めします

0

これは興味深い質問です。結局のところ、答えは "それは依存する"です。考慮すべき事項は次のとおりです。

  1. 承認されたレコードと未承認レコードの選択頻度はどのくらいですか?あなたが他よりも頻繁に1つを選択している場合、データを分離することは意味があるかもしれません。

  2. データがどのように成長する

  3. ?おそらく、承認されたレコードは時間が経つにつれて成長し、未承認のレコードはユーザーの機能により多く成長するでしょう。これがそうであれば、それは時間が経つにつれて、承認された記録の量が承認されていない記録を矮小にすることを意味します。これはまた、データを分離することを主張する。承認されていないレコードの対承認のために許容されている操作のどのような

  4. ?たとえば、承認されていないレコードのみを削除/更新できますか?そうであれば、レコードを分離することもできます。これは、書き込みロックを特定のテーブルに制限し、異なるDB権限を使用してこの制約を適用することができるからです。

  5. あなたは承認されていないと同じ結果セット内のレコードを承認の両方を示すの要件を持っているのだろうか?それはそれらを一緒に保つことを主張するだろう。

希望します。