クソシステム過ぎる…

駿河屋みてえなシステムだな

今どき本屋使う奴が悪い

これがあるから駿河屋は発送しましたのメール見るまで安心できない

※実店舗と在庫を共有しています。
よりつらいな

研修で周知させないといけないことすぎんだろ…！

なんで発注やらせてるのにこんな大事な欠陥教えてねぇんだよ…！

表示の反映にラグがあるのはまだ分かるけど更新処理の制御にまでラグがあるのはクソシステムってレベルじゃねえよ…

システム側の問題を運用でカバーしてるとこうなる

じゃあ近くの別の本屋でその本買ってくるしかねえな…！

確定しましたって表示すんなや

これ僕くんのミスか…？

多分もっとクソな部分がある
ダーティーリードもする

これシステムのバグであってメガネの人のミスではなくない？

確定しない欠陥が分かっているなら「確定しました」のメッセージは変えろよ

こういうのを回避するときはシステム屋さんはどういう感じにするの？

シス屋さんはさぁ…後は現場で対応してと納品する人？

amazonで買うかあ

いちいち発送されたかどうか後から履歴見に行かないと行けないの？クソすぎない？

履歴をこっちで確認しろって
こんなうんこシステム使うな

「注文確定したって言ったよな？」

>こういうのを回避するときはシステム屋さんはどういう感じにするの？
マイナス在庫でエラーにする
もしくは他ユーザに更新されましたってエラーにする

こんなんだからネット通販に客取られるんだ

>こういうのを回避するときはシステム屋さんはどういう感じにするの？
>排他制御

>こういうのを回避するときはシステム屋さんはどういう感じにするの？
先に注文した書店がカートに入れた時点で在庫仮押さえにして後続が注文できないようにするか
後続の書店が注文ボタンを押したタイミングで在庫が有るかもっぺん確認して無ければエラー表示をだす

少なくともキャンセルされました系の通知は欲しい…

ここロックすると遅すぎて使い物にならないから…仕方ないから…

名前的に元ネタがブックライナーだとすると他の出版社サイトより早いというか
書店に一番早く着くサービスだからスレ画みたいに他は届いたのにライナーのだけまだ来てないみたいにはならんよね

実際こんなので本届いてないんですよって言われたら
今度から通販にするか…ってなるよ

>マイナス在庫でエラーにする
>もしくは他ユーザに更新されましたってエラーにする
ごめんラグが想定されてる場合どうするのかなって

注文システムに入る時だけ在庫があるか確認して注文完了時には在庫があるかもう一度確認してないのかな
早く直せ

注文確定しましたが本当に正しいのかの確認までしないといけないのか
クソシステム！

客からすればぬか喜びでたまったものではない

あくまで注文のリクエストが到着しましたという意味であって
そのリクエストが実際に実現可能かどうかはわかりませんと言いたいんだろうか

>こんなんだからネット通販に客取られるんだ
ネット通販も自分のとこの在庫か切れたら取次や出版社から取り寄せる事になるので
発注したはずなのにまだ来ないぞ(減数食らった)とかはあるよ

普通に組んだらならないよねこれ
>ここロックすると遅すぎて使い物にならないから…仕方ないから…
こういうのでsqlトレースしないで場当たり的に作るからこうなる

今日新幹線の座席購入で座席選んだ後にチケット出る前に弾かれたからそういう仕組みにする必要があるんだよ…

>ここロックすると遅すぎて使い物にならないから…仕方ないから…
チューニングしよ
DBのパフォーマンスが出ないならアプリ側で制御しよ
在庫管理として致命的だよ

>あくまで注文のリクエストが到着しましたという意味であって
>そのリクエストが実際に実現可能かどうかはわかりませんと言いたいんだろうか
ならそう書け

これで最初にヨシ！した責任者を
棒などでしばいても許される

座席予約システムレベルのシステムにしろ

>ごめんラグが想定されてる場合どうするのかなって
>排他制御

せめて後からでもエラー表示しろや

kindleで買います

そこまで金掛ける価値もねえんだ
現場で一手間増やしてくれ

>>マイナス在庫でエラーにする
>>もしくは他ユーザに更新されましたってエラーにする
>ごめんラグが想定されてる場合どうするのかなって
普通のシステムは在庫の増減の処理でラグは発生させない

>今日新幹線の座席購入で座席選んだ後にチケット出る前に弾かれたからそういう仕組みにする必要があるんだよ…
飛行機のチケットとかはキャンセル分見越して座席数の１１０％ぐらい発行するけど
すごい思い切るよね…

>ごめんラグが想定されてる場合どうするのかなって
画面表示ならともかく更新処理部分にラグが入り込む余地が生まれてるのがそもそもおかしい

百歩譲って注文受け付けたよぐらいのニュアンスで言ってるなら
在庫無くて発送出来ないときにメールかなんか寄越せ…

きょうびわざわざ書店で注文してくれるお客さんって
書店が好きでやってる人だろうし
通した注文が通ってなかったってなったらもう来ないよな

システムが悪い
周知してないのが悪い

実店舗と在庫共有って店員が店に来た客より先に本を確保してくれないと敗けるのかー

こ…こんなシステムあるのか…

つまりよおシステム改修する金も無いんだろ？
お辛い…

DB2を使う案件の時にどうしてもうまく処理する方法がなくて
IBMに相談したらOracle風に動くモードを教えてくれて解決したことある

数日間注文反映されたか確認するの忘れてたって書店だと気が回る回らない以前の話というか
普通確認する時間毎日作ってるでしょとしか言えん

Amazonで注文すればよくね？

やめだやめだ
平日ど真ん中の寝る前にシステム開発の話なんかやめよう
死にたくなるから
本当に

確定しましたって表示されるってことはリクエスト通ってるわけなので発注の際に異常でないってことはどこかでキャンセルしてることになる
どこで情報捨ててんだよトラブル発生してるのわかりきってるんだからちゃんと通知しろ

