🎄teratailクリスマスプレゼントキャンペーン2024🎄』開催中!

\teratail特別グッズやAmazonギフトカード最大2,000円分が当たる!/

詳細はこちら
MySQL

MySQL(マイエスキューエル)は、TCX DataKonsultAB社などが開発するRDBMS(リレーショナルデータベースの管理システム)です。世界で最も人気の高いシステムで、オープンソースで開発されています。MySQLデータベースサーバは、高速性と信頼性があり、Linux、UNIX、Windowsなどの複数のプラットフォームで動作することができます。

PHP

PHPは、Webサイト構築に特化して開発されたプログラミング言語です。大きな特徴のひとつは、HTMLに直接プログラムを埋め込むことができるという点です。PHPを用いることで、HTMLを動的コンテンツとして出力できます。HTMLがそのままブラウザに表示されるのに対し、PHPプログラムはサーバ側で実行された結果がブラウザに表示されるため、PHPスクリプトは「サーバサイドスクリプト」と呼ばれています。

Q&A

解決済

4回答

829閲覧

テーブルロックの設計について

tt02

総合スコア36

MySQL

MySQL(マイエスキューエル)は、TCX DataKonsultAB社などが開発するRDBMS(リレーショナルデータベースの管理システム)です。世界で最も人気の高いシステムで、オープンソースで開発されています。MySQLデータベースサーバは、高速性と信頼性があり、Linux、UNIX、Windowsなどの複数のプラットフォームで動作することができます。

PHP

PHPは、Webサイト構築に特化して開発されたプログラミング言語です。大きな特徴のひとつは、HTMLに直接プログラムを埋め込むことができるという点です。PHPを用いることで、HTMLを動的コンテンツとして出力できます。HTMLがそのままブラウザに表示されるのに対し、PHPプログラムはサーバ側で実行された結果がブラウザに表示されるため、PHPスクリプトは「サーバサイドスクリプト」と呼ばれています。

0グッド

2クリップ

投稿2021/03/18 04:43

●テーブルロックの設計に関して。

MySQLとWebアプリケーションの組み合わせです。
現在、次のような状況です。

WebアプリケーションAの利用者は、既存のレコードを編集したい時、編集開始時にレコードロック(select ...from...where...for update)をかけます。
(このレコードをテーブルTのレコードRとします。)
その間、他のWebアプリケーションAの利用者は、テーブルTのレコードRは閲覧しかできない状況になっています。

●今後、次のようなアプリを作りたいと思っています。
管理者専用の、そして一名しか使えないアプリケーションBを作成したいと思っています。
このアプリケーションBでは、WebアプリケーションAの使用状況にかかわらず、任意のタイミングでテーブルTの任意のレコードを編集
できるようにしたいと思っています。

どんな設計を行うと実現できるでしょうか。

あるいは、管理者も現在のWebアプリケーションAを使って、管理を行うべきでしょうか。
しかし、その場合、WebアプリケーションAを利用時に、管理者がロック待ちに直面すると、管理業務に支障が生じてしまいます。
管理業務の中には、新規追加ではなく、既存データの編集もどうしても含まれるため、ロック待ちは極めて非効率だからです。

●条件
・WebアプリケーションAの改修(sqlを含む)は自由にできます。
・WebアプリケーションAの利用者同士は、誰かが編集している時は、閲覧しかできないという条件は改修後も維持しなくてはなりません。
・アプリケーションBはWebである必要はありません。

どうぞ、ご教授いただければ大変助かります。

気になる質問をクリップする

クリップした質問は、後からいつでもMYページで確認できます。

またクリップした質問に回答があった際、通知やメールを受け取ることができます。

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

K_3578

2021/03/18 07:01 編集

yo_uさんの指摘を受け、コメント内容を修正しております。 ーーーーーーーーーーーーーーーーーーーーーーーーーーーー この内容だと ・WebアプリケーションAの改修(sqlを含む)は自由にできます。 ・WebアプリケーションAの利用者同士は、誰かが編集している時は、閲覧しかできないという条件は改修後も維持しなくてはなりません。 ・アプリケーションBはWebである必要はありません。 という条件を満たした設計をしてくれという「作業依頼」と取れますので、 現在どのように組んでいるのか等を明確に示してピンポイントに質問して貰った方が宜しいかと存じます。
yo_u

2021/03/18 04:56

「どんな設計を行うと実現できるでしょうか。」 という、漠然としたアドバイス求めているくらいに受け止めればいいんじゃないですかね? なんでもかんでも作業依頼とかいって、相談にすらのれないんじゃこんなサイト要らないと思いますが。 WebアプリケーションAを使って編集しているレコードのロックを無視して、 アプリケーションBが強制的にデータをいじるときに、 今現在編集しているWebアプリケーションAの動きをどうするのか考えるのが先かなと私は考えます。
退会済みユーザー

