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

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

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

**デフォルトの名無しさん** · 2016/01/20(水) 16:37:02.67

データベース板にMSSQLスレあるよ

**デフォルトの名無しさん** · 2016/01/20(水) 19:46:17.26

>>430
どのユーザーでどのユーザー

**デフォルトの名無しさん** · 2016/02/01(月) 00:25:24.43

検索の仕方が悪いのか、データベースのデータから特定のx行y列目の値を一つの変数へ格納する方法が見つからない…

コマンドプロンプト上で検索するやり方は特定の行または列だけ。
excelなら行と列を指定すればそのセルの値を取得できるが、他の面で不便だ

SQliteなんだが、特定のx行y列目の値を一つの変数へ格納する方法が知りたい

**デフォルトの名無しさん** · 2016/02/01(月) 05:21:16.21

>>433
変数って何の変数だよ？

**デフォルトの名無しさん** · 2016/02/01(月) 06:09:47.86

データベースに行数列数なんて概念あんの？

**デフォルトの名無しさん** · 2016/02/01(月) 06:19:13.75

>>435
はあ？

RDBは行列の2次元の表が基本だぞ。

**デフォルトの名無しさん** · 2016/02/01(月) 06:21:27.24

>>433
RDBには行の順番というものはないぞ。

**デフォルトの名無しさん** · 2016/02/01(月) 09:24:33.50

SELECT 文に ORDER BY をつけてようやく順番が決まった表みたいなものになる
数十万、数百万件もあるかもしれないデータをいきなり何行目とか指定できない
順番にfetchするとかカーソル使うとか、、、特定の何番目かの行だけ取り出したければ
LIMIT OFFSET使うとか

**デフォルトの名無しさん** · 2016/02/01(月) 09:32:31.63

>>434
>>437
行"数"は無いのか…。

多くのサイトの説明だと

「select カラム from テーブル where 条件」で抽出できる、みたいに書いてある。
けれど抽出したデータを任意に作った変数にどう取り込むのか、までは載ってないんだ…

変数っていうのは、ゲームの例で言えば、
特定のモンスターの能力値を読み込むときに、モンスターに振り分けたIDなりでデータベースを検索して、
攻撃力・守備力・魔法力の数値が全部載ってる行を見つける

けれど、そのまとまった情報をゲーム上のステータスにどう反映すればいいのかがわからない。
攻撃力を表す変数Xに攻撃力の数値を入れたいんだよね。

**デフォルトの名無しさん** · 2016/02/01(月) 13:22:29.13

レコードを特定して列指定で格納値を取得
さらに列の型に応じてゴニョゴニョする…とこの辺がわかってないのか

C/C++ じゃなくて VBとかスクリプトだと余計なこと考えなくていいんだけど
多分ダメなんだろうな

【末吉】 · 2016/02/01(月) 15:01:28.17

>>433
>「select カラム from テーブル where 条件」で抽出できる、みたいに書いてある。
>けれど抽出したデータを任意に作った変数にどう取り込むのか、までは載ってないんだ…

change your mind
わからなければORMでも使えばいい

**デフォルトの名無しさん** · 2016/02/01(月) 19:01:11.15

みんなのくれるヒントをもとに検索かけてるんだがやっぱりだめだ……

>>441
ORMというものの説明をさっくり見ても理解できなかった。すまん

>>440
VB.netのほうが取っつきやすいから、そっちのほうで良い方法を載せてるサイトを知らないか？

**デフォルトの名無しさん** · 2016/02/02(火) 00:31:00.26

>>442
サブクエリで検索したまえ

**デフォルトの名無しさん** · 2016/02/02(火) 01:49:46.31

日を跨いですまん

>>443
これはわかりやすくて使いやすいな。
ただ最も知りたいのは、ここから自分の作った変数へ当て嵌める方法でな…。

たとえば ttp://www.dbonline.jp/mysql/select/index20.htmlの例を使うなら、
サブクエリを使って求めた行のうちのname"～"の値を、適当な変数Xに入れて X = "～" としたいんだ。