>きょうびわざわざ書店で注文してくれるお客さんって
>書店が好きでやってる人だろうし
>通した注文が通ってなかったってなったらもう来ないよな
まあ1店員が知ったことではないな

>Amazonで注文すればよくね？
Konozamaだよ

近隣店舗に電話して
すいませんありませんか！？って聞いたりするしかねえか

テストはどうなってんだよテストは

ネット以外にも電話やFAX注文や店頭の直接取引でも在庫が減るような場合は
ネット取引の排他処理だけでは無理ダナ

システム作ってほうだってねツラいんですよ

最初にこれで通した奴は何考えてるんだ！？ってシステム結構あるよね

じゃあなにか注文が確定したかもしれません。に変えればいいのか？

どういうDBの作りしてるんだ…
そもそもこの子ウィンドウは本当にクエリが帰ってきたのを見て出してるのか…

楽観排他もかけてないのか

行ロックとかなんかいい感じに入れてほしいなこれ

>ごめんラグが想定されてる場合どうするのかなって
メッセージを「受け付けました」と「確定しました/取り消しました」の2段階にして「受け付けました」の後にラグのせいでWブッキングしてないか確認して「確定しました/取り消しました」にする

>テストはどうなってんだよテストは
現象が知られてるんだから、仕様ですで通したんだろう…

このあとどうなるの…？

ちゃんと作っても顧客の要望で変えられたりする
利用者側からしたらクソ仕様になる

WEB在庫数一応出るからこれやったことないな…

日販のNOCSにしてもトーハンのTONETSにしてもなんならスレ画の元ネタっぽいブックライナーにしても
在庫数はリアルタイムで減るというか違う店が同時に客注完了押したとかでもなきゃ在庫0ですに変わるけどいつの記憶で書いてんだろ

でもよぉ……
これってフィクション発注サイトなんだろぉ？現実の本屋さんの発注サイトはこんなクソサイトじゃないんだろぉ？

ラグがあるって言ってるでしょ

>最初にこれで通した奴は何考えてるんだ！？ってシステム結構あるよね
システム会社が必ずしも悪いわけじゃないのがな…

>じゃあ近くの別の本屋でその本買ってくるしかねえな…！
https://comic-walker.com/detail/KC_004869_S/episodes/KC_0048690001700011_E

>まあ1店員が知ったことではないな
そりゃ店員はただのバイトだからその客が今後来なくなっても痛くも痒くもないんだけどさ…
ただでさえ減ってる書店の客がさらに減るのは良いことではないよね

中小チェーン店程度の内部システムだと軍服に自分の体を合わせろみたいなクソ欠陥がおうおうに存在する
俺が入社する前からずっと修正されないし俺が辞めてもきっとずっと続く

>これってフィクション発注サイトなんだろぉ？現実の本屋さんの発注サイトはこんなクソサイトじゃないんだろぉ？
現実は我々の想像をいとも簡単に超えてくれる

結局仕様の洗い出しが甘いだけだろうからな…

昔ECサイト作ったときは二人同時にやるいっせーのーせテストをした
作りが甘いと客に届くサンクスメールが入れ替わったりする…

>じゃあなにか注文が確定したかもしれません。に変えればいいのか？
仕組み的にどうしてもできないなら一旦注文を受け付けましたって出して確定までにインターバル取ればいい

よくこんな欠点抱えた発注システムで納品できたな

ノウハウとして共有される程度には何度かあった事例なんだな…

>最初にこれで通した奴は何考えてるんだ！？ってシステム結構あるよね
要件定義で開発側から本当にこれでいいんですね！？って何回聞いてもいいから早く作ってとしか言わない客はいる
こういう弊害があるけどいいんですか！？って言っても全く聞く気がない

各出版社の補充注文用サイトなら在庫有るって書いてあったじゃんなんで配本0なのは割とあるけど
客注でスレ画みたいなケースになる客注用サイトってなんかあったか

最後にめちゃいい客来てるな

店員は悪くないのは分かるんだけど
注文した客には関係のない話なんだ

>じゃあなにか注文が確定したかもしれません。に変えればいいのか？
セーブポイントトラップ

スレ画みたいなことは無かったけど在庫ありますねでは注文をって注文書書いてもらい帰ったタイミングで見たら在庫無くなってたってことはある

在庫ないのに発注通るケース自体は最悪まあ仕方ないよ
発送できないなら能動的に通知しろよ何でそのまま放置が許されてるんだ

街の本屋さんも滅びつつある

在庫データが１DBにまとまってるならまだやりやすいけど
複数システム横断での在庫確認が必要になったりするとまあ面倒くさい

これ気づいたところでいつ謝るかの違いにしかならなくない？

>>じゃあなにか注文が確定したかもしれません。に変えればいいのか？
>仕組み的にどうしてもできないなら一旦注文を受け付けましたって出して確定までにインターバル取ればいい
だが店頭に来るお客は意外とせっかちなのだ！

下手に弄るともっとバグ作りそうで…

>発送できないなら能動的に通知しろよ何でそのまま放置が許されてるんだ
スレ画に関して言えば忙しくて確認できなかったねって言ってない？

>>最初にこれで通した奴は何考えてるんだ！？ってシステム結構あるよね
>要件定義で開発側から本当にこれでいいんですね！？って何回聞いてもいいから早く作ってとしか言わない客はいる
>こういう弊害があるけどいいんですか！？って言っても全く聞く気がない
気付いてるならなんとかしろ役目でしょ

>じゃあなにか注文が確定したかもしれません。に変えればいいのか？
「注文を受け付けました」
「注文が確定しました」/「注文の受付を取り消しました」
「発送しました」
の3段階にする

在庫管理「」の集い

>発送できないなら能動的に通知しろよ何でそのまま放置が許されてるんだ
立場の強い殿様商売だと許されたりする…

