環境
言語：VB.NET
システム：業務アプリ
DB：SQLserver
経緯
業務アプリ中で、管理者マスタを追加・編集する画面があり、
管理者マスタには、所属開始と所属終了期間を持っています。
現在、追加または編集確定時に所属期間が被らないよう重複チェックの機能が実装されており、
私は、変更の場合に変更元のレコードを重複チェックの対象から除外するよう改修中です。
SQLでキーを除外して返すようにすればいいのですが、
何とテーブルに複合キーが10個も存在しており、
可読性の面からDBではなくPG側で対応しようと考えています。
相談したいこと
追加の場合は、変更元がないため除外対応不要
変更の場合は、変更元の除外対応が必要 という認識です。
この場合、明確に変更と追加の場合で条件分岐させ
追加の場合は変更元のレコードを除外する処理を実行しないように考えています。
しかし、上司から
追加でレコードの変更元のレコードの除外処理をしてもレコードが取得できないだけだから
条件分岐せずにもっと簡潔に書いていいよと言われました。
私的にはしっくりこなかったのですが
皆さんはいかがでしょうか。ご意見をいただければ幸いです。
よろしくお願いいたします。
回答2件
#1
総合スコア758
投稿2025/04/12 14:53
すべての処理がSW側で行われ、DBのトランザクションもすべて適切に管理されていると仮定します。
(不具合改修だから)
新規行の入力の際に除外するロジックでその行が見つからなくてエラーにならないのであれば特に問題はないのではないでしょうか。
あなたが問題点と考えている部分はおそらくロジックを見ないと伝わらないと思います。
重複している行を得るには、
編集後のテーブルから
・編集した行を削除
・重複していない行を削除
をしないといけなくて、
insertの場合編集した行を削除するような条件があってもなくても同じ集合になるっていう話ですよね
で、改修なので編集した行を削除だけの条件だけいれればいいよ、分岐しなくてもいいよっていう話題ですよね、
ちなみに考慮事項が若干おかしいと思います。
変更元という言葉が出てますが変更元という概念は全くいらなくて全部の行について「変更後」のことだけ見ればいいと思います。
なにかほかの条件があるのでしょうか(AからBに変更してはいけないなど)
言葉的にとらえると、全部の変更を一回で確認したいみたいなことかと思うんですが、その時に
1行目を[編集しました]
2行目に[挿入しました]
というときに、1行目の編集前のデータと2行目の編集後のデータが重複しているかどうかなんて何にも関係がないので。
もし、DBで整合性が取れていないのであれば、省かなければいけないのは編集後の同一のレコードではなく編集しているすべてのレコードになるかと思います。
#2
総合スコア86260
投稿2025/04/13 11:24
詳細不明なので、まずは一般論で。
可読性の面からDBではなくPG側で対応しようと考えています。
は、良いと思います。
追加でレコードの変更元のレコードの除外処理をしてもレコードが取得できないだけだから条件分岐せずにもっと簡潔に書いていいよと言われました。
は詳細が分かりませんが、分岐なしで書けるならその方が良いです。上司が「分岐なしで書ける」と判断した訳なので、おそらく書けるのでしょう。
推測が合ってるかどうか分かりませんが、読み取れる範囲から推測すると、
「重複をチェックする必要がある対象レコードを全部取得して、プログラム側の繰り返し処理で、順次チェックして、その際にキーが書き換え対象の場合（変更元ということ）だけチェックから除外する」
で良いかと思います。
上司の方が言ってるのが、「上記のような新規更新を分けない処理にしても、新規の場合は、重複をチェックする必要がある対象レコード取得が0件になるのでチェック処理は0回」という意味なら上司の方の言うとおりでしょう。
あなたの回答
tips
プレビュー
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。