データベースプログラミング全般スレ

**デフォルトの名無しさん** · NG

データベース板もあるが、あそこは過疎板だからこっちに立てました。
データベース関連のプログラミングならな～んでもOK。
色んな話をしませまうる号。

**デフォルトの名無しさん** · 2016/09/02(金) 11:22:48.43

>>492
なんか話が変わってきているが、>>469に沿って言えば、Z.Xにユニーク制約を付けるのが「普通」。
あと、トランザクションの大小は関係ない。
3msで終了する「存在チェック→insert」というトランザクションでも、複数人が実行するのなら競合する可能性はある。

**デフォルトの名無しさん** · 2016/09/02(金) 22:39:01.72

>>492
トランザクションを勉強するのはいいが、ロックのことは一旦忘れた方がいい。理解の妨げになる。
明示的にロックを「使う」なんて言うのはトランザクション分離レベルを理解できなかったジジイのやること。

**デフォルトの名無しさん** · 2016/09/05(月) 11:48:06.49

トランザクション分離レベルのことがわかっていると、今回のケースでテーブルロックを使わなくてもいいってことか？

**デフォルトの名無しさん** · 2016/09/05(月) 20:21:03.85

今回のケースに限らず、基本的にロックなんて使う必要ない。そもそも標準SQLにロックなんてないしな。
必要があるとすれば、SQL92のトランザクション対応してない古いシステムでどうしてもやらないと
ならない場合とか、全部わかってる人があえて標準じゃできない使い方をする場合くらい。

**デフォルトの名無しさん** · 2016/09/06(火) 03:41:01.52

>>494-495
ロックってのは基本的には分離レベルに応じてDBMSが勝手にやってくれる
今回の例ならSERIALIZABLEでトランザクション流せば良いだけ

理想は分離レベルの指定だけで済ますことなんだが
現実的には、どの分離レベルでどういうSQL流したらどういうロックが獲得されるかはちゃんと理解しとかないと
パフォーマンス的な問題がでるかもしれんがな

**デフォルトの名無しさん** · 2016/09/06(火) 07:48:18.17

>理想は分離レベルの指定だけで済ますことなんだが
>現実的には、どの分離レベルでどういうSQL流したらどういうロックが獲得されるかはちゃんと理解しとかないと

それは別に相反する話じゃないが。

**デフォルトの名無しさん** · 2016/09/06(火) 11:27:23.34

>>497
> 今回の例ならSERIALIZABLEでトランザクション流せば良いだけ
同じテーブルに同時に別のデータをINSERTすることがないという限定条件付きだけどな。

普通は、同じテーブルに同時に別のデータをINSERTすることもあるし、同時に同じデータをINSERTすることもある。
で、同時に同じデータをINSERTされないようにするには、普通はunique制限を付ける。
なんらかの理由でunique制限を付けられない場合は、論理的にはテーブルをロックするしかない。

その「テーブルをロックする」というのが、MySQLで上の限定条件に限り、目的と合致するというだけの話。

**デフォルトの名無しさん** · 2016/09/06(火) 20:19:05.08

>>499
お前の言う限定条件ってのは理解できない
だれかに言われてたけど、トランザクションは常に失敗の可能性があるってことすら理解してないのか？
あるいは同時実行されるトランザクションが複数あれば、ロック待ちが発生する可能性があるって事が理解できない？
>>論理的にはテーブルをロックするしかない
だから、SERIALIZABLEなトランザクションってのは必要ならそう言う動作するわけだが
MySQLどうこうじゃなくて、SERIALIZABLEを正しく実装してる全てのDBMSで正しく動作するけど？

MySQLがトランザクションとSERIALIZABLE分離レベルを正しく実装してるかどうかはしらん

**デフォルトの名無しさん** · 2016/09/06(火) 20:56:58.82

ロックロック言う奴はやっぱりトランザクション分離レベルが理解できてないという好例>>499

**デフォルトの名無しさん** · 2016/09/07(水) 03:06:30.86

>>477がちょっと気になったんだが
本当に先行トランザクションのuser1のinsertがブロックされたり
user2が(ロックタイムアウトじゃなくて)デッドロックで落ちたりするのか？

それがホントなら誰かMySqlのャ鴻bク周りにつｂ｢て詳しい解説ャTイト教えてくｂ

**デフォルャgの名無しさん** · 2016/09/07(水) 03:09:09.50