結合テストで排他制御が甘い障害が発見された俺にとってタイムリーなスレ

>気付いてるならなんとかしろ役目でしょ
システム会社は言われたものを作るのが仕事だからね
そびえたつウンコでも作らなきゃならない

昔注文したのが予定日に届かなかったって謝られたことあるけどこれのせいなのかな…
でもあの書店在庫聞いただけで金取られたことあるからな…
いついつ届きますんで前払いにします？じゃねえんだよ面白かったですウォーターシップダウンのうさぎたち（ハードカバー）

>在庫数はリアルタイムで減るというか違う店が同時に客注完了押したとかでもなきゃ在庫0ですに変わるけどいつの記憶で書いてんだろ
完全に同時に完了しても排他制御を行っていれば問題ないので
そこで問題が発生するシステムはヤバいゾ

>>発送できないなら能動的に通知しろよ何でそのまま放置が許されてるんだ
>スレ画に関して言えば忙しくて確認できなかったねって言ってない？
そこを人力に頼るままだとヒューマンエラーを０にできないのでシステム改修で警告メッセージ出させるとかした方が良い
が本社はシステム改修に多大なお金がかかるから…と言って永年放置する

確定とか完了って言葉が持つ意味は重いからマジで確定しきった時以外は出さない方がいいんだ

受注側もすごいアナログな方法で倉庫の在庫確認してるだろうから
客が発注してから秒単位で現物押さえろと言われても無理だろうな…という気はする

>>発送できないなら能動的に通知しろよ何でそのまま放置が許されてるんだ
>スレ画に関して言えば忙しくて確認できなかったねって言ってない？
普通は在庫確保失敗した時点で確保失敗の通知がまず行くし親切なら届く段階でも以下の商品は在庫確保出来ませんでしたのでキャンセルされましたって品目に書かれると思う
なんで注文者が後からこれちゃんと受け付けられたかなーっていちいち見ないといけないんだよ

ジョジョのチョコラータの気持ちが良く分かる
あとで注文出来てませんでしたってのが最もむかつく

>よくこんな欠点抱えた発注システムで納品できたな
要件定義で発注側がOK出したからだし

エンジニア15年やってるけど未だに在庫管理の仕事が回ってくると「在庫管理かぁ…」ってなる
それぐらいだいたい業務がややこしい

これ各出版社とかの注文用サイトのダメ元で客注扱いにして注文してみるかで配本貰えなかったケースと
そういうケースは起こらない客注専用サイトの存在をごちゃ混ぜにして書いてるというか
書店員だとむしろどのサービス使ったんだこれとツッコミ入る内容だと思う

>でもあの書店在庫聞いただけで金取られたことあるからな…
>いついつ届きますんで前払いにします？じゃねえんだよ面白かったですウォーターシップダウンのうさぎたち
注文したのに取りに来なかった客に悩まされたんだろう…

こういうシステムがちゃんとしてる企業ってどこがあるのかしら？ちなみに俺はニータ

現実だとこんなクソ仕様教えられずトラブル起きてから「なんで知らねぇんだよ！！」と責め立てられるの理不尽

>普通に組んだらならないよねこれ
DBによるとおもう
単一のRDBによる昔ながらの業務システム構成ならまあ安心
クラウドでNoSQLなDBとかだときがるに扱って良いものではないなとくるしむ

>エンジニア15年やってるけど未だに在庫管理の仕事が回ってくると「在庫管理かぁ…」ってなる
>それぐらいだいたい業務がややこしい
DB屋？

>>エンジニア15年やってるけど未だに在庫管理の仕事が回ってくると「在庫管理かぁ…」ってなる
>>それぐらいだいたい業務がややこしい
>DB屋？
基幹シじゃない？

>街の本屋さんも滅びつつある
これも時代の流れだ仕方あるまい
より便利なものが登場したのに追従できなければ淘汰されるのは自然なことよ

TSUTAYAやメロンブックスの店頭在庫検索で「在庫あり」なのに売り切れやられた事ある
ラグがあるから仕方ないという説明だけれどそういうのを公開されても困る…

結局本屋が入荷してから電話してくれるのが1番正確

社会人なってからずっと証券系のシステムだけ触ってるから逆にこんなのがマジで存在するのか？くらいに思ってしまう

>結合テストで排他制御が甘い障害が発見された俺にとってタイムリーなスレ
発見できて偉い！
まあ後の工程は地獄だけど、カットオーバー後に発覚してデータの修正も必要になるのよりは何倍もマシ！

>>>エンジニア15年やってるけど未だに在庫管理の仕事が回ってくると「在庫管理かぁ…」ってなる
>>>それぐらいだいたい業務がややこしい
>>DB屋？
>基幹シじゃない？
DBとアプリ掛け持ちしている

でもこんな事のためだけにシステム改修なんてやれないよな

>現実だとこんなクソ仕様教えられずトラブル起きてから「なんで知らねぇんだよ！！」と責め立てられるの理不尽
スレ画もトラブル起きてから教えてるじゃん！

>TSUTAYAやメロンブックスの店頭在庫検索で「在庫あり」なのに売り切れやられた事ある
>ラグがあるから仕方ないという説明だけれどそういうのを公開されても困る…
あくまで目安であることを保証するものではないから…

コンビニよくおいてあるモバイルバッテリーのレンタルだけどこれの在庫管理大変だろうなぁ…って思いながら見ている

街の本屋さんは新聞の切り取り持って行ったら在庫探してくれる場所としての需要があるから…

知ってて是正しない周知しないは罪ですよ！

>まあ後の工程は地獄だけど、カットオーバー後に発覚してデータの修正も必要になるのよりは何倍もマシ！
こっちは本番障害祭りだぜ
プロパーの方は頑張ってください！

>知ってて是正しない周知しないは罪ですよ！
おあしす…