退会済みユーザー

2021/03/18 13:09 編集

あほうな提案でもよければ… 「アプリAは編集する際に編集用アカウントしか認めず、アプリAの閲覧は誰でも可能」 「あれ?これWordPressっぽくね?」 「アプリBはAPIにしちゃってURL叩けば編集可能な作りにしちゃう」 「メール投稿とかそれっぽかったような?」 「OK!じゃあWordPressでいこう!」 「「「ないなー…」」」 他の方の回答を見て追記 WordPressは誰かが編集しているときに「OOさんが開いてますよ」と出るので親切なのだと知った。
K_3578

2021/03/18 06:58

@yo_uさん ちょっと過敏反応過ぎかもしれなかったですね。申し訳ないです。 とは言えもう少し内容を絞り込んで欲しかったので、元コメント修正しておきます。
tt02

2021/03/18 12:23

yo_u様 擁護していただき、ありがとうございました。<(_ _)>。おかげさまで良回答に恵まれました。
guest

回答4

0

編集画面が表示されているうちはロックをするのはやめましょう
データを送信する際にトランザクションでロック処理をいれておいてください
ロックされているのは一瞬です
もちろん重い処理が先に実行されている場合はその処理を待ってからの
処理になるので一瞬ですまないものもありますが

投稿2021/03/18 05:08

yambejp

総合スコア116694

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

0

・WebアプリケーションAの利用者同士は、誰かが編集している時は、閲覧しかできないという条件は改修後も維持しなくてはなりません。

一般ユーザー向けのロック管理を、データベース自体のロックを使わずに、別管理すべきものなのではないでしょうか?

投稿2021/03/18 06:51

maisumakun

総合スコア145975

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

maisumakun

2021/03/18 06:52

他の方の回答にもあるように、データベースのロックはあくまでデータの整合性を保つためのものであり、アプリケーションレベルのロックを作り込むために使うものではありません。
tt02

2021/03/18 12:13

ご回答ありがとうございます。なるほど。一般ユーザー向けのロック管理という発想が私に欠落しておりました。DBのロックとアプリのロックの区別がついておりませんでした。 68user様の案2ですね。maisumakun様のご回答、大変ありがとうございました。今後、また困ったとき、ご回答いただく機会があれば、大変うれしく思います。
guest

0

ベストアンサー

案1. A はこれまで通りロックする。B は更新結果を別の「更新反映待ちテーブル」に突っ込む。
案2. ロック管理専用テーブルを別途作成し、A 利用者はそれでロックする。B はそれを使わない。

いずれも A と B 両方更新されたらどっちが勝つのっていう問題はありますね。

投稿2021/03/18 05:21

68user

総合スコア2022

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

tt02

2021/03/18 12:15

ご回答ありがとうございます。 Bの操作はリアルタイム反映を求められているので、案1は実現できませんが、思考の枠が広がりました。 案2の考え方が非常に役立ちました。 『いずれも A と B 両方更新されたらどっちが勝つのっていう問題はありますね。』この点、気づかせていただきありがとうございます。 Bが編集開始した時点で、Aの使うロック管理専用テーブルにその旨をinsertしようと思いました。 経験則からのノウハウ非常に助かりました。
68user

2021/03/18 12:30

A の利用者が「作業時間が無駄になるのはイヤ」的な考えて作業前にロックをかけたいということであれば、A の編集中に数秒おきにポーリングし、「Bの作業によりあなたの作業が無駄になった or 無駄になる可能性あり」というお知らせを出す手もありますね。そういうシステムもたまにあります。
tt02

2021/03/18 13:01

なんと、ご親切(なシステム)!!記憶にとどめておきます。
guest

0

編集開始時にレコードロック

は止めましょう。
MMIのさなかにロックを含めるべきではありません。
先ずは、楽観的排他で検討されることをお薦めします。

投稿2021/03/18 05:26

sazi

総合スコア25327

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

tt02

2021/03/18 12:14

ご回答ありがとうございます。確かにその方向で検討を考慮しようと思います。 おっしゃるように少なくともWebアプリA利用者は、テーブルTに対する、編集開始時ロックはかけない方向で目的を実現させたく思います。
guest

あなたの回答

tips

太字

斜体

打ち消し線

見出し

引用テキストの挿入

コードの挿入

リンクの挿入

リストの挿入

番号リストの挿入

表の挿入

水平線の挿入

プレビュー

15分調べてもわからないことは
teratailで質問しよう!

ただいまの回答率
85.36%

質問をまとめることで
思考を整理して素早く解決

テンプレート機能で
簡単に質問をまとめる

質問する

関連した質問