**デフォルトの名無しさん** · 2016/02/02(火) 02:12:05.74

>>442
VB.NETつかうんならADO.NET使えば？

**デフォルトの名無しさん** · 2016/02/02(火) 08:19:43.05

変数ってホストの話か？お前らよく付き合うな。言語も環境もなんも書いてないのに。

**デフォルトの名無しさん** · 2016/02/02(火) 14:44:58.86

馬鹿には無理

**デフォルトの名無しさん** · 2016/02/04(木) 18:31:06.37

住所氏名電話番号とかいろんなデータに、どんなデータ型が最適かまとめられたリストってありませんか？

**デフォルトの名無しさん** · 2016/02/04(木) 18:57:06.90

ありますよ

**デフォルトの名無しさん** · 2016/02/04(木) 20:43:57.05

安心してください

**デフォルトの名無しさん** · 2016/02/04(木) 21:27:28.08

>>448
全部VARCHAR

**デフォルトの名無しさん** · 2016/02/04(木) 23:38:59.91

ipaが共通語彙基盤とかいうのやってるね

**デフォルトの名無しさん** · 2016/02/05(金) 07:24:45.41

何それ不安しかない

**デフォルトの名無しさん** · 2016/02/16(火) 22:06:45.67

質問なんですが、
accessはもちろんofficeすらインストールしていないpcで、
vs2015から、mdbファイルを利用できます
またaccessをデータセットとして利用できます
これ何ででしょうか？
もしかしてvs2015には、もれなくaccessもついてくるのかな？
当方、日曜プログラマです
上記は、JRAVAN,datalab競馬ソフト開発体験教室レッスン7を実行した結果です
http://jra-van.jp/dlb/sdv/trial.html

**454** · 2016/02/16(火) 22:15:23.66

いや、日曜プログラマだと語弊があるかもしれない
日曜日に趣味で勉強しているおっさんです
プログラマではないです

**デフォルトの名無しさん** · 2016/02/17(水) 00:01:04.23

accessという製品はタダでは付いてきません
mdbにアクセスするためのプロバイダはoffice無しでも利用できます

**デフォルトの名無しさん** · 2016/02/17(水) 00:57:40.92

>>456
レスども
やっぱりaccessはないわけですか
あれ有料ですもんね
ありがとうございました

**デフォルトの名無しさん** · 2016/02/17(水) 07:18:01.15

LibreOffice を使えば？

**デフォルトの名無しさん** · 2016/02/17(水) 13:21:34.95

>>458
accessとbaseの互換性がいまいちわからないんですよね
mdbファイルは開けるけど
現状dbはほぼ未経験、accessもbaseも未経験
adoの勉強始めたとこですね
選択肢の1つとして考えときます
ありがとうございます

**デフォルトの名無しさん** · 2016/02/17(水) 22:15:55.38

libreOfficeっていけてるデータプロバイダあんの？

**デフォルトの名無しさん** · 2016/02/18(木) 12:58:46.87

>>454
テーブルで RDB したいだけだったら Access は不要

**デフォルトの名無しさん** · 2016/02/18(木) 13:00:40.69

>>460
libreOffice から mdb にリンクするのが吉

**454** · 2016/02/19(金) 22:28:46.73

>>461
そうみたいですね
Accessは入ってるけど、機能制限がかかってる感じなのかな

**デフォルトの名無しさん** · 2016/02/21(日) 10:39:25.91

>>463
Accessは入ってない

**デフォルトの名無しさん** · 2016/02/26(金) 19:25:15.74

Access2016のダウンロード版のダウンロードサイズが1kbということは、
機能はwindowsに入ってんのかね？1kbはライセンスだけだよな

**デフォルトの名無しさん** · 2016/02/26(金) 21:13:28.84

再配布用のランタイムだけでも300MBくらいあるべ
https://www.microsoft.com/en-us/download/details.aspx?id=50040

