1
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 5 years have passed since last update.

住所入力欄を適当に分けると痛い目に合う話

Posted at

よくあるやつ。
Webの問い合わせだったり受発注だったりの受付フォームで住所を入れる項目があるけど、あれ事細かに分かれてる場合ありますよね、あれは良くないと思った。

結論:これでいいのでは

自分ならこうする。

  • 都道府県(プルダウン必須)
  • 市区町村・番地(テキスト必須)
  • 建造物名・部屋番号(テキスト任意)

何の話

今あるWebアプリの住所入力欄が

  • 都道府県(プルダウン必須)
  • 住所1(テキスト必須)
  • 住所2(テキスト任意)

っていう入力欄になっていて、それぞれの項目に入っている内容が、レコードごとにバラバラになってる

何が起きたか

例えば、住所の入力されるパターンとして

  • 住所1:市区町村 番地 建造物名 部屋番号 / 住所2:空欄
  • 住所1:市区町村 番地 / 住所2:建造物名 部屋番号
  • 住所1:市区町村 / 住所2:番地 建造物名 部屋番号
  • 住所1:市区 / 住所2:町村 番地 建造物名 部屋番号

みたいなことになる。

ひどいパターンになると、

  • 住所1:市区 / 住所2:番地

みたいなエラーデータを誘発する。
この話に関しては今回言いたいことからは外れるのでこれ以上は書かない。

ここで問題になるのが、例えば戸建ての住所で

  • 住所1:市区町村 / 住所2:番地

になった場合の住所2の扱い。

例えば、「2000-10-1」のようなデータが入ったとしよう
そして顧客管理部門の人間はコンピュータに不慣れなのでExcelでデータを管理したいと言い出したとしよう

察しのいい人はお分かりと思う

Excelが得意げに日付データとして解釈し、うまく動かない(=住所へ送付物を出そうとしたのにあて先不明のオンパレード)となるのだ

これに限らず、数字記号のみのデータの形式を勝手に解釈して入れ込んでしまうトラブルは山のようにあると思う。
機能単体で見ると便利なんだけど、こういう場合は悪さをした話しか聞かないのはなんでだろう。

あとこのWebアプリをこの設計にしたやつはちょっとそこに正座しよう。おじさん怒らないから。

1
2
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?