>TSUTAYAやメロンブックスの店頭在庫検索で「在庫あり」なのに売り切れやられた事ある
>ラグがあるから仕方ないという説明だけれどそういうのを公開されても困る…
メロブは更新時間の関係で在庫ない場合あるよ了承してね
って注意書き書かれてなかった？

ここだけちょっと直してくれるだけでいいからさ…すぐ直してね！

>TSUTAYAやメロンブックスの店頭在庫検索で「在庫あり」なのに売り切れやられた事ある
>ラグがあるから仕方ないという説明だけれどそういうのを公開されても困る…
在庫のズレに関してはマジでしょうがねえんだ
なんなら書店はそこに万引きも絡む三重の地獄だ

>クラウドでNoSQLなDBとかだときがるに扱って良いものではないなとくるしむ
えっ？在庫管理をNoSQLで…？！

>>結合テストで排他制御が甘い障害が発見された俺にとってタイムリーなスレ
>発見できて偉い！
>まあ後の工程は地獄だけど、カットオーバー後に発覚してデータの修正も必要になるのよりは何倍もマシ！
排他ミス起因の障害って本番運用後だと見つけるのが困難だからね…

書店のメリットとは…

>なんなら書店はそこに万引きも絡む三重の地獄だ
レジ通さないから反映されないのか…
万引き許すまじ過ぎる…

>>クラウドでNoSQLなDBとかだときがるに扱って良いものではないなとくるしむ
>えっ？在庫管理をNoSQLで…？！
注文データだけNoSQLにして在庫データ自体はRDBみたいな感じじゃない？

>えっ？在庫管理をNoSQLで…？！
出来らあっ！

>ここだけちょっと直してくれるだけでいいからさ…すぐ直してね！
何か不具合起きたら責任全部取ってくれます？

客側のメリットとしては
とんでもない量のタイトルが一気に目に入るから
ネットのオススメじゃ出てこない本に出会えることだと思う

プログラム書き換えるだけならハードルは低い
えっ現場の業務フローも変更しなきゃいけないんです？

在庫なかったらせめてアラートだせ
他の発注作業中にも常に出し続ける勢いで

気づいてるなら何とかしろで勝手に仕様変えるとね…当然怒られるんだよ…

>ここだけちょっと直してくれるだけでいいからさ…すぐ直してね！
顧客確認が済み次第本番リリースしますね
……そして一年がたった

金融系のシステム構築やった時は各拠点のオペレーター端末に自動操作プログラム入れて排他制御にミスがないかめちゃくちゃ確認した
どっかの拠点の社員さんが興味本位で端末触って自動操作止めちゃって引くほど怒られてた

>どっかの拠点の社員さんが興味本位で端末触って自動操作止めちゃって引くほど怒られてた
よくそれだけで済んだな…

それこそeplusとかチケットぴあみたいな特定の時間帯に膨大な注文が入るサイトってどんな在庫管理しているのかちょっと興味ある

一冊盗まれると在庫あるのに無い状態なうえに損害取り返すのに数十冊売らないといけない

なんでそんなケース想定するの
起こらないよ起こるわけ無いでしょと言われ足らん
それは実運用で絶対に起こるフラグ

客にとっては本が届かないって時点で問題だろうけれどシステム屋的には届かないことそのものより店員がなんで届いてないんですか！って言い出すようなシステムなことの方がすごい怖い

えっこれ本当に本屋のシステムこんなのなの…？

けっきょく運用する側が在庫をラグなしでサーバーに反映する習慣を徹底しないと悲劇は繰り返しうる
というかブックオフのアレ見てれば実在庫とバーチャルなデータなんて合ってるほうが奇跡というか

仮引当で発注止めるかマイナス在庫でエラーにしろ

>在庫なかったらせめてアラートだせ
>他の発注作業中にも常に出し続ける勢いで
毎日のように来るから無意識でOKボタン押すやつ

どっちみち謝ることは変わりないんだよな

システム屋はシステム要件を満たしてるかどうかしか考えてない
発注かち合うとか在庫数量がマイナスとかただのエラーケースだから運用なんか知らん

>なんなら書店はそこに万引きも絡む三重の地獄だ
レジはまだ通ってないけど既に棚から取った人は居るとかもそこまで管理できねぇよ！という話だしな…

悪いのはクソシステムでも頭下げるのは結局…

膨大な在庫管理してるシステムでこの仕様はかなりヤバい

>システム屋はシステム要件を満たしてるかどうかしか考えてない
>発注かち合うとか在庫数量がマイナスとかただのエラーケースだから運用なんか知らん
要件を満たしてないだろそれ

>システム屋はシステム要件を満たしてるかどうかしか考えてない
>発注かち合うとか在庫数量がマイナスとかただのエラーケースだから運用なんか知らん
最初からそういうケース想定した上で依頼しろや！ってこと？

>えっこれ本当に本屋のシステムこんなのなの…？
普通のシステムだったらマイナス在庫が発生したらメールなりなんなりで通知するような仕組みがある
もしくはWEBで注文した段階ではあくまで発注を受け付けたってステータスにして改めて在庫を確認して足りてるんだったら注文確定の連絡を出すようにする

こういうの処理できなかったのが確定した時点でメールやらメッセージとか来ないのって思ったけど
発注通ってないのは履歴みたら分かるだろっていわれたらそうかもしれない

>システム屋はシステム要件を満たしてるかどうかしか考えてない
>発注かち合うとか在庫数量がマイナスとかただのエラーケースだから運用なんか知らん
いやド定番のイレギュラーパターンだから当然念頭に置くよ
あとは対応に必要な納期と予算が確保されるかどうかだ

機会損失がーで無い分まで受け付けようとするのは
仕様決めるときに偉い人が余計なことしたんでしょ

>それこそeplusとかチケットぴあみたいな特定の時間帯に膨大な注文が入るサイトってどんな在庫管理しているのかちょっと興味ある
接続できた人が押さえた席は仮押さえで15分くらいずっともってる
同時に席押さえたら…？その辺は気合いでまあ…

