データリーダーがより優れているか、またはデータのセットが同時実行性の問題がある可能性があります

Question

私はデータリーダーとデータセットの違いを知っています。

DataReaderは、最適化された読み取り専用、高速および転送専用のデータアクセスが必要なアプリケーションに適しています。

データセットは、アプリケーションレベルで必要に応じてすべてのデータを取得して更新し、データベースに変更を送信することができます。

私の理解に間違いがないかどうかを確認してください。

今私はインタビューをしている人が私に尋ねた。データウェアハウスや接続アーキテクチャは、チケット発行システムのようなアプリケーションに適していますか？基本的には、多くのユーザーが同じテーブルを更新しようとしていた可能性があります。したがって、並行性の概念が現れます。

Disconnectedアーキテクチャを使用すると、並行性をチェックして、一度に1人のユーザーしかテーブルを更新できません。しかし、それは接続されたアーキテクチャの面でどのように起こるか知りません。データベースへの接続、特に関連テーブルへの接続は、1人のユーザーのみが更新を行うようにしますが、後でヒットしようとするユーザーは更新できません。

データベースがボトルネックに達すると、すべてのユーザーが接続を開いてもパフォーマンスには影響しません。

私はそれらを理解する答えを得ることを望む。

Answer 1

データがクライアントに到達してから既に古い/無効であるため、どちらの方が良いかは問題ではないと思います。予約の表を表示すると、予約の内容を大まかに把握するのに便利ですが、次の1秒以内に完全に異なる可能性があります。競合状態を解消したい。まずは良い建築が必要です。

これを行う1つの方法は、チケット[1]を '予約'することです。アプリケーションは、一致した基準で利用可能なチケットを取得するように求めます。この時点で、チケットが利用可能かどうかに関する既知の事実。それが利用可能であった場合、すでに予約されていました。これにより、1つのチケットに対する複数の予約が回避されます。次の予約（同じ操作/アクション）により、異なるチケットが予約されます。必要に応じて、このチケットに情報を後から追加することができます（チケットの所有者や情報など）。情報が添付されていないチケットは、一定の時間が経過するとタイムアウトし、プールに戻ります。これらのチケットは再び予約することができます[1]。

[1]複数の割り当てを避けるには、optimistic lockingを使用してください。

質問に答えるために、私はDataReaderと答えます。データベースの通信を最小限に抑える（ロードとロック）ので、できるだけ早く更新を処理できます。 1つずつ別のものを選ぶことは並行性の問題を解決しません。それは重要なトータルソリューションです。

例

私は要件を知りませんが、それは面接の質問ですので、私は例をあげます。これをゴールデンルールとして取ってはいけませんが、私の頭の先端からは次のようなものになります：

（必要な場合）最初に、ユーザーにはチケットが残っている可能性のある画面が表示されます予約済み。接続を開き、リーダで予約可能なチケットの金額を読んでください。リーダーと接続を閉じます。ユーザーは次の画面に進みます。

SELECT COUNT(*) 
FROM [Tickets] 
WHERE ([LastReserved] IS NULL OR [LastReserved] <= DATEADD(MINUTE, GETDATE(), @ticketTimeout)) 
    AND [TickedAssignedToUserId] IS NULL; 

ユーザーはx個のチケットを要求し、次の画面に進みます。現時点では、利用可能なチケットが十分にある場合、システムは楽観的ロックをチェックします。影響を受けた行数が@numberOfTicketsRequestedと同じである必要があります

UPDATE TOP(@numberOfTicketsRequested) [Tickets] 
SET [LastReserved]=GETDATE() 
WHERE ([LastReserved] IS NULL OR [LastReserved] <= DATEADD(MINUTE, GETDATE(), @ticketTimeout)) 
    AND [TickedAssignedToUserId] IS NULL; 

：単純に（！トランザクションとの）接続を開き、次のクエリを実行します。このような場合は、トランザクションをコミットしてチケット識別子を取得します。それ以外の場合はロールバックし、利用可能なチケットがないことをユーザーに伝えます。この時点では、レコード情報が必要なので、識別子も取得することをお勧めします。

この時点で、ユーザは、ユーザの詳細を入力するのに、@ticketTimeout分を取得します。正しく行わ場合は、次のクエリを実行することができます

UPDATE TOP(@numberOfTicketsRequested) [Tickets] 
SET [TickedAssignedToUserId]=@userId 
WHERE [TicketId]=@Id AND [LastReserved]=@lastReserved AND [TickedAssignedToUserId] IS NULL; 

ユーザーが10分を言う、より長くかかり、他の誰かが再び同じチケットを要求し、その後、LastReservedタイムスタンプが変更された場合。最初のユーザーがチケットの詳細を予約しようとしたとき、アップデートはもともとのLastReservedタイムスタンプと一致せず、アップデートでは影響を受ける行（ロールバック）が不十分であると表示されます。影響を受けた行の数と一致する場合、ユーザーはチケットを正常に予約しました（=コミット）。

チケット識別子以外のチケット情報がアプリケーションに到達していないことに注意してください。私はユーザー登録も含んでいません。完全なテーブルは渡されず、ロックは最小限しか使用されていません（2回の短い更新）。