HOME»データベーススペシャリスト掲示板»R2 午後Ⅰ 問2 設問3 (3)
投稿する
まず、空席フラグ、空席フラグ、仮予約フラグ(オフ)などのレプリカデータが用意されます。
次に、購入処理の際には、図5に従って、仮予約フラグのオン、オフ。イベント型に変更したので購入処理が終了してから、レプリカデータに反映します。その時点で仮予約フラグはオフ。
結局、レプリカデータの仮予約フラグはずっとオフなので、オフをオフに更新する処理は省略出来ます。
空席フラグがないと、座席番号ごとの空席状況が確認できません。図3、図4は席種(S席など)ごとの空席状況です。
そもそも、他トランザクションなどから見た時に仮予約フラグがずっとオフなら、このフラグ自体意味がなくなってしまうと思うので、フラグ立てた時点でコミットしないと意味がないと思うんですよね。
自分も正直断言はできないのですが、上記解釈をしました。
ただ、空席状況の一覧表示で、仮予約している状態で決済処理中のものを表示しないようにするかどうかは仕様の話でその辺りの仕様が問題に明記されていないので何とも言えないのですが、実運用では決済処理中のものが一覧に表示されるのはユーザーが買おうとして決済でエラーになる確率が上がってしまうと思うので、あまり良くないかなぁと思いました。（実運用的には、仮予約フラグが立ってるデータは一覧には表示しない方が良い）
仮予約中まで考慮されていたらありがたいけど、人気チケットを捌くのは大変になるのかしら。
何はともあれ視野が広がりました。教えて頂き、ありがとうございました。
[0523] R2 午後Ⅰ 問2 設問3 (3)
SHIKIさん(No.1)
席種在庫テーブルと座席状況テーブルがイベント型レプリケーションの対象であることが分かった上で...そのレプリケーション対象の列を答える問題ですが、
・席種在庫 - 空席数
・座席状況 - 空席フラグ
ときて、
・座席状況 - 仮予約フラグ
が解答にならないのはどうしてでしょうか？
こちらも購入処理の際に更新する列ですので、対象だと思ってしまいました。
あくまで連携先システムの表示に使用する情報をリアルタイム反映するのが目的だからでしょうか。
もしそうである場合、
表示に使用する情報、というのは特に明示されていないため、
図3のチケット情報一覧を流用すると考えるのが妥当な気がするのですが、
図4の通り、こちらには空席フラグを利用していないため、
今度は空席フラグの方が不要（空席数のみでOK）なのでは？と疑問に思ってしまいます。
皆様はいかがお考えでしょうか。
勘違い等ありそうであればご教示いただけますと幸いです。
・席種在庫 - 空席数
・座席状況 - 空席フラグ
ときて、
・座席状況 - 仮予約フラグ
が解答にならないのはどうしてでしょうか？
こちらも購入処理の際に更新する列ですので、対象だと思ってしまいました。
あくまで連携先システムの表示に使用する情報をリアルタイム反映するのが目的だからでしょうか。
もしそうである場合、
表示に使用する情報、というのは特に明示されていないため、
図3のチケット情報一覧を流用すると考えるのが妥当な気がするのですが、
図4の通り、こちらには空席フラグを利用していないため、
今度は空席フラグの方が不要（空席数のみでOK）なのでは？と疑問に思ってしまいます。
皆様はいかがお考えでしょうか。
勘違い等ありそうであればご教示いただけますと幸いです。
2023.08.18 16:32
logres_fanさん(No.2)
★DB ブロンズマイスター
> 座席状況 - 仮予約フラグが解答にならないのはどうしてでしょうか？
まず、空席フラグ、空席フラグ、仮予約フラグ(オフ)などのレプリカデータが用意されます。
> こちらも購入処理の際に更新する列ですので、
次に、購入処理の際には、図5に従って、仮予約フラグのオン、オフ。イベント型に変更したので購入処理が終了してから、レプリカデータに反映します。その時点で仮予約フラグはオフ。
結局、レプリカデータの仮予約フラグはずっとオフなので、オフをオフに更新する処理は省略出来ます。
> 図3…図4の通り、こちらには空席フラグを利用していないため、
空席フラグがないと、座席番号ごとの空席状況が確認できません。図3、図4は席種(S席など)ごとの空席状況です。
2023.08.18 18:36
SHIKIさん(No.3)
ご回答ありがとうございます。
そういうことでしたか...
レプリケーション機能の仕様に、イベント型は「レプリケーション元のトランザクションと同期してデータを反映」と書いてありますね。
おっしゃる通り、購入前の空席情報を見る段階で必要な情報ですね。
図3-4に固執して視野が狭くなっていました...。
ありがとうございます。
もっと仕様と実際の処理の流れを読み取れるよう努力したいと思います。
> 結局、レプリカデータの仮予約フラグはずっとオフ
そういうことでしたか...
レプリケーション機能の仕様に、イベント型は「レプリケーション元のトランザクションと同期してデータを反映」と書いてありますね。
> 空席フラグがないと、座席番号ごとの空席状況が確認できません。図3、図4は席種(S席など)ごとの空席状況です。
おっしゃる通り、購入前の空席情報を見る段階で必要な情報ですね。
図3-4に固執して視野が狭くなっていました...。
ありがとうございます。
もっと仕様と実際の処理の流れを読み取れるよう努力したいと思います。
2023.08.18 20:02
awesamさん(No.4)
横から失礼します。
イベント型は、レプリケーション元のトランザクションも同期してデータを反映するもので、仮予約フラグを立てるトランザクションはフラグを立てた後にコミットしてるので、レプリケーションさせる場合はオンという状態もレプリケーションされると思うのですが、認識に誤りがありますでしょうか？
表2の対策で、1座席ごとにコミットするように変更した際に、そのあたりの処理も変更したという感じなのでしょうか？
イベント型は、レプリケーション元のトランザクションも同期してデータを反映するもので、仮予約フラグを立てるトランザクションはフラグを立てた後にコミットしてるので、レプリケーションさせる場合はオンという状態もレプリケーションされると思うのですが、認識に誤りがありますでしょうか？
表2の対策で、1座席ごとにコミットするように変更した際に、そのあたりの処理も変更したという感じなのでしょうか？
2023.08.20 11:24
awesamさん(No.5)
> 結局、レプリカデータの仮予約フラグはずっとオフなので、オフをオフに更新する処理は省略出来ます。
そもそも、他トランザクションなどから見た時に仮予約フラグがずっとオフなら、このフラグ自体意味がなくなってしまうと思うので、フラグ立てた時点でコミットしないと意味がないと思うんですよね。
2023.08.20 17:41
logres_fanさん(No.6)
★DB ブロンズマイスター
その通りですね、ご指摘ありがとうございます。
トランザクションログをデコードしてSQLストリームを流して応答が返ってきたらコミットする、これをコミットごとに都度実行。複製対象に設定したカラムが反映される。仮予約フラグは、単に空席状況確認に不要だから外れる。
正しくは、このような回答でしょうか。間違えがあれば、教えて下さい。
トランザクションログをデコードしてSQLストリームを流して応答が返ってきたらコミットする、これをコミットごとに都度実行。複製対象に設定したカラムが反映される。仮予約フラグは、単に空席状況確認に不要だから外れる。
正しくは、このような回答でしょうか。間違えがあれば、教えて下さい。
2023.08.21 01:39
awesamさん(No.7)
> 仮予約フラグは、単に空席状況確認に不要だから外れる。
自分も正直断言はできないのですが、上記解釈をしました。
ただ、空席状況の一覧表示で、仮予約している状態で決済処理中のものを表示しないようにするかどうかは仕様の話でその辺りの仕様が問題に明記されていないので何とも言えないのですが、実運用では決済処理中のものが一覧に表示されるのはユーザーが買おうとして決済でエラーになる確率が上がってしまうと思うので、あまり良くないかなぁと思いました。（実運用的には、仮予約フラグが立ってるデータは一覧には表示しない方が良い）
2023.08.21 11:17
awesamさん(No.8)
この投稿は投稿者により削除されました。(2023.08.21 12:55)
2023.08.21 12:55
awesamさん(No.9)
元々一覧には空席が無くても表示する仕様なので、正確には仮予約フラグを考慮した上で空席数がない場合は空席情報を×表示にするという運用が本来はいいのではと思いました。
ただその場合、実際は席種在庫に確保数みたいなカラムを追加して仮予約中の総数を管理する形にした方がパフォーマンス的に良いかなぁと思いました。
ただその場合、実際は席種在庫に確保数みたいなカラムを追加して仮予約中の総数を管理する形にした方がパフォーマンス的に良いかなぁと思いました。
2023.08.21 12:55
logres_fanさん(No.10)
★DB ブロンズマイスター
>No.7
>No.9
仮予約中まで考慮されていたらありがたいけど、人気チケットを捌くのは大変になるのかしら。
何はともあれ視野が広がりました。教えて頂き、ありがとうございました。
2023.08.22 00:57