うは、なんか文字化けしとる
MySqlのロック周りについて詳しい解説サイト教えてくれ
と書いたんだが、さて

**デフォルトの名無しさん** · 2016/09/07(水) 10:18:08.32

>>500
まず、俺がトランザクションについて理解していないとか、分離レベルについて理解していないとか、
そういう思い込みを捨てろ。俺に言わせれば、お前の方が理解していないように見えるんだが。

> MySQLどうこうじゃなくて、SERIALIZABLEを正しく実装してる全てのDBMSで正しく動作するけど？
いや、serializableなトランザクションに関する各RDBMSの実装が異なっているというのが前提で、
だからこそ「serializableなトランザクションを使えばうまくいく」という一般論にはならない。
なので、「MySQLならこういう限定条件であればserializableなトランザクションを使えば良い」という
ようにしか言えない。

> >>477がちょっと気になったんだが
> 本当に先行トランザクションのuser1のinsertがブロックされたり
> user2が(ロックタイムアウトじゃなくて)デッドロックで落ちたりするのか？
いやいや、実行結果って書いたじゃん。実際に自分でもやってみたら？

> それがホントなら誰かMySqlのロック周りについて詳しい解説サイト教えてくれ
「mysql serializable」でググった1ページ目には、その「詳しい解説」は見つからなかったのか？

**デフォルトの名無しさん** · 2016/09/07(水) 10:40:31.01

PostgreSQLでもやってみた。

user1: begin transaction isolation level serializable;
user1: select count(*) from t where a=3; -> データがないことを確認できる
user2: set tx_isolation = serializable;
user2: begin transaction isolation level serializable;
user2: select count(*) from t where a=4; -> データがないことを確認できる
user1: insert into t values(3, 300); -> insertは完了する
user2: insert into t values(4, 400); -> insertは完了する
user1: select count(*) from t; -> 1
user2: select count(*) from t; -> 1
user1: commit; -> 成功する
user2: commit; -> エラー発生
> ERROR: トランザクション間で read/write の依存性があったため、アクセスの直列化ができませんでした
> DETAIL: Reason code: Canceled on identification as a pivot, during commit attempt.
> HINT: リトライが行われた場合、このトランザクションは成功するかもしれません

**デフォルトの名無しさん** · 2016/09/07(水) 10:42:56.92

各RDBMSがserializableなトランザクションの実装で保証するのは「ファントムリードがないこと」であって、
それを実現する方法は各RDBMSの実装にまかされている。

**デフォルトの名無しさん** · 2016/09/07(水) 10:43:58.68

訂正：
>>505の
> user2: set tx_isolation = serializable;
は削除し忘れ。

**デフォルトの名無しさん** · 2016/09/07(水) 11:58:09.82

少し解説を加えると、RDBMSはserializableなトランザクション内の文脈を見て成功・失敗を決めているわけではなく、
ただ単にファントムリードが発生しないような実装にしているだけ。

あと、ロックと処理がブロックするというのは別の話。
ファントムリードを防ぐという目的の場合に、read lock対read lockなら処理はブロックしないという実装もありだし、
read lock対read lockでも処理をブロックするという実装もありえる。

またserializableなトランザクションの場合、リトライすればOKな場合がある。
そもそも、トランザクションが重ならなければお互いOKになる場合ね。
そういうケースでは、SQL CODEの内容からリトライ可能かどうかを判定してリトライするという実装が必要。
もちろん1回だけのリトライではまた他のトランザクションと重なる場合があるので、MAX回数を決めてリトライを
続ける必要がある。

そういう面倒くさいことをしてまでも、ファントムリードを防がなければならないケースに限って、トランザクションを
serializableにするというのが正しい使いだと思う。
ユニーク性を担保したいだけだったら、テーブルロックで十分。

**デフォルトの名無しさん** · 2016/09/07(水) 15:28:03.69

テーブルロックは常に成功するとでも思ってるんだろうか

**デフォルトの名無しさん** · 2016/09/07(水) 15:44:40.75

>>509
デッドロックになるようなロックのかけ方すればエラーになるだろうけど、それと今回の話とは関係ないよね。

**デフォルトの名無しさん** · 2016/09/07(水) 19:16:59.25

デッドロックとロックタイムアウトの区別もつかない人か

まあserializableで単独テーブルに対するアクセスでデッドロックするのもどうなんだという感じがしないでもないが
それでも少なくとも2重登録の防止って要件はserializableで満たしてるわけだが

