アカウント名:
パスワード:
重複予約の回避は色々なしがらみで難しかったかもしれない。でも、市区町村コードなんて一覧がある [soumu.go.jp]のだから、チェック機能入れるだけじゃないの？と思う。誰が設計したんだ、これ。
市町村コードくらいはチェックしろというのは同意します。その上で、なんですが……ただ「チェック機能入れるだけ」では済まなくて、都度更新されるので、過去のマスタも保持する必要があり、ちゃんと設計しようとすると面倒なことになります。面倒を避けるために国交省や農水省が公開している電子納品チェックシステムは定期的にブランチ切ってコードフリーズみたいなことをやってますね。いずれにしろコードの一覧が公開されている以上、悪意のある入力を弾くことはできないので、誤入力対策でしかないのは留意する必要があります。
市町村コードくらいはチェックしろというのは同意します。その上で、なんですが……ただ「チェック機能入れるだけ」では済まなくて、都度更新されるので、過去のマスタも保持する必要があり、ちゃんと設計しようとすると面倒なことになります。
市町村コードって合併とかあったら変わるもんでしょ？センターの運用期間内（2年くらいか）に合併がなさそうなら無視していいんじゃない？
合併があったらそんとき手作業で変えればいい
そういうの全部ひっくるめた上で雑な運用をするというのなら、それはそれでアリ。
一度そういう検討を経て、市町村合併でコードが一致しない事象も発生し得ることが分かっていれば、バリデーションチェックで引っ掛かったときに「未知のコードが入力されました。この現象は市町村合併で生じることがあります。本当にこのまま送信しますか？」といった警告で通す設計も考えられる。
何も考えずに、ただ市町村コードをチェックしろみたいなのが一番ダメ。事前に想定したコード以外は絶対に通さないクソシステムの出来上がり。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲはアレゲを呼ぶ -- ある傍観者
市区町村コードくらいは (スコア:0)
重複予約の回避は色々なしがらみで難しかったかもしれない。
でも、市区町村コードなんて一覧がある [soumu.go.jp]のだから、チェック機能入れるだけじゃないの？と思う。
誰が設計したんだ、これ。
Re: (スコア:0)
市町村コードくらいはチェックしろというのは同意します。その上で、なんですが……
ただ「チェック機能入れるだけ」では済まなくて、都度更新されるので、過去のマスタも保持する必要があり、ちゃんと設計しようとすると面倒なことになります。
面倒を避けるために国交省や農水省が公開している電子納品チェックシステムは定期的にブランチ切ってコードフリーズみたいなことをやってますね。
いずれにしろコードの一覧が公開されている以上、悪意のある入力を弾くことはできないので、誤入力対策でしかないのは留意する必要があります。
これくらい雑な運用でええやろ (スコア:0)
市町村コードくらいはチェックしろというのは同意します。その上で、なんですが……
ただ「チェック機能入れるだけ」では済まなくて、都度更新されるので、過去のマスタも保持する必要があり、ちゃんと設計しようとすると面倒なことになります。
市町村コードって合併とかあったら変わるもんでしょ？
センターの運用期間内（2年くらいか）に合併がなさそうなら無視していいんじゃない？
合併があったらそんとき手作業で変えればいい
Re:これくらい雑な運用でええやろ (スコア:0)
そういうの全部ひっくるめた上で雑な運用をするというのなら、それはそれでアリ。
一度そういう検討を経て、市町村合併でコードが一致しない事象も発生し得ることが分かっていれば、バリデーションチェックで引っ掛かったときに「未知のコードが入力されました。この現象は市町村合併で生じることがあります。本当にこのまま送信しますか？」といった警告で通す設計も考えられる。
何も考えずに、ただ市町村コードをチェックしろみたいなのが一番ダメ。事前に想定したコード以外は絶対に通さないクソシステムの出来上がり。