- - PR -
【ASP.NET】セッション変数の値を外部で利用する方法
投稿者 | 投稿内容 | ||||||||
---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2006-05-12 09:57
どっとねっとふぁんさん、お返事ありがとうございます。 HttpModule を手掛かりに調べてみましたが、敷居が高そうですね(^_^;) http://www.ascii.jp/pb/msdn/article/a30_0050.html 製造前なら色々と試してみたいと思うのですが、現時点から技術調査していくのは難しいかなぁ、と思ってしまいます。安易な方法に流されてはいけないんですけど・・・
論理削除が一般的なんですか?! ちょっと衝撃です。 監査すべき期間はデータを消しちゃいけないんでしょうね(不正防止)。 ただ、監査の必要のないシステムにとってはDB回りの設計をかなりシッカリしないと論理削除はシステムに影響が出そうですね。 教えていただいたページを眺めてみました。英語力が乏しいため、意味を全て理解できないのが悲しいです(^_^;) これは、どういう仕組みなんでしょうか? WindowsNT チャレンジ/レスポンス認証というものを使って、Request.ServerVariables("LOGON_USER") をアカウントID としているようですが。単純に、これを Session変数で管理しているユーザID に変えれば良い、というレベルではないですよね。 当然、複数のユーザがシステムを利用するわけですが、その辺の切り分けがどのようになされるかが読み取れませんでした。 | ||||||||
|
投稿日時: 2006-05-12 10:08
v$系のView を使ってどうにかできないかなー
とか考えていましたが、 (出来るかわかりませんが トリガーが起動されたセッションIDから 前回投げたSQLのパラメータをみて うにゃうにゃうにゃとか) 解りにくくなりそうですし やっぱりプログラム側からログを出すのが 素直で安上がりになるんじゃないでしょうか | ||||||||
|
投稿日時: 2006-05-12 10:10
こんにちは。
ひろれいさんが開発されているのが欧米の政府関係のシステムかどうかはわかりません が(笑)様々な理由で物理削除を止めて削除フラグで制御しているシステムも結構あり ますね(私が現在開発しているシステムもそうです)。 そこで少し考えていたのですが、テーブル上に削除フラグを設け、プログラムの削除処理 では DELETE を発行するのではなく UPDATE で削除フラグと更新ユーザIDを更新し てもらうとして。そして UPDATE トリガで「削除フラグが UPDATE されたら」ログを出力 後にトリガ側で DELETE をかけてみるという感じで(できるのかどうかは不明)。 自分が担当しているとしたらどうするかで考えたら上記のような解決案になりましたが プログラムとテーブル(あとトリガ)の変更が必要だったりするので、数が多いとちょっと ('A`)マンドクセ って感じになるかもしれませんね。 | ||||||||
|
投稿日時: 2006-05-12 10:33
かるあさん、ぽぴ王子さん、お返事ありがとうございます。 ぽぴ王子さんから提案していただいた方法でも可能だと思います。 UPDATE の TRIGGER で、削除フラグが変更された場合だけ起動するようにし、ログを出力した後、物理削除する、という感じですね。 ただ、この方法だと、テーブルに修正が入る分、単純に DELETE 時にログを出力する方法より手間がかかりますね。 やっぱり、素直に UPDATE は TRIGGER で、DELETE はアプリ内からログを出力する方法が1番手っ取り早いみたいですねぇ | ||||||||
|
投稿日時: 2006-05-12 11:03
私の提案した方法は「あくまで手っ取り早く収める方法」ということで、実際のところは他
の皆さんと同じく「全部プログラムでログ出そうぜ、な!」という感じだったりします。 (以上たぶん自分が後輩に相談されたらそう答えるだろうシミュレーションテストでした) UPDATE 後に DELETE 方式は苦肉の策というか、DELETE するときに更新ユーザ IDがわからないんだから UPDATE で(削除フラグを)更新してしまえ→削除フラグが立 っているレコードをいつ削除するのん?節子それ DROP やない! TRIGGER や!(意 味不明)というわけでトリガでログ出力&削除という無理やり感丸出しで考えてみました。 保守性とかまったくもって無視されてますね orz で、それを踏まえたうえで、DELETE 用のログをアプリから出力させるのであれば、じゃあ UPDATE だってアプリから出力させればいいじゃん?と思ったわけで。 本音を言えば、プロジェクトが行き詰ってからのこういった変更って結構めんどくさいですよね (最初から考えておけよ案は甘んじて受けます) | ||||||||
|
投稿日時: 2006-05-12 11:35
今回の PJ は、「基本ノーメンテ」という依頼があったため、ログを設計から省いていました。(この時点で間違いだったことは、おおいに反省しております) しかし、製造過程でユーザ殿の担当者が変わり、「再度プロト見せて」と言われ、その時に「誰でも入力データをメンテできるんですね」というご指摘があり、利用ユーザに権限を設定する方式も考えたのですが、「厳密に誰がどういう作業をするかは、運用してみないと・・・」って話があり、最終的に「じゃあ、ログを採って、後から追えるようにしておこう」となった、という経緯がありまして・・・ ぽぴ王子さんが言われる通り、「最初からログの方式を盛り込んでおく」のが真っ当な道だと私も思います。(反省) | ||||||||
|
投稿日時: 2006-05-12 12:21
いろんな案が出てるようですので、私からも参考に一案。
「削除はトリガーを使わずストプロで」 主キーとユーザIDを受け取ってログ出力と削除処理を行うストプロを作って使う。 そうすれば、もし将来的に「物理削除を止めて削除フラグで制御して」と言われても ストプロの修正だけで済みます。 |