주소를 street/city/state/zip으로 구분합니까?

현재 앱에 사용자의 주소 정보를 저장해야합니다. 저는 현재 관행적인 거리 주소/도시/주/우편 텍스트 상자 및 드롭 다운을 사용할지 아니면 단순히 한 줄에 모든 것을 사용하는 Google의 방법을 사용할지에 대해 토론하고 있습니다. 이러한 방법 중 하나에 주소 정보를 저장하는 데 찬반 양론에 대한 의견은 있습니까?주소를 street/city/state/zip으로 구분합니까?

출처

2008-10-30 Kevin Pang

정확한 파싱이 중요하지 않은 경우에만 Google에서 하나의 상자 모델을 사용합니다 (예 :지도). Checkout의 경우에도 여전히 다른 입력란을 작성해야합니다. – albertb

@albertb 계산을 위해 입력 필드를 분할 할 필요는 없습니다. [이 게시물은 UX.SE] (http://ux.stackexchange.com/questions/22196/combining-all-the-address-fields-into-one) 및 [자유형 주소를 구문 분석하는 방법에 관한이 기사를 참조하십시오. http://stackoverflow.com/questions/11160192/how-to-parse-freeform-street-postal-address-into-components) * 할 수 있고, 안정적으로 수행 할 수 있습니다. – Matt

분할해야합니다. 길을보고하는 것이 훨씬 쉬워 질 것입니다. 주 또는 우편 번호 또는 도시의 모든 거주자를 끌어 올리려면 어떻게됩니까? 하나의 필드를 모두 사용하면 문제가 생길 수 있습니다.

또한 사용자는 메시지를 표시하지 않으면 필요한 모든 정보를 입력하는 것을 잊어 버릴 수 있습니다. 게시물에 사용자가 입력 태그에 의해 판단

출처

2008-10-30 03:00:51

, 난 당신이 사용자 가 데이터를 입력하는 방법을 언급하는 가정, 그리고 지금 당신이 얼마나 는 백 엔드 데이터베이스에 데이터를 저장.

정보를 정렬하고 분석하려는 경우 (예 :보고 및 통계 목적으로) 데이터베이스에서이 정보를 별도의 입력란으로 저장해야 할 수 있습니다.

이 경우에는 주소 지정 정보를 개별 필드로 올바르게 구문 분석 할 수 있다고 확신하는 것이 얼마나 중요한지 생각합니다.

하나의 하이브리드 옵션은 사용자가 주소를 한 줄로 입력 한 다음 정보를 최선의 노력으로 개별 필드로 구문 분석하도록 허용하는 것입니다. 이는 Outlook에서 연락처 주소를 관리하는 방법과 비슷합니다. 모든 정보를 하나의 메모 필드에 입력 한 다음 사용자를 위해 정보를 분할합니다. 그런 다음 필드가 잘못 해석 된 경우이를 수정할 수 있습니다.

출처

2008-10-30 03:03:43 LeopardSkinPillBoxHat

제 의견으로는, 하이브리드 방법이 갈 길입니다. 배송 된 물건이 없는데 주소가 올바르게 파싱되지 않는 한, 제대로 설계되지 않은 사이트에서 내 주소를 나눠야합니다. – albertb

나는 이것을 분할하는 경향이있어 주소의 특정 섹션에 대해 검색을 수행 할 수 있으며 형식 지정, 즉 동해안 지역에만 배송 할 수 있으므로 처리 할 주소를 제한 할 수 있습니다.

출처

2008-10-30 03:04:18 Jiminy

나중에 검색 할 때와 마찬가지로 입력 내용을 처리하는 방법과 관련이 없다고 동의하십시오. – Riri

나는 사용자가 자신의 주소를 입력하는 단일 텍스트 필드를 사용하는 것에 대해서 매우 반대합니다. 특정 분야가없는 경우 얼마나 많은 사람들이 우편 번호 나 기타 중요한 정보를 남기지 않을지 놀랄 것입니다. 또한 다른 사람들이 언급했듯이 모든 데이터가 미리 파싱 된 경우 나중에이 정보를보고하는 것이 훨씬 쉽게보고됩니다. 다른 사용자가 언급 한 것처럼 Outlook과 같은 프로그램은이 정보를 구문 분석하지만 데이터 원본이 전자 메일의 서명 인 경우가 많기 때문에이 정보는 일관된 형식이 아닙니다.

출처

2008-10-30 03:08:56 Kibbee

1) 분할해야합니다.

2) 국제 주소 입력을 시도하기 전에 this을 읽어 보시기 바랍니다.

출처

2008-10-30 05:52:58 Claudiu

그 기사에 의존하지 마십시오. 작가는 문제를 이해하지만 세부 사항의 절반이 잘못되었습니다. –

@Windows 프로그래머 : 어느 쪽이 좋습니까? @Claudiu : +1 다른 주소 형식을 언급하기 위해 +1 – Treb

나는 Kibbee와 동의한다. 나는 사람들이 이름과 성, 우편 번호, 도시 등을 뒤집어 쓰는 필드의 라벨을 읽지 않는 것을보고 놀랐다.
아니요, 웹 애플리케이션 타겟팅에서 우편 번호가 유효한지 여부를 결정할 수 없습니다. 국제 고객 ...
일부 국가는 우편 번호, 다양한 길이, 상태 정보 없음 등의 알파 문자를 사용합니다.

출처

2008-10-30 06:57:03 PhiLho

일부 국가의 우편 번호의 유효성을 검사 할 수도 있지만 데이터 원본에 올바른 코드가 있다는 보장이 없으므로 규칙이 아니라 지침이어야합니다. 우리 마을은 한 우편 번호에서 두 우편 번호로 나뉘었다. 내 것은 똑같이 머물렀다. 그러나 몇몇 사이트는 그것이 바뀌 었다고 생각했다. ... –

... 그리고 나는 그것을 정정하게하지 않고, 그들에게 우편 번호가 틀렸다는 것을 설명 할 수없는 소수의 사람들과 접촉해야하는 것이 매우 실망했다. –

명확하게 입력을 분할합니다. 도움이 될 수 있으며 비즈니스 요구 사항에 따라 입력 시점에서 주소 확인을 수행하는 것이 좋습니다.이렇게하면 주소가 데이터베이스에 그대로 있다는 것을 알 수 있습니다 및 사기 방지와 같은 여러 가지 작업을 수행 할 수 있습니다. 확인 된 주소가 있으면 실제 상품을 고객에게 운송하는 경우 운송 비용을 줄이는 데 도움이되며 AVS 확인 중에 정확한 ZIP 코드가 제출되도록하여 신용 카드 판매자 수수료를 줄일 수 있습니다.

전체 공개의 목적으로, 나는 SmartyStreets의 설립자입니다. 우리는 CASS-certified address verification 서비스를 제공합니다. 사용자는 list for scrubbing (CSV/Excel/etc.)을 웹 사이트에 업로드하거나 address verification web service API LiveAddress를 사용할 수 있습니다.

출처

2011-10-13 04:18:58

주소를 street/city/state/zip으로 구분합니까?

답변

관련 문제