- PR -

【SQL】複数テーブル検索時の整合性

投稿者投稿内容
fight
ベテラン
会議室デビュー日: 2005/09/25
投稿数: 74
投稿日時: 2006-06-01 11:47
2006/01/01 00:00:00
テーブルA
 レコード1

テーブルB

2006/01/01 00:00:01
テーブルA

テーブルB
 レコード1


<仕様>
1.当システムにはテーブル照会機能とレコード移動機能があります。それぞれ別スレッドです。
2.テーブル照会機能はテーブルAとテーブルBを検索します。
3.移動機能はテーブルAのレコードをテーブルBに移動します。

<問題点>
テーブル照会機能がテーブルAを検索(2006/01/01 00:00:00)
レコード移動機能がテーブルAのレコード1をテーブルBに移動
テーブル照会機能がテーブルBを検索(2006/01/01 00:00:01)
上記のような順になった場合、検索結果が二重に表示されてしまいます。
テーブルAとテーブルBを同時に検索する方法や整合性をとる方法がわからず困っています。
ご存知の方いらっしゃいましたら教えていただけるとありがたいです。よろしくお願いいたします。
じゃんぬねっと
ぬし
会議室デビュー日: 2004/12/22
投稿数: 7811
お住まい・勤務地: 愛知県名古屋市
投稿日時: 2006-06-01 11:56
引用:

mukoubutiさんの書き込み (2006-06-01 11:47) より:

テーブル照会機能がテーブルAを検索(2006/01/01 00:00:00)
レコード移動機能がテーブルAのレコード1をテーブルBに移動
テーブル照会機能がテーブルBを検索(2006/01/01 00:00:01)
上記のような順になった場合、検索結果が二重に表示されてしまいます。
テーブルAとテーブルBを同時に検索する方法や整合性をとる方法がわからず困っています。


「Database Expert 会議室」向けの話題だと思いますが、
テーブル A と B を JOIN して SELECT すれば良いのではないでしょうか?

_________________
C# と VB.NET の入門サイト
じゃんぬねっと日誌
Java僧
ぬし
会議室デビュー日: 2003/11/06
投稿数: 261
投稿日時: 2006-06-01 12:47
お使いのRDBMSがわかりませんが、テーブル照会機能とレコード移動機能の
トランザクションとその隔離レベルはどうなっていますか?
#テーブル照会機能が2つのトランザクションになってしまっている気がする。
fight
ベテラン
会議室デビュー日: 2005/09/25
投稿数: 74
投稿日時: 2006-06-05 15:17
RDBMSはSQL SERVER 2000を使っています。
JOINですか、、、結合条件は無いためUNIONじゃだめですか?
ところでUNIONを使ってテーブルAとテーブルBの検索を1つのSQL文で検索した場合、テーブルAのSELECTとテーブルBのSELECTとの間にテーブルBへのDELETE文は割り込むことができるんでしょうか?
その場合は、検索結果からはデータが欠落する形になるのでしょうか?
JIMMY
常連さん
会議室デビュー日: 2004/10/26
投稿数: 32
お住まい・勤務地: 東京
投稿日時: 2006-06-05 15:49
こんにちは

・テーブル照会機能がテーブルAを検索(2006/01/01 00:00:00)
・レコード移動機能がテーブルAのレコード1をテーブルBに移動
・テーブル照会機能がテーブルBを検索(2006/01/01 00:00:01)
まず、処理順が問題なのだと思いますが、何故二つの照会機能の間に移動機能がはいるのでしょうか?
テーブルAを一時バッファのような使い方をしているのでしたら
・テーブル照会機能がテーブルAを検索(2006/01/01 00:00:00)
・テーブル照会機能がテーブルBを検索(2006/01/01 00:00:01)
・レコード移動機能がテーブルAのレコード1をテーブルBに移動
もしくは
・レコード移動機能がテーブルAのレコード1をテーブルBに移動
・テーブル照会機能がテーブルAを検索(2006/01/01 00:00:00)
・テーブル照会機能がテーブルBを検索(2006/01/01 00:00:01)
の処理順でなければいけないと思います。

現状の仕組みで、どうしても今の順序を変更できないのであれば、テーブルBの検索の際、テーブルAで検索できる情報は否定条件で除外すべきでしょうね。
マー帽
常連さん
会議室デビュー日: 2006/01/31
投稿数: 21
投稿日時: 2006-06-06 19:50
引用:

mukoubutiさんの書き込み (2006-06-05 15:17) より:

ところでUNIONを使ってテーブルAとテーブルBの検索を1つのSQL文で検索した場合、テーブルAのSELECTとテーブルBのSELECTとの間にテーブルBへのDELETE文は割り込むことができるんでしょうか?
その場合は、検索結果からはデータが欠落する形になるのでしょうか?


DELETE文が割り込むかどうかは分からないのですが、(割り込まないとは思うのですが)
1点気になる部分があります。

テーブルAからテーブルBへの移動の処理順ですが、下記の様になっているという事ですよね?

1.テーブルAからDELETEする。
2.テーブルBにINSERTする。

この順序だとDELETEとINSERTの間に他のSELECTが割り込むのかどうかも
考えなければならないと思いますし、出来れば下記の順序が望ましいのではないでしょうか?

1.テーブルAをロックする。SELECT 〜 FROM テーブルA WITH(UPDLOCK)
2.テーブルBにINSERTする。
3.テーブルAからDELETEする。

トランザクションの分離レベルにもよりますが...
#「Database Expert 会議室」向けになってしまいました。


[ メッセージ編集済み 編集者: マー帽 編集日時 2006-06-06 19:52 ]
Jitta
ぬし
会議室デビュー日: 2002/07/05
投稿数: 6267
お住まい・勤務地: 兵庫県・海手
投稿日時: 2006-06-06 22:29
引用:

JIMMYさんの書き込み(2006-06-05 15:49)より:

・テーブル照会機能がテーブルAを検索(2006/01/01 00:00:00)
・テーブル照会機能がテーブルBを検索(2006/01/01 00:00:01)
・レコード移動機能がテーブルAのレコード1をテーブルBに移動
もしくは
・レコード移動機能がテーブルAのレコード1をテーブルBに移動
・テーブル照会機能がテーブルAを検索(2006/01/01 00:00:00)
・テーブル照会機能がテーブルBを検索(2006/01/01 00:00:01)
の処理順でなければいけないと思います。


 Java僧さんがおっしゃるように、『テーブル照会機能が2つのトランザクションになってしまっている』からでしょう。
 2回の検索が1つのトランザクションで、分離レベルがダーティデータ読み出し可能になっていれば、照会機能はダーティデータを読み出して、「レコード1」は1回しか現れないでしょう。

 照会機能と移動機能は『別スレッド』ということですから、あるいは別々のユーザが処理を行っているのかもしれません。


 ただ問題は、mukoubutiさんって、今まで完了のフィードバックがないのよね。
fight
ベテラン
会議室デビュー日: 2005/09/25
投稿数: 74
投稿日時: 2006-06-07 11:02
[quote]
Jittaさんの書き込み (2006-06-06 22:29) より:
引用:

JIMMYさんの書き込み(2006-06-05 15:49)より:

・テーブル照会機能がテーブルAを検索(2006/01/01 00:00:00)
・テーブル照会機能がテーブルBを検索(2006/01/01 00:00:01)
・レコード移動機能がテーブルAのレコード1をテーブルBに移動
もしくは
・レコード移動機能がテーブルAのレコード1をテーブルBに移動
・テーブル照会機能がテーブルAを検索(2006/01/01 00:00:00)
・テーブル照会機能がテーブルBを検索(2006/01/01 00:00:01)
の処理順でなければいけないと思います。


> Java僧さんがおっしゃるように、『テーブル照会機能が2つのトランザクションになってしまっている』からでしょう。
→SELECT文なのでトランザクション(begin transaction commit transaction)は使っていません。

> 2回の検索が1つのトランザクションで、分離レベルがダーティデータ読み出し可能になっていれば、照会機能はダーティデータを読み出して、「レコード1」は1回しか>現れないでしょう。
→仕様上ダーティーリード不可です。

> 照会機能と移動機能は『別スレッド』ということですから、あるいは別々のユーザが処理を行っているのかもしれません。
→別々のユーザです。

> ただ問題は、mukoubutiさんって、今まで完了のフィードバックがないのよね。
→すいませんでした。ご指摘ありがとうございます。今までの質問に対し完了のフィードバックを投稿しました。

スキルアップ/キャリアアップ(JOB@IT)