アカウント名:
パスワード:
再発防止策のほうが気になる
記事によると> 営業担当者2人によるWチェックを行ったが防げなかった。> 「今後管理職も加わって確認する手順に変える。担当者に対しても手順の遵守を徹底する」（同）としている。とあるが、Wチェックからトリプルチェックにしてもコストばっかりかかるし、作業画面のインタフェース変えるとかのほうがいいんじゃないかなぁ・・・
消えた直後からユーザが新しい座席予約をどんどん入れていたので、トランザクションログから戻すのも調停が難しいと判断したのかもしれませんね。
トランザクションのログが残っているならば、事故発生時までのログをまっさらのDBに適用することにより、発生時点でのDBの状態を再現してそこから予約状況を拾えると思う。
原理的には。
実際には複数の独立したDBが絡み合ってたりして一筋縄ではいかないだろうけれど。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲはアレゲ以上のなにものでもなさげ -- アレゲ研究家
やってしまったものは仕方ない (スコア:5, すばらしい洞察)
再発防止策のほうが気になる
記事によると
> 営業担当者2人によるWチェックを行ったが防げなかった。
> 「今後管理職も加わって確認する手順に変える。担当者に対しても手順の遵守を徹底する」（同）としている。
とあるが、Wチェックからトリプルチェックにしてもコストばっかりかかるし、
作業画面のインタフェース変えるとかのほうがいいんじゃないかなぁ・・・
Re:やってしまったものは仕方ない (スコア:2)
人生は七転び八起き、一日は早寝早起き
Re:やってしまったものは仕方ない (スコア:1)
消えた直後からユーザが新しい座席予約をどんどん入れていたので、
トランザクションログから戻すのも調停が難しいと判断したのかもしれませんね。
Re:やってしまったものは仕方ない (スコア:1)
トランザクションのログが残っているならば、事故発生時までのログをまっさらのDBに適用することにより、
発生時点でのDBの状態を再現してそこから予約状況を拾えると思う。
原理的には。
実際には複数の独立したDBが絡み合ってたりして一筋縄ではいかないだろうけれど。