**デフォルトの名無しさん** · 2016/02/26(金) 21:30:46.59

>>465
Webインストーラーでしょ

**デフォルトの名無しさん** · 2016/03/03(木) 17:58:33.89

このスレ12年も存在し続けてるのかw

**デフォルトの名無しさん** · 2016/08/25(木) 16:35:33.34

質問失礼します。

以下の順番でレコードの重複回避処理を行っています。

① A.php で Z テーブルの X カラムの値が 49 のレコードを select してレコードの存在チェックを行う。

② ①で存在しなければ、A.php で Z テーブルの X カラムの値が 49 のレコードを insert する。

今日、上司から②で insert している最中に他の A.php が走り、

２回レコードが insert されてしまう（つまりレコードが重複してしまう）可能性があるんじゃないの？って聞かれました。

そういう事は考えられるのでしょうか？

またそれを回避するにはどういう SQL 文（トランザクションでしょうか？）を書いたら良いのでしょうか？

分かる方、よろしくお願いします。

**469** · 2016/08/25(木) 16:41:17.60

すいません。
開発環境を忘れてました。
php7.0.6
MySQL5.6
よろしくお願いします。

**469** · 2016/08/25(木) 16:46:28.67

すいません。また補足です。

Z テーブルの X カラムにユニーク属性は付けていません。

他にもカラムがあって設計上付けないことになっています。

**デフォルトの名無しさん** · 2016/08/25(木) 16:48:36.83

>>469
> そういう事は考えられるのでしょうか？
考えられる。

> またそれを回避するにはどういう SQL 文（トランザクションでしょうか？）を書いたら良いのでしょうか？
Z.Xにユニーク制約をつけるのが一番簡単。

**デフォルトの名無しさん** · 2016/08/25(木) 16:52:28.51

>>471
> Z テーブルの X カラムにユニーク属性は付けていません。
そうなんだ。
じゃ最適解はわからない。テーブルロックか？

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

①と②をSerializableなトランザクションでやればいい。

**デフォルトの名無しさん** · 2016/08/26(金) 15:10:39.88

>>474
それでは無理

**デフォルトの名無しさん** · 2016/08/26(金) 20:31:32.61

できるだろ。
SERIALIZABLEの意味わかってるか？

**デフォルトの名無しさん** · 2016/08/29(月) 14:33:26.91

>>476
こういうケースで問題がある。

table t: (a integer, b integer)
user1がa=3のレコードを、user2がa=4のレコードを同時に作成しようとする。
本来なら、別のデータを登録する処理なので、両立すべき。

user1: set tx_isolation = serializable;
user1: begin;
user1: select count(*) from t where a=3; -> データがないことを確認できる
user2: set tx_isolation = serializable;
user2: begin;
user2: select count(*) from t where a=4; -> データがないことを確認できる
user1: insert into t values(3, 300); -> 処理がブロックする
user2: insert into t values(4, 400); -> エラー発生(Deadlock found)、user1のブロック解除
user2: rollback;
user1: commit;

結果として、user2はデータを登録できない。

**デフォルトの名無しさん** · 2016/08/29(月) 22:22:51.33

>>469の要件は満たしてるのに、

>本来なら、別のデータを登録する処理なので、両立すべき。

なんでこういう条件を勝手に追加するんだか。

しかも、それぞれのトランザクション分離レベルで守らなければならないことと
実装に任されていることとの区別もついていないようだ。

>user2: select count(*) from t where a=4; -> データがないことを確認できる

ここでuser2をブロックあるいは失敗させてuser1を成功させてもSERIALIZABLEの
要件は満たすし、仮にここでブロックする実装なら

>user2: insert into t values(4, 400); -> エラー発生(Deadlock found)、user1のブロック解除

これをエラーにする必要もないんだが。

**デフォルトの名無しさん** · 2016/08/30(火) 10:23:03.89

