DBのテーブル構成について

質問

テーブルA：承認が必要なデータが保存されます。
テーブルB：承認が完了したデータが保存されます。
承認処理はWebからオンライン処理で行います。
承認完了後、バッチ処理でテーブルBに内容をコピーします。

承認完了時の処理として、以下の２パターンのどちらにするかで悩んでいます。
１．テーブルAの完了フラグをONにする。
　　バッチ処理は、テーブルAの完了フラグがONのデータを対象とする。
２．新たにテーブルCを設け、承認完了したデータをコピーする。
　　バッチ処理は、テーブルCに存在するデータを対象とする。

１は、完了・未完了が混在するデータの中から完了データを抽出しますが
テーブルAの完了フラグに索引をつけておけば気にする必要がないのでしょうか？
２は、存在するデータ全てが処理対象となる為、データの抽出は用意ですが
その為だけのテーブルCを作るのもありなのでしょうか？

なお、データ件数は最大で５０万件程度を想定しています。

回答No.3

entree

> テーブルA：承認が必要なデータが保存されます。
> テーブルB：承認が完了したデータが保存されます。
> 承認処理はWebからオンライン処理で行います。
> 承認完了後、バッチ処理でテーブルBに内容をコピーします。

一般的な話をすると、テーブルAとテーブルBが1:1で共通の属性を持っているなら、
そもそもテーブルAとテーブルBを分けたりしません。分けることで冗長になるので。
それに、承認済みデータと未承認済みデータはフラグや承認日時列を設定してあげる事で、
SQLで絞り込めますから。性能云々についても、何千万件ならいざしらず、たかが50万件
程度ならチューニング次第でどうにでもなるでしょう。

もちろん、これは一般論であり、そうせざるを得ない理由があるなら話は別です。
なので、まずは、Cテーブル以前にまずBテーブルがなぜ必要なのか明確にしていただかないと。

> １．テーブルAの完了フラグをONにする。
> 　　バッチ処理は、テーブルAの完了フラグがONのデータを対象とする。
> ２．新たにテーブルCを設け、承認完了したデータをコピーする。
> 　　バッチ処理は、テーブルCに存在するデータを対象とする。

前提条件等にもよりますが、普通はますます冗長になる２案は採用しません。
さらに言えば、１案よりもNo.2様が言われている、承認してAテーブルのデータを削除する際に
Bテーブルにデータを入れる方が良いでしょう。

もっと言えば、データを移動するくらいなら、冒頭で述べたとおり、Bテーブル自体も無くし、
承認された時点で承認日時を入れるためのUPDATEをするのが良いように見えます。

回答No.2

Siegrune

オンラインの処理で、
>２．新たにテーブルCを設け、承認完了したデータをコピーする。
>　　バッチ処理は、テーブルCに存在するデータを対象とする
をするなら、
バッチ処理なしで、オンライン処理で、テーブルBに内容をコピーしたらどうなのだろう。
だめな理由が、質問文から読み取れませんけど。
まあ、明示されていない理由（承認した後日次処理で反映してリアルタイムでは反映してはいけないとか）があるとして。

＞１は、完了・未完了が混在するデータの中から完了データを抽出しますが
＞テーブルAの完了フラグに索引をつけておけば気にする必要がないのでしょうか？
サーバの性能や資源にもよりますが、５０万件程度の件数で、インデックスなしとありで
どれくらい性能に差がでるのかな、というところは気になります。
（一般論ですが、1sが1msへと1000倍早くなったところで・・・。）
遅ければ、テーブルAの完了フラグに索引を付けると考えておけばいいと思います。

＞２は、存在するデータ全てが処理対象となる為、データの抽出は用意ですが
＞その為だけのテーブルCを作るのもありなのでしょうか？
冒頭の話は置いておくと、ないわけではないのですが、
・承認を取消しするときにテーブルＣの削除をする必要がある
・未承認一覧を出すときに「テーブルＣになくテーブルＡにあるレコード」を抽出する必要がある
・既に承認済みのものを承認しようとしたときにエラー対策が必要。
　（同じ人のＩＤでクライアント２台で同時に同じレコードに対する承認画面を上げておいて
　順番に実行してみると・・・）

## そもそも、テーブルＣを作って二重にデータを持っているのは資源のムダと思いますし、
## バッチ処理は楽（？）かもしれませんが、最終承認の取消し処理は面倒な上に、
## 未承認の一覧を出すのも手間かかるので、私なら、１しか選択しません。

回答No.1

naoiz

懸念点がよく理解しかねますが、普通は1の方でしょうね。