同時実行する他のトランザクションがエラーになるのはダメとか、それは分離レベルが保証することではないし
リトライすればOKな事もあるとか、もはや分離レベル関係ないし

**デフォルトの名無しさん** · 2016/09/07(水) 22:23:54.80

>いや、serializableなトランザクションに関する各RDBMSの実装が異なっているというのが前提で、
>だからこそ「serializableなトランザクションを使えばうまくいく」という一般論にはならない。

この時点で理解してないのは明らか。そもそもSERIALIZABLEは無条件に直列化可能で
あることを保証するものだし。

>各RDBMSがserializableなトランザクションの実装で保証するのは「ファントムリードがないこと」であって、
>それを実現する方法は各RDBMSの実装にまかされている。

ファントムリードが起きない「だけ」なんだが、直列化可能性を保証するにはそれで十分なわけ。
まさか「ファントムリードがない」ってのを、単に他トランザクションで挿入したレコードを
見せないだけとでも思ってるんだろうか。

**デフォルトの名無しさん** · 2016/09/08(木) 10:04:35.37

>>511
もうお前の主張にはなにも興味はないが、mysqlとpostgresqlの実装にたいする感想くらいくれよ。

**デフォルトの名無しさん** · 2016/09/08(木) 10:09:10.39

>>511
> まあserializableで単独テーブルに対するアクセスでデッドロックするのもどうなんだという感じがしないでもないが
あ、これがmysqlの実装に対する感想なのか？
じゃ、もういいや。

**デフォルトの名無しさん** · 2016/09/08(木) 10:14:11.58

最後に一つだけ。
「SERIALIZABLEは無条件に直列化可能であることを保証するもの」の意味が全然わからんが、
ユニーク性を担保するためには、同時に実行される可能性があるトランザクションを「直列化」する
必要があり、それにはテーブルロックを使うのが最も簡単。

これに反論がある場合に限ってレスしてくれ。

**デフォルトの名無しさん** · 2016/09/08(木) 11:18:11.85

>>515への直接のレスがなければ、これでserializable話は終了します。
いい加減うざいだろうし。

「serializableなトランザクションとは何か」は、以下のスライドが俺が見つけた範囲だと一番わかりやすいと思う（それでもわかりづらいんだが）。
『トランザクションをSerializableにする4つの方法』
http://www.slideshare.net/kumagi/serializable4-56309007

**デフォルトの名無しさん** · 2016/09/08(木) 21:47:43.84

「SERIALIZABLEじゃ無理」→「問題がある」→「ロックの方が簡単」

なんだかなぁｗ
普通はトランザクション開始時に隔離レベルを1行指定する方がいちいちテーブルを指定して
ロックをかけるより簡単だと思うんだが。

「(今からトランザクションを理解するより)ロックの方が簡単」という個人的事情なのかね？

**デフォルトの名無しさん** · 2016/09/09(金) 03:27:30.69

>>517
ロックの詳細や問題点を正確に把握できてないんじゃないの

>serializableなトランザクションの場合、リトライすればOKな場合がある
>そういう面倒くさいことをしてまでも、ファントムリードを防がなければならないケースに限って、トランザクションを
> serializableにするというのが正しい使いだと思う。
と、あたかも自分でテーブルロックすれば他のトランザクションやリトライ系については考慮いらないかのようなこと言ってるし

>テーブルロックは常に成功するとでも思ってるんだろうか
っていう突っ込みに対して
>デッドロックになるようなロックのかけ方すればエラーになるだろうけど
って回答してるし
>デッドロックとロックタイムアウトの区別もつかない人か
についてはまともな反論してないからな

デッドロック以外にロックでエラーは出ないと思ってるんだろ

**デフォルトの名無しさん** · 2016/09/24(土) 11:55:19.93

再利用性の高いクエリの書き方を教えてください

**デフォルトの名無しさん** · 2016/12/04(日) 21:38:58.08

Oracleってdomain使えないん？

**デフォルトの名無しさん** · 2016/12/06(火) 22:37:42.39

今どきRDBMSとかダサすぎ。

**デフォルトの名無しさん** · 2016/12/15(木) 15:36:13.98

https://chrome.google.com/webstore/detail/%E3%81%AF%E3%81%A6%E3%81%AAng/mbgdnfmdelffjdhkdggilmphfdihnmcj?hl=ja