>>478
> なんでこういう条件を勝手に追加するんだか。
別に勝手に追加したわけじゃなくて、>>477は普通の正常系の話。
複数人が別々のデータを同時に登録するなら、それは成功してしかるべき。

> これをエラーにする必要もないんだが。
なにか勘違いしてるようだけど、>>478は、
・お互い分離レベルがserializableなtransactionにする
・処理は、「存在確認」→「なければinsert」という処理
を普通に行う実装で、「->」以降はそれを実行した結果。

> >user2: select count(*) from t where a=4; -> データがないことを確認できる
> ここでuser2をブロックあるいは失敗させてuser1を成功させてもSERIALIZABLEの
> 要件は満たすし
serializableの要件を満たすことが目的ではないし、普通に実装すればuser2はブロックしないし
失敗もしない。

> >user2: insert into t values(4, 400); -> エラー発生(Deadlock found)、user1のブロック解除
> これをエラーにする必要もないんだが。
どういう意味？
エラーにするんじゃなくて、エラーが発生するんだけど。

**デフォルトの名無しさん** · 2016/08/30(火) 10:26:02.84

というか、クライアントを二つ立ち上げて、>>477を実査にやってみれば、俺が言ってることを納得できると思う。

**デフォルトの名無しさん** · 2016/08/30(火) 22:41:53.12

>別に勝手に追加したわけじゃなくて、>>477は普通の正常系の話。
>複数人が別々のデータを同時に登録するなら、それは成功してしかるべき。

そもそもトランザクションは常に失敗の可能性があるってことすら理解してないのか。
>>469はそんなもの問題として挙げてないし、これが実際に問題となるかどうかはもう少し
具体的にアクセス規模や性能要件なんかを出して議論するものだ。

>serializableの要件を満たすことが目的ではないし、普通に実装すればuser2はブロックしないし
>失敗もしない。
>エラーにするんじゃなくて、エラーが発生するんだけど。

>>478に書いた「実装」ってのはDBMSの実装のことな。
SERIALIZABLEの要件を満たすのもエラーを出すのもDBMS側の仕事。
極端な話、

>user1: select count(*) from t where a=3; -> データがないことを確認できる

安直なDBMならここでtにテーブル排他ロックをかけるかもしれない。それでも規格準拠だ。
それを踏まえてもういちど>>478を読み返してみな。

>というか、クライアントを二つ立ち上げて、>>477を実査にやってみれば、俺が言ってることを納得できると思う。

>>478と同じことを書くけど、おまえさんはSQL標準で規定されたトランザクションの仕様と
個々のDBMSの実装の区別がついていない。

**デフォルトの名無しさん** · 2016/08/31(水) 10:08:49.24

>>481
あ、MySQL前提じゃなかったんだね。
じゃ話があわない。

**デフォルトの名無しさん** · 2016/08/31(水) 10:23:23.44

標準規格のserializableの話だとして>>478を読み直すと、結論としては>>481はMySQLの分離レベルの
実装はなってないということか？

**469** · 2016/08/31(水) 20:31:43.28

返答ありがとうございました。

前提条件が不明確でいらぬトラブルを生んでしまったかもしれません。

すいませんでした。

やりたい事をまとめますと「複数同時に実行される A.php で、明確に１レコードだけが挿入されるようにしたい」です。

**469** · 2016/08/31(水) 20:32:39.61

結局処理は、シリアライズな？トランザクションの使い方も良く分かっていないので以下のように設計しました。

① Z テーブルの X カラムの値が 49 のレコードが存在するかチェックする（ほとんどの場合はココではじかれる）

② Q テーブルに T レコードが存在していなければ、ユニークなユーザーIDの入った T レコードを挿入する
　INSERT INTO SELECT ？

③その直後、その T レコードの id （オートインクリメント）の値が一番大きい T レコードを取得する

④ T レコードを挿入したのが自分（ユーザーIDでチェックする）ならば、Z テーブルの X カラムの値が 49 のレコードを insert する。