>同時に席押さえたら…？
サーバに届いた順で先勝ちじゃいかんのか

黎明期はこういうクソシステムよくあった

>膨大な在庫管理してるシステムでこの仕様はかなりヤバい
目安が分かればいいようなシステムなのかもしれない
存在意義はあまり分からないが…

>中小チェーン店程度の内部システムだと軍服に自分の体を合わせろみたいなクソ欠陥がおうおうに存在する
>俺が入社する前からずっと修正されないし俺が辞めてもきっとずっと続く
軍服に体合わせろなんて言ってねえよ
そのオンボロ火縄銃がライフルに変わったから使い方覚えろって言ってるんだよ
なんで趣味のサブスク使えるのに支給されたIDパスワード管理できませんとか抜かすんだ
みたいなのも体験したのでどっちが正しいかわからない

>えっこれ本当に本屋のシステムこんなのなの…？
本屋だけじゃないかもしれない
ドラッグストアでもあるぞこのクソシステム…

>システム屋はシステム要件を満たしてるかどうかしか考えてない
>発注かち合うとか在庫数量がマイナスとかただのエラーケースだから運用なんか知らん
その理論は通用しない
いわゆるそういった非機能部分は当然実装しているべきと判断されて裁判起こされると負ける
もちろん特定のケースで排他が抜けるって障害であれば戦いようがあるが要件書に書かれてないから排他制御考えてませんは100%負ける

履歴で確認してる時にはもう手遅れなんじゃないの？

そんなんだから棚卸で苦労するんだぞ

セマフォを落としただけなのに

旭川医大の事例いいよねよくない

在庫かち合った時の想定してないってことは下手したら空出荷で空箱だけ送られてきても仕様通りですって話になりかねないバカ企業になっちゃう

>Amazonで注文すればよくね？
「在庫不足のためご注文の商品はキャンセルされました」

>履歴で確認してる時にはもう手遅れなんじゃないの？
数日の余裕あるなら探し回れるかもしれないし…
するか…？多分しない

同じ瞬間にレコード編集が来うるは典型的だから考慮しないのは怠慢
複数DB跨ってるとか見かけ上1つのDBのようなふるまいを普段はするとかみたいな世界なんかだとたいへんなので
人とお金と時間がないなら運用でカバーしてくださいはあるかもしれない

確定していないのに「確定しました」のメッセージ出すとか裁判なったら負けない？

薬剤などは確定はしないで受注残がどんどん積もってシステムかな…
即応性を犠牲にすればそりゃいくらでも対応はできるよ
その場で客に納期まで確約するのが難しい

>旭川医大の事例いいよねよくない
あれは発注側があまりにも悪質って判断されたから…

もはや狭くても広くても利用しづらいよね本屋って

なんか例外種類ありすぎ…
exceptionをキャッチするか…

メガネは悪くないが
めんどくせぇ客にそんな事言っても通じるわけがなく…
本部の人間が来て謝れ

>>同時に席押さえたら…？
>サーバに届いた順で先勝ちじゃいかんのか
それでいいんだけど繋がった！席取った！取れてない！を延々と繰り返すとどんどん席の質が落ちていく…

せめて発注データ送信しましたと注文確定しましたを分けて

DB系の本読むと排他処理について必ず口酸っぱく書いてある割には結構この手の話あるよね

映画館だと被ること考慮して席が確保してあるな

>確定していないのに「確定しました」のメッセージ出すとか裁判なったら負けない？
読んでないけど利用規約のどっかに免責事項書いてあるんだろう
裁判大国の企業がそこら辺手を抜くはずはないし

まあ映画とか乗り物とかなら代わりの席なり便なり用意すればいいけど在庫はそこに無ければ無いからな…

限定品とかだとヤバいやつ

>確定していないのに「確定しました」のメッセージ出すとか裁判なったら負けない？
システム会社を訴えるならこの程度では裁判に勝つことは無理かな…
本屋が取次会社を訴えるなら勝てても得るものが全くない

amazonのシステムってがんばってるんだな…

ここまでトランザクションの制御の話なし

ぶっちゃけ仕事に不慣れな現場新人の確認不足ってことにして怒鳴って謝らせた方が八方丸く収まるんだ
生け贄になれ

>>システム屋はシステム要件を満たしてるかどうかしか考えてない
>>発注かち合うとか在庫数量がマイナスとかただのエラーケースだから運用なんか知らん
>その理論は通用しない
>いわゆるそういった非機能部分は当然実装しているべきと判断されて裁判起こされると負ける
>もちろん特定のケースで排他が抜けるって障害であれば戦いようがあるが要件書に書かれてないから排他制御考えてませんは100%負ける
そんなバカな話有るか
排他制御を要求しなかったユーザが悪いだろ

謎のデータベース風コンポーネントだと書き込みに排他制御が効かないので二重書き込みを防ぐためには書き込みノードは1つだけにしてくださいみたいなことを言われる
こんなゴミ製品使うな〜〜〜〜〜〜〜〜〜〜〜〜〜〜！！！！！！！！！！！！！！！！ってなる

プレイヤーA：ミュウツーを送る
プレイヤーB：コラッタを送る
プレイヤーA：ミュウツーを受けとる
プレイヤーB：コラッタを受…電源を切る！
プレイヤーA：レポートを書く
プレイヤーB：交換前の状態をロード

確定したけど物無かったんなら連絡くれよ

>プレイヤーA：ミュウツーを送る
>プレイヤーB：コラッタを送る
>プレイヤーA：ミュウツーを受けとる
>プレイヤーB：コラッタを受…電源を切る！
>プレイヤーA：レポートを書く
>プレイヤーB：交換前の状態をロード
今はオンラインでデータベース噛ませるからお互いの処理が完了しお互いの端末の書き換えとデータベースの更新が完了する前にそんなことしたらエラーでお互いロールバック処理だろうな

