「既存のデータベースであり、キャンセルのフラグがある」なら、キャンセルを抽出条件に使います。すでに運用中であり、仕様を完全に把握しているのでなければ、データの削除に対する影響がわかりません
「既存のデータベースであり、キャンセルのフラグがない」なら、集計に含まないとする条件をそれぞれ追加するしかないでしょう
「既存のデータベースであり、キャンセルを削除する」を考えた場合、今後の運用に問題はないでしょうか?それを正しく削除できますか?誰が、いつ、できますか?
hirotonの場合、設計段階として、Nullを数えるような仕組みを極力排除します。仕組みとしては、「現物票出力日」「出庫日」「梱包明細出力日」の他に「状態」フィールドを設け、「-1;キャンセル;0;現物票未出力;1;未梱包;2;未出庫;3;出庫済み
」とします。明確に目的のものを集計するのでミスが起こりません
キャンセルについては、「梱包まで済んでキャンセルになった」のようなそれをどうするんだ?という場合もあると思います。要求に合わせて「受注状態(キャンセル・受注・納品済み)」「作業行程(伝票未発行、未梱包、未出庫、出庫済み)」のように、複数フィールドで管理する場合もあります
-1からの連番にしてしまっているので設計段階で工程をしっかり把握しておく必要があることには注意が必要です。「状態マスタ」テーブルを作成して、数値に意味を持たせないのが正しい正規化ですが、末端の情報にそこまで神経質になって後から良かったと感じたことはそれほどないです
当たり前ですが、削除すべきデータは削除します(ミス登録とか)
「キャンセル」というアクションは「存在しなかったもの」として扱っていいモノでしょうか?そうであるならば、「キャンセル」というアクションが起きたときにデータを削除するようにすればいいです
「とりあえず削除フラグ」というやり方は削除フラグが問題の原因ではなく、「とりあえず」という妥協する姿勢が問題になるのです
現在のレコード数が約5万件、うち出荷済み扱いになっていないのが約1500件
およそ3%が問題のデータということですが、パフォーマンスが問題になった場合、不要分のデータが存在しなかったとするならば、問題が発生するまでの期間の3%の期間だけ延命できることになります
パフォーマンスが問題になるならば、もっと根本的な解決が必要です