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

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

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

**デフォルトの名無しさん** · 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