Amazonも注文は通ったけど配送準備中のままピクリも動かない
1ヵ月後にこちらからキャンセルとかたまにある

>プレイヤーA：ミュウツーを送る
>プレイヤーB：コラッタを送る
>プレイヤーA：ミュウツーを受けとる
>プレイヤーB：コラッタを受…電源を切る！
>プレイヤーA：レポートを書く
>プレイヤーB：交換前の状態をロード
違法栽培システム！

>そんなバカな話有るか
>排他制御を要求しなかったユーザが悪いだろ
要件定義に書いてなくても常識的に考えて必要だよね…って内容だと負けることがある
提案したうえで要りません！って言われたなら話は別だが

後で確認しなければいけないのタイムラグがどれくらいかにもよる
数十分かかると死ねって思う

こういうのはもう共通規格でテンプレみたいなの出来てないの？

>そんなバカな話有るか
>排他制御を要求しなかったユーザが悪いだろ
実際の裁判事例いくつかあるよ
システム開発会社は専門家なんだから当然考慮すべき範疇のことを考えるのは契約書に書かれて無くても期待されうる役割だよって裁判所に言われる

>>そんなバカな話有るか
>>排他制御を要求しなかったユーザが悪いだろ
>実際の裁判事例いくつかあるよ
>システム開発会社は専門家なんだから当然考慮すべき範疇のことを考えるのは契約書に書かれて無くても期待されうる役割だよって裁判所に言われる
ソースあんならすぐ出せ

>プレイヤーA：ミュウツーを送る
>プレイヤーB：コラッタを送る
>プレイヤーA：ミュウツーを受けとる
>プレイヤーB：コラッタを受…電源を切る！
>プレイヤーA：レポートを書く
>プレイヤーB：交換前の状態をロード
問屋は本を送ったのに問屋の在庫は減らない
みんな幸せになる

>そんなバカな話有るか
>排他制御を要求しなかったユーザが悪いだろ
既に判例がある
ユーザはシステム構築において素人なんだし在庫管理システムで排他制御を考えるのは当たり前の話だからそれを実装してないのはシステム会社側の落ち度って判断される
在庫管理をしたいって目的を達成できてないよね？排他制御を考えるのは当たり前でしょってのが裁判所の判断

>こういうのはもう共通規格でテンプレみたいなの出来てないの？
ライトなやつならkintoneとかで実装かな

>ソースあんならすぐ出せ
pl/sql

>今はオンラインでデータベース噛ませるから
そんなことしてないよローカル通信だけで交換できるし
タイミングがシビアなのと不正終了した人はペナルティで30分ぐらい通信できなくなる

>>ソースあんならすぐ出せ
>pl/sql
ぐはっ
俺の負けだ

こんなだから本屋は滅びる

>>>そんなバカな話有るか
>>>排他制御を要求しなかったユーザが悪いだろ
>>実際の裁判事例いくつかあるよ
>>システム開発会社は専門家なんだから当然考慮すべき範疇のことを考えるのは契約書に書かれて無くても期待されうる役割だよって裁判所に言われる
>ソースあんならすぐ出せ
https://atmarkit.itmedia.co.jp/ait/articles/1411/04/news020.html
アカウント登録とDLが必要だがDLできるPDFの39ページあたりを見てみな
こっちは排他制御のかけ方がおかしくて同時に発注を乞萎えるのは一人だけ見たいな実装をしたシステム会社が敗訴している事例が説明されてる

そういやヨドバシで漫画本注文して受注完了メールも届いたのに翌々日くらいに「やっぱ確保出来なかったからキャンセル」って電話が来た事あったな
あそこは取り寄せ商品は最初からそういうシステムだけど問題の本は普通に在庫がある表記だったからビックリした

>プレイヤーA：ミュウツーを送る
>プレイヤーB：コラッタを送る
>プレイヤーA：ミュウツーを受けとる
>プレイヤーB：コラッタを受…電源を切る！
>プレイヤーA：レポートを書く
>プレイヤーB：交換前の状態をロード
これってビットコインとか電子マネーで応用できない？

少なくとも昨今の発注システムにおいて排他制御はデフォルトで備わっておくべきものだから
「言われなかったからつけませんでした！」はもう通らないだろうな

>そういやヨドバシで漫画本注文して受注完了メールも届いたのに翌々日くらいに「やっぱ確保出来なかったからキャンセル」って電話が来た事あったな
>あそこは取り寄せ商品は最初からそういうシステムだけど問題の本は普通に在庫がある表記だったからビックリした
システムエラーの可能性もあるが万引きされて在庫がないケースもあるからな…

去年くらいにあったコンビニで別人の住民票が出てきたのも排他制御の問題?

電子書籍ならこんなこと起きなかったのに…

１冊足りない程度なら出版社が追加でサッと刷ってスイと届けてくれればいいよね

>こういうのはもう共通規格でテンプレみたいなの出来てないの？
今はどっかの会社が作ったテンプレを使うパッケージ開発が主流だと思う
顧客要望のカスタマイズでテンプレの原型が残らなくなることもよくある

今はもう古いシステムの改修とかだと1から作った方が早いってケースが多そう

基本裁判所はベンダー側がプロジェクトを適正に管理して一般的に満たすべき品質を満たしていれば多少の障害や遅延ががあって損害賠償を起こされてもベンダー有利の判決を出してくれる

>>こういうのはもう共通規格でテンプレみたいなの出来てないの？
>今はどっかの会社が作ったテンプレを使うパッケージ開発が主流だと思う
>顧客要望のカスタマイズでテンプレの原型が残らなくなることもよくある
システムに合わせて業務を改革することでコストミニマムで導入することができます！

日本企業の悪い癖だよ！
パッケージあるのに業務に合わせてパッケージの魔改造をさせようとするのは！

>システムに合わせて業務を改革することでコストミニマムで導入することができます！
沈黙する業務チーム

>そこまで金掛ける価値もねえんだ
>現場で一手間増やしてくれ

システム入れ替えで同時入力でエラーになるから排他できるように要求したら担当にそう言われて却下されたわ
ＤＸしてなんで以前のシステムより退化してんだよクソが

運用でカバー

>去年くらいにあったコンビニで別人の住民票が出てきたのも排他制御の問題?
秒までの時刻で通番管理してたみたいなクソボケ設計じゃなかったか

>今はもう古いシステムの改修とかだと1から作った方が早いってケースが多そう
古いシステムを改修するからソース渡すね！仕様書はないし業務データも渡せないけど！はあったな…

言っちゃなんだけど本なんて保存が（比較的）効くだけマシな方なんだ
食品の受発注とか悲惨だぞ

>>プレイヤーA：ミュウツーを送る
>>プレイヤーB：コラッタを送る
>>プレイヤーA：ミュウツーを受けとる
>>プレイヤーB：コラッタを受…電源を切る！
>>プレイヤーA：レポートを書く
>>プレイヤーB：交換前の状態をロード
>これってビットコインとか電子マネーで応用できない？
本体の電源が消えようがサーバーにミュウツーとコラッタの交換履歴は残ってるぜ残念だったな！

>去年くらいにあったコンビニで別人の住民票が出てきたのも排他制御の問題?
排他と言えば排他だな…DBではなくてファイルだったはず

>食品の受発注とか悲惨だぞ
プッチンプリンが！

>>食品の受発注とか悲惨だぞ
>プッチンプリンが！
あれどうなったんだろうな
もう直った？

>秒までの時刻で通番管理してたみたいなクソボケ設計じゃなかったか
聞いた時正気か？って思った仕様

金融と医療じゃなくて本当に良かった

スレ画読んで気になるのは発注履歴に「本が発送されました」って出るまでどのぐらいの時間かかるかだな

>去年くらいにあったコンビニで別人の住民票が出てきたのも排他制御の問題?
A「住民票だして」
システム「りょ」
B「住民票だして」
システム「りょ」
システム「じゃあBさんの出しますね」
A「誰よこいつ！」

>>去年くらいにあったコンビニで別人の住民票が出てきたのも排他制御の問題?
>排他と言えば排他だな…DBではなくてファイルだったはず
住民票画像_YYYYMMDDHHMMSS.jpg とかいうキャッシュファイル作ったら何故か被っちゃってぇ…

子供へのプレゼントで普通に予約して買っただけで滅茶苦茶言われてんのかわいそう

テスト運用とかやってそこで気付いたりとかは？

>>>食品の受発注とか悲惨だぞ
>>プッチンプリンが！
>あれどうなったんだろうな
>もう直った？
昨日から復活した
まあグリコ自体は一時的な被害だけでほぼノーダメだろうけど
原料や卸は…

やっぱり受注業務はFAX&入力のおばちゃんの方が信頼できるよな

>住民票画像_YYYYMMDDHHMMSS.jpg とかいうキャッシュファイル作ったら何故か被っちゃってぇ…
ハッシュ衝突を経験した身なので笑えない

(まっさか秒単位で同時に出すやつはおらんだろ…)とでも思ったかバカめ！

>>秒までの時刻で通番管理してたみたいなクソボケ設計じゃなかったか
>聞いた時正気か？って思った仕様
こういう時はRDBのsequenceやauto numberやUUIDと使うのものじゃないの…？

>テスト運用とかやってそこで気付いたりとかは？
この動作は仕様通りです
運用でカバーできます

>住民票画像_YYYYMMDDHHMMSS.jpg とかいうキャッシュファイル作ったら何故か被っちゃってぇ…
まさか同じ時間に住民票を出す人が複数いるとは思わなくってぇ…

>(まっさか秒単位で同時に出すやつはおらんだろ…)とでも思ったかバカめ！
大事なシステムなら0.1秒単位にするよね

>まあグリコ自体は一時的な被害だけでほぼノーダメだろうけど
いやいや普通にとんでもない額だぞ

>大事なシステムなら0.1秒単位にするよね
クソボケがーっ！

>>(まっさか秒単位で同時に出すやつはおらんだろ…)とでも思ったかバカめ！
>大事なシステムなら0.1秒単位にするよね
シーケンス使え！

>>(まっさか秒単位で同時に出すやつはおらんだろ…)とでも思ったかバカめ！
>大事なシステムなら0.1秒単位にするよね
>(まっさか0.1秒単位で同時に出すやつはおらんだろ…)とでも思ったかバカめ！

>>まあグリコ自体は一時的な被害だけでほぼノーダメだろうけど
>いやいや普通にとんでもない額だぞ
工場止めてた分の損害と人件費ヤバそう

尼で予約したのにkonozamaしたのも…？

うーん…住民票なんて滅多に出さないよね
秒単位の管理でいっか

>>>(まっさか秒単位で同時に出すやつはおらんだろ…)とでも思ったかバカめ！
>>大事なシステムなら0.1秒単位にするよね
>>(まっさか0.1秒単位で同時に出すやつはおらんだろ…)とでも思ったかバカめ！
じゃあ0秒で！

>やっぱり受注業務はFAX&入力のおばちゃんの方が信頼できるよな
こういう露骨な極論はともかく受発注は双方がシステム導入してないと意味ねぇってのがとにかくキツイ
世間的には結構有名なメーカーがFAXでしか注文受けてないとかザラ

工場止めてると動かす時もまたえらい大変だしな

（このプログラムどうせ俺しか使わないし同時とかは考えなくてもいいだろ…）

>うーん…住民票なんて滅多に出さないよね
>秒単位の管理でいっか
せめてUUID使えや！

主キーという概念はないのです？

