順番を管理しているデータの二者間のデータ更新について

Question

いつもお世話になっております。

社内の商品をの生産を管理するために、生産管理予定表を作成し運用しております。
利用しているデータベースは、MySQL5.7.xを利用し、プログラム言語は、Javaを利用しております。

生産管理予定表を更新する管理者と、生産を行う作業者の両方から利用されております。
生産管理予定表は、複数の設備ごとに用意しております。

生産予定を管理するテーブルを一つ用意し、各設備ごとの製品に対して優先順位を割り当て
更新時に、対象設備の全データを更新し優先順位を振り直しています。

作業者は優先順位の高い順から作業し、管理者は基本的には優先順位の低いデータを登録しています。
順番性を担保するために、更新については先勝として後からデータを更新できないようにしております。

運用では、先勝ちが多発しており利用者から少し不満の声があり、改善できないか検討しております。
設計が悪いこともありますが、RDBを利用する上では、こういった状況を回避するのは難しいのではないかと思いました。

どんな方法にしても、データの不整合を防ぐために、どちらかに対して再操作を促す必要があるかと思いますが、
極力、最低限にしたいと考えております。

RDB以外でも、こういった状況を解決するデータのもたせ方がございましたら、
アドバイスいただけないでしょうか？

大変、お手数をおかけしますが、よろしくお願いします。

=== 追記 ====

DDL を記載させて頂きます。
サンプルとなりますが、下記のようなテーブルでございます。

CREATE TABLE products (
goods varchar(30),
order_no int,
created_at datetime
)

ストレージエンジンは、InnoDBを利用しております。

「更新については先勝として後からデータを更新できないように」という箇所ですが、
説明が不足しており申し訳ございません。

開発しているWebシステムの作りに引きづられてしまっているので、このような作りになってしまっているのですが、

1.管理者にて予定表作成画面を開き製品を追加したり順番を変えたりし予定表を作成
2.更新ボタンにて、POSTを行い対象の設備の予定表を更新
→ 管理者が予定表を作成している最中に、現状システムに登録されている予定表に変更があれば、予定表は更新させない。
→ 作業者基本的に、削除するのみなので、データあれば、削除なければ何もしない

と、いった作りになっております。

作業者からの更新頻度が高いため、管理者の更新処理が行えず、何度もやり直しの状態が発生しております。

Comments

[SVC34]

DDLとSQLを提示してください。ストレージエンジンはInnoDBを使用されていますか？「先勝ち」とはどのような状況で、それによりどのような問題・不満が生じているのかを具体的に説明してください。「更新については先勝として後からデータを更新できないように」は現状どのように実現していますか？

Answer 1

命題自体競合に関する質問だと理解しましたが
優先順位の考え方としてはプロジェクト管理に近い感じになるかも
パターンは４つ

(1)タスクAとタスクBが直結している場合、つまりタスクAが終了しなければ
タスクBが始まらなければ優先順位はタスクAにあります
(2)タスクAとタスクAダッシュが並行している場合、タスクAもしくはタスクA
ダッシュがどちらかがクリティカルになるので遅れている方が優先順位が
高くなります（進んでいる方は調整ができるので）
(3)タスクAとタスクBに相関関係がない場合、結果としてどちらが先に
あがってきても変わりはありませんので速く報告が来たほうが優先順が
高くなります（先勝？）

難しいのが(4)、タスクAが仕掛りでもタスクBが始められて並行しているが
タスクAが進まないとタスクBが処理できない場合。
これは原則タスクAを優先順位が高いとしますが、基本的に一体作業と考え
タスクCとして別管理するしかありません

これらをガントチャートの要領でつなげて優先順位をつければ、
たんに報告順に優先がつくことはないと思います

Comments

[退会済みユーザー]

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

アドバイス頂いたことを、質問させて頂いた後に、ずっと考えておりました。
数珠つなぎをイメージしております。
(イメージとしてはあってますでしょうか？)

データのロストさえしなければ、順番は担保できそうだと思いました。

Answer 2

（本来は「質問への追記」に書くべきでしょうが、引用ができないので、回答にて失礼します。）

生産予定を管理するテーブルを一つ用意し、各設備ごとの製品に対して優先順位を割り当て

更新時に、対象設備の全データを更新し優先順位を振り直しています。

更新時、作業者が「作業中の『最優先順位』」を、下位の優先順位と入れ替えることは、しませんよね？

作業者は優先順位の高い順から作業し、管理者は基本的には優先順位の低いデータを登録しています。

順番性を担保するために、更新については先勝として後からデータを更新できないようにしております。

ここまでは、問題は無いと思います。

運用では、先勝ちが多発しており利用者から少し不満の声があり、改善できないか検討しております。

問題はこの「先勝ちが多発しており利用者から少し不満の声」の

『利用者』とは、何者なのでしょう？

• 管理者？
• 作業者？
• その他？

『不満の声』とは、何でしょうか？

• 管理者の投入順位が「作業性」を悪化させているので、「作業者」でも「優先順位を微調整したい」？
• 更新時の変化点が見えないので「作業者」が「段取り時困惑が生じる」？
• その他？

設計が悪いこともありますが、RDBを利用する上では、こういった状況を回避するのは難しいのではないかと思いました。

「設計が悪い」のであって「RDB」とは関係無いと思います。

どんな方法にしても、データの不整合を防ぐために、どちらかに対して再操作を促す必要があるかと思いますが、極力、最低限にしたいと考えております。

上記内「？」に、何らかの回答を頂ければ、更なる提案が出来ると思います。

Comments

[退会済みユーザー]

ご質問ありがとうございます。

回答が遅くなりまして、申し訳ございません。

>更新時、作業者が「作業中の『最優先順位』」を、下位の優先順位と入れ替えることは、しませんよね？

入れ替えることはしております。

>『利用者』とは、何者なのでしょう？

説明に不備があり、申し訳ございません。
利用者というのは、管理者をさしておりました。

管理者が、計画をしている最中に、作業者からの更新が発生してしまうため、
その都度、計画を見直しを行っております。
上の文章だけだと、計画している最中に作業されているのであれば、計画を見直すのはあたりまえのことだと思われますが、現状のデータベースの設計では、例えば、１０個の製品があるとし、作業者が優先順位の高い製品を削除した場合、残りの９個の製品に対して、採番を再度するようにしております。

簡易的ですが、テーブルの持ち方は下記のようにしております。

goods varchar
order_no int
created_at datetime

質問をさせてから自分なりに考えてみました。
データの持ち方とシステムの作りを一部変えて対応したいと検討しております。

テーブルの持ち方を、

goods varchar
before_goods varchar
created_at datetime

とし、一つの行データに対してそのデータ自身がどの行データの後なのかを把握するためのカラム(before_goods)を用意する。

予定表に追加・削除・並び替えを行った時点で対象のカラムの情報を更新する。

文章しているうちに気づいたのですが、ただ、データ自体が一つでもロストした場合、並び順が担保できなくなりますね。。。

[退会済みユーザー]

はやり、そういう事でしたか？
もし、小生が、当システムの作成者ならば、
「追加・削除・並び替え」発生時、それぞれの背景色を変えて、
管理者と作業者間での相互承認にて、生産管理予定『確定』、、、
みたいな、概念（操作）を実装すると思います。