これで A.php が複数同時に走ったとしても一回しか通らないはずです。

大丈夫ですよね？

PDOを利用しています。

要は他スレッド？の A.php による挿入をブロックしなければならないのですが、オーソドックスなやり方を知りたいです。。。

コードが正しいのか、タイミングをほぼ同時にできるかつ自動で微妙に時間をでずらすソフトを作成して、百本ノックならぬ１００億本ノックで安全を担保しようとしています。

凄くタコなやり方ですが、これ以外に安全を担保するやり方を知らないので。。。

**デフォルトの名無しさん** · 2016/08/31(水) 21:55:15.56

Qテーブルに1レコードしか存在し得ないよう制約がかけられているのならOK。複数挿入できるならNG。
そもそもそんなQテーブルが作れるのなら素直にZにユニーク制約をかけることを検討した方が
いいんじゃないかとは思うが。
あと、ロングトランザクションなら楽観的ロックも仕方ないが、ちゃんとトランザクションの使い方を
学んだ方が後々苦労せずに済むと思うがねぇ。

**デフォルトの名無しさん** · 2016/08/31(水) 22:08:34.19

そもそもMySQLって、エンジンによってはトランザクションそのものをサポートしてなかった気がするけど
MySQLの排他制御がどうなってるか知らんが、普通に考えれば

テーブル全体に排他ロック獲得
チェック
インサート
テーブルロック解除

でできるんじゃね
同時実効性とかロック待ちで性能低下とか知った事じゃないけどな

**デフォルトの名無しさん** · 2016/09/01(木) 00:33:23.21

>>469
1で存在チェックしてから、2で挿入するって、
1と2の間に、他のプロセスが割り込めるから、典型的なダメパターン。
教科書に書いてある、やっちゃいけない事前問い合わせ

一々、2回もSQL実行するのは無駄。
いきなり、挿入すればいい。
挿入できなければエラーになるだけ

①のような丸囲み文字は、Windowsの環境依存文字だから、使わないように

**デフォルトの名無しさん** · 2016/09/01(木) 04:24:13.09

ｶﾀｶﾅは日本でしか通じないから
Englishで書いてください

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

>>485
おい、いつのまにか対象とするテーブルが一つから二つに増えてるぞ。
あと、値が49ってなんだよ・・・。

> 大丈夫ですよね？
全然駄目。
すなおにテーブルロックすべし。

**469** · 2016/09/02(金) 10:39:25.56

返答ありがとうございます。

一つ間違っていました。

丸3 の「一番大きい T レコードを～」は「一番小さい T レコードを～」でした。

>>486
>Qテーブルに1レコードしか存在し得ないよう制約がかけられているのならOK。複数挿入できるならNG。
複数挿入できないように制約をかけます。
良く分かってないので怖いですが、INSERT INTO SELECT（行が無ければ挿入？）で実現しようとしています。

>>487
テーブルロックは使わない方法でご教授いただければと思います。

>>488
丸2 で「存在していなければ挿入」とするので、丸1 は必要ないのですが、念のために入れてるだけです。

>>490
テーブルロックは使わない方法でご教授いただければと思います。

**469** · 2016/09/02(金) 10:41:00.77

>2回もSQL実行するのは無駄
指摘を受けてハッとしました。
やりたい事を伝え忘れていました。
「Z テーブルの X カラムの値が 49 のレコード」は結果テーブル１行だけというのは変わらないのですが、
その直前にわりと大きめのトランザクションが走ります。
そのトランザクションが複数走るのではと心配になっていました。
トランザクションはまとめて一気に走らせて「何かに失敗したら全部ロールバックできる便利な機能」位しか理解できていません。
仕組みが良く分かっていないので今勉強中です。

２人から同じご指摘いただいているので、普通はテーブルロックで行うって事ですよね。。。
ちょっとそちらも勉強して理解を深めようと思います。

進捗があったらまた書き込ませていただきます。

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