오늘은 좀 재밌는 일이 벌어졌다.
엘라스틱서치를 결국 도입하게 될 것 같다^^;;
어제 거의 새벽 1시까지 작업을 한게 도움이 됐다!!!!
커뮤니티비용이 많이 들 것 같은데요?
나도 저 부분에 있어서 고민을 계속 했다, 우리가 주소검증을 하지 않는다면?
택배를 발송할 때 주소검증이 택배사에 의하여 한번 이뤄지는데, 여기서 문제가 발생했다고 가정하자.
그럼 판매자는 출고요청을 한 시기와는 무관하게 발송이 이루어지는 날 문제를 확인할 수 있다.
그러면 발송시간이 딜레이가 걸릴 것이고, 구매자는 해당 판매자를 신뢰할 수 없을 것이다.
또한 우리 매니저분들이 판매자와 컨텍을 해야할 것이고,
주소를 업데이트해달라고 확인을 요청하고 발송을 할 때 다시 택배사에 의하여 검증이 이뤄진다.
이러면 안된다, 주소가 글러먹었으면 사전에 차단해주는게 무조건 맞고 거기서 수정을 하게 만들어야한다.
결국은 휴먼에러라는 것을 방지하기 위해서는 사람이 건드리는 일을 줄이는 것이 최선이다.
즉 주소검증은 무조건 해야한다.
휴먼에러를 코드로 잡는게 말이 돼?
안돼
주소라는 것은 상당히 복잡한 구조를 가지고 있다.
여기서 일반적으로 주소는 행정단위부 + 번지부 / 기타부로 2개를 분리해서 보는 편이다.
(이것은 네이버쇼핑에서의 주소검색 설명, 자세하게 적어야한다는 것을 볼 수 있다.)
여기서 정말 중요한 것은 번지부다.
어떤 동네인지는 행정단위부로 확인할 수 있지만, 어떤 건물인지 판단하는 것은 번지부이기 때문인데....
문제는 입력값에, 행정단위부와 번지부가 붙어있는 경우다.
행정단위부는 100% 5개 중 한개로 끝난다.
- 로
- 길
- 가
- 동
- 리
번지부는 무조건 숫자로 시작하고, 숫자로 끝난다.
- 15
- 2724
- 792-791
어! 뭐야, 그럼 그냥 위에 다섯개 중에 숫자가 붙어있으면 걍 떨어트리면 안돼요?
응 안돼
바로 ~로000번길이라는 도로명이 존재한다 -_-
그래서 이거때문에 진짜 많은 문제가 발생한다.
주소체계 누가만들었냐 진짜 이런 중복사유는 없게 만들어야하는거아닌가?????
네이버에서만 몇번 눌러봐도 확인할 수 있는데, 위에 보인김에 저걸로 좀 꾹꾹눌러봤다.
고양대로2002ㅁ번길70-62
정상주소
비정상주소
-_- 이정도 보면 네이버급에서도 어떤 기준으로 구분을 하는지 보인다.
숫자 앞에 로가 무조건 있고, 그 뒤에 번이 존재해야한다.
비스무레한 정규식을 짤 수 있었는데.... 문제는 띄어쓰기다.
모든 것을 충족하면서 띄어쓰기까지 오류를 잡아줄 수 있는 정규식을 짜면 좋겠는데
3시간 4시간 고민을 해도 저거까지는 못잡겠더라 진짜(병걸릴거같음)
아무튼 거의 완성은 해가지고... 내일 사무실 출근해서 검증좀 해봐야겠다...
에휴 정규식
자야지 오늘도 12시 넘었네