取り寄せたこち亀とゴルゴの既刊全部ラッピングにしてくれは流石に断ったな
本社にクレーム入って始末書と減俸になったけど

>まあグリコ自体は一時的な被害だけでほぼノーダメだろうけど
売上高が200憶下方修正されたっぽい

>（このプログラムどうせ俺しか使わないし同時とかは考えなくてもいいだろ…）
（ソース流用されてエラいことになる）

>取り寄せたこち亀とゴルゴの既刊全部ラッピングにしてくれは流石に断ったな
>本社にクレーム入って始末書と減俸になったけど
それシステムと関係ある？

>主キーという概念はないのです？
社内システムとかだと頭に社員番号とかつければ重複はかなり防げるが住民票ってこともあってID的なものがないからな

ITエンジニアだけど在庫管理とか絶対やりたくない
SKUとか地獄だと思う
DB内で完結する話でもきちんとロックとか考えないといけないのにさらに物理要素が絡んでくる

>>まあグリコ自体は一時的な被害だけでほぼノーダメだろうけど
>売上高が200憶下方修正されたっぽい
じゃあ棚から消えるかって言われるとそんな事は無いのは三幸製菓の時に学んだ
どうせ来年には元通りだよ

>それシステムと関係ある？
漫画の話じゃない？

どのくらいの規模の企業から業務システムを自社開発なのかあんまり肌感無い
大企業でも電算部門なかったりする？

プログラムは趣味でやるに限る…

注文確定するのがおかしいんだよなあ

まぁ在庫とか……めんどくさいよ……

A「注文します」
Aシステム「在庫まだあるヨシ！注文受付完了しました！」
B「注文します」
Bシステム「在庫まだあるヨシ！注文受付完了しました！」
Aシステム「在庫ください！」
在庫「ヘイ最後の一冊ね！！」
Bシステム「在庫ください！」
在庫「そんなもの…うちにはないよ…」

独自BtoBやってるとこは大体似たような問題抱えてるよね
更に直営店持ち問屋だったりすると直営店が最上位に設定されてたり

>在庫「そんなもの…うちにはないよ…」
在庫「でも注文は確定したよ！やったね！」

>取り寄せたこち亀とゴルゴの既刊全部ラッピングにしてくれは流石に断ったな
>本社にクレーム入って始末書と減俸になったけど
お渡し明日になってもよろしいのでしたら…とか
ラッピング用の在庫が足りませんので…とかのやり取りなしで断ったの？

まさか有権者が秒単位で同時に投票することは想定できず無効票が発生してしまいました
心よりおわり申し上げます

物流って毎日これあんの？大丈夫？

>まさか有権者が秒単位で同時に投票することは想定できず無効票が発生してしまいました
>心よりおわり申し上げます
おわるな

>プログラムは趣味でやるに限る…
小規模なシステムだったら楽しいよ
ネットワーク系には手を出しちゃあかん

>物流って毎日これあんの？大丈夫？
ジャストインタイムを心がけております！

>物流って毎日これあんの？大丈夫？
真っ当なシステムはちゃんと排他制御してるよ！

>No.1219567180
これって普通に……問い合わせ元の媒体に問い合わせた情報返すのじゃ駄目なのか？
問い合わせ先が単一化されてるように見えるんだが

>物流って毎日これあんの？大丈夫？
食品とかでこんなんやったら即死だし流石にないよ
良くも悪くも緩くないとこんな事起きない

>独自BtoBやってるとこは大体似たような問題抱えてるよね
>更に直営店持ち問屋だったりすると直営店が最上位に設定されてたり
昔関わったスポーツ用品メーカーだと営業が自分の担当顧客にいい顔するためだけに在庫を抱え込み合うナワバリバトルやってて傍から見てる分には面白かった

本屋だと丸善蔦屋あたりは下請けはいても自前かね

>取り寄せたこち亀とゴルゴの既刊全部ラッピングにしてくれは流石に断ったな
割と真面目にこのサービスを現場でやるの止めた方が良いと思う
大量に要求された時の対処どうしようもないし

スレ画みたいな時って電子書籍勝手に印刷して自前で製本して売ったら違法になる？

食品通販はお届け日に遊び作ってたな…
足りないこととか入れた食品に瑕疵あることもザラだし遅れても良い設計になってた

>スレ画みたいな時って電子書籍勝手に印刷して自前で製本して売ったら違法になる？
昔の中古ゲーム屋みてえなこと言ってんじゃねえぞ！

>>取り寄せたこち亀とゴルゴの既刊全部ラッピングにしてくれは流石に断ったな
>割と真面目にこのサービスを現場でやるの止めた方が良いと思う
>大量に要求された時の対処どうしようもないし
注意書きで何冊までとか何冊以上は要予約(別途追加料金)とか書くしかない

ジュンク堂と丸善のシステムはおなじところが担当してるんじゃねえかな…とおもいながらいつも店舗内の在庫確認してる

>昔の中古ゲーム屋みてえなこと言ってんじゃねえぞ！
説明書の思い出がよみがえってきた

>>クラウドでNoSQLなDBとかだときがるに扱って良いものではないなとくるしむ
>えっ？在庫管理をNoSQLで…？！
色々制限あって同時注文されてもどうにかなるようにやったことあるけどまぁアンチパターンだよね
めっちゃRDS使いたかった

大量に本買ってカバーしてくれ→今日は無理です
でキレ散らかす客も居ないとは言い切れないのが怖いな

>スレ画みたいな時って電子書籍勝手に印刷して自前で製本して売ったら違法になる？
そこまでできんなら本屋やめて印刷屋やれ

>こういうのを回避するときはシステム屋さんはどういう感じにするの？
🙇する

>>こういうのを回避するときはシステム屋さんはどういう感じにするの？
>🙇する
前屈みになって必死にコード書く人

営業とユーザー担当にまかせときゃ
ええ！