데이터베이스 (RDBMS)에 우편 주소를 저장하는 모범 사례?

데이터베이스 (RDBMS)에 우편 주소를 저장하는 모범 사례?

---

RDBMS에 우편 주소를 저장하는 모범 사례에 대한 좋은 참조가 있습니까? 만들 수있는 많은 장단점이 있고 각각에 대해 많은 장단점을 평가해야하는 것 같습니다. 확실히 이것은 몇 번이고 반복 되었습니까? 누군가 적어도 어딘가에서 배운 교훈을 쓴 적이 있습니까?

내가 말하는 절충점의 예는 우편 번호를 정수 대 문자 필드로 저장하는 것입니다. 집 번호를 별도의 필드 또는 주소 행 1의 일부로 저장해야하는지, 스위트 / 아파트 / 기타 번호가 정규화되거나 주소 줄 2의 텍스트 덩어리, zip +4 (별도 필드 또는 하나의 큰 필드, 정수 대 텍스트)를 어떻게 처리합니까? 기타

저는이 시점에서 주로 미국 주소에 관심이 있지만 글로벌화의 결과에 대비하기위한 몇 가지 모범 사례가 있다고 생각합니다 (예 : 우편 번호 대신 주 또는 우편 번호 대신 지역과 같은 필드 이름 지정, 기타

---

더 많은 국제적 사용을 위해 고려할 하나의 스키마는 Drupal 주소 필드에서 사용하는 스키마 입니다. xNAL 표준을 기반으로하며 대부분의 국제 사례를 다루는 것으로 보입니다. 이 모듈을 조금만 파헤쳐 보면 국제적으로 주소를 해석하고 검증 할 수있는 좋은 진주가 나올 것입니다. 또한 ISO 코드가있는 멋진 행정 구역 (도, 주, 주 등)이 있습니다.

다음은 모듈 페이지에서 복사 한 스키마의 요점입니다.

country => Country (always required, 2 character ISO code)
name_line => Full name (default name entry)
first_name => First name
last_name => Last name
organisation_name => Company
administrative_area => State / Province / Region (ISO code when available)
sub_administrative_area => County / District (unused)
locality => City / Town
dependent_locality => Dependent locality (unused)
postal_code => Postal code / ZIP Code
thoroughfare => Street address
premise => Apartment, Suite, Box number, etc.
sub_premise => Sub premise (unused)

내가 배운 교훈 :

• 숫자로 아무것도 저장하지 마십시오.
• 가능한 경우 국가 및 행정 구역을 ISO 코드로 저장하십시오.
• 모를 때는 필드 요구에 대해 느슨해 지십시오. 일부 국가에서는 locality& 와 같은 기본적인 것조차도 당연하게 여기는 필드를 사용하지 않을 수 있습니다 thoroughfare.

---

'국제'사용자로서 미국 형식 주소만을 지향하는 웹 사이트를 다루는 것보다 더 실망스러운 것은 없습니다. 처음에는 약간 무례하지만 유효성 검사도 지나치게 열성적 일 때는 심각한 문제가됩니다.

글로벌화에 관심이 있으시다면 제가 할 수있는 유일한 조언은 자유 형식을 유지하는 것입니다. 국가마다 규칙이 다릅니다. 일부에서는 집 번호가 거리 이름 앞에 나오고 일부에서는 그 뒤에옵니다. 일부에는 주, 일부 지역, 일부 카운티, 일부 조합이 있습니다. 여기 영국에서는 우편 번호가 우편 번호가 아니라 문자와 숫자가 모두 포함 된 우편 번호입니다.

우편 번호에 대한 별도의 필드와 함께 ~ 10 줄의 가변 길이 문자열을 권장합니다 (국가적 감수성에 대처하기 위해이를 설명하는 방법에주의하십시오). 사용자 / 고객이 주소 작성 방법을 결정하게하십시오.

---

"half-numbers"또는 "129A"와 같은 내 현재 주소와 같은 특수한 경우 때문에 집 번호를 숫자가 아닌 문자 필드로 저장하는 것을 확실히 고려해야합니다. 그러나 A는 아파트로 간주되지 않습니다. 배달 서비스 번호.

---

다른 국가에서 우편 주소를 사용하는 방법에 대한 포괄적 인 정보가 필요한 경우 다음은 매우 좋은 참조 링크입니다 (Columbia University).

우편 주소에 대한 Frank의 강박 지침 효과적인 국제 우편 주소
지정

---

저는이 작업을 수행했으며 (데이터베이스에서 주소 구조를 엄격하게 모델링), 다시는하지 않을 것입니다. 일반적으로 고려해야 할 예외가 얼마나 미친 지 상상할 수 없습니다.

나는 노르웨이 우편 번호 (내 생각에)와 관련된 문제를 모호하게 기억한다. (내 생각에는) 18 개 정도의 오슬로를 제외하고 모두 4 개 위치였다.

나는 우리가 모든 국가 주소에 대해 지리적으로 정확한 우편 번호를 사용하기 시작한 순간부터 꽤 많은 사람들이 그들의 우편물이 너무 늦게 도착했다고 불평하기 시작했다고 확신합니다. 그 사람들은 우편 지역 사이의 경계선 근처에 살고 있었고 누군가가 실제로 우편 지역 (예 : 1600)에 살았음에도 불구하고 실제로 그의 우편물은 우편 지역 1610으로 발송되어야합니다. 왜냐하면 실제로는 이웃 우편 지역 이었기 때문입니다. 우편물을 올바른 우편 지역으로 보내면 우편물을 잘못된 우편 지역으로 전달하기 위해 올바른 우체국에서 원치 않는 개입이 필요했기 때문에 우편물이 도착하는 데 며칠 더 걸릴 것입니다.

(우리는 ISO 코드 'ZZ'로 국가에 해외 주소를 가진 사람들을 등록했습니다.)

---

" 이것이 관계형 데이터베이스에서 주소 정보를 모델링하는 좋은 방법입니까? "를 반드시 참조해야 하지만 귀하의 질문은 그것과 직접적으로 중복되지 않습니다.

분명히 많은 기존 답변이 있습니다 (예 를 들어 DatabaseAnswers 에서 예제 데이터 모델 확인 ). 기존 답변의 대부분은 일부 상황에서 결함이 있습니다 (DB Answers를 전혀 선택하지 않음).

고려해야 할 한 가지 주요 문제는 주소 범위입니다. 데이터베이스가 국제 주소를 처리해야하는 경우 한 국가의 주소 만 처리해야하는 경우보다 더 유연해야합니다.

In my view, it is often (which does not mean always) sensible to both record the 'address label image' of the address and separately analyze the content. This allows you to deal with differences between the placement of postal codes, for example, between different countries. Sure, you can write an analyzer and a formatter that handle the eccentricities of different countries (for instance, US addresses have 2 or 3 lines; by contrast, British addresses can have considerably more; one address I write to periodically has 9 lines). But it can be easier to have the humans do the analysis and formatting and let the DBMS just store the data.

---

Unless you are going to do maths on the street numbers or zip / postal codes, you are just inviting future pain by storing them as numerics.

You might save a few bytes here and there, and maybe get a faster index, but what do you when US postal, or whatever other country you are dealing with, decides the introduce alphas into the codes?

The cost of disk space is going to be a lot cheaper than the cost of fixing it later on... y2k anybody?

---

Ive found that listing all possible fields from smallest discrete unit to largest is the easiest way. Users will fill in the fields they see fit. My address table looks like this:

*********************************
  Field              Type
*********************************
  address_id (PK)    int
  unit               string
  building           string        
  street             string
  city               string
  region             string
  country            string
  address_code       string
*********************************

---

Adding to what @Jonathan Leffler and @Paul Fisher have said

If you ever anticipate having postal addresses for Canada or Mexico added to your requirements, storing postal-code as a string is a must. Canada has alpha-numeric postal codes and I don't remember what Mexico's look like off the top of my head.

---

Where's the "trade off" in storing the ZIP as a NUMBER or VARCHAR? That's just a choice -- it's not a trade off unless there are benefits to both and you have to give up some benefits to get others.

Unless the sum of zips has any meaning at all, Zips as number is not useful.

---

This might be an overkill, but if you need a solution that would work with multiple countries and you need to programmatically process parts of the address:

you could have country specific address handling using two tables: One generic table with 10 VARCHAR2 columns, 10 Number columns, another table which maps these fields to prompts and has a country column tying an address structure to a country.

---

If you ever have to verify an address or use it to process credit card payments, you'll at least need a little structure. A free-form block of text does not work very well for that.

Zip code is a common optional field for validating payment card transactions without using the whole address. So have a separate and generously sized field for that (at least 10 chars).

---

Inspired by Database Answers

Line1
Line2
Line3
City
Country_Province
PostalCode
CountryId
OtherDetails

---

I would just put all the fields together in a large NVARCHAR(1000) field, with a textarea element for the user to enter the value for (unless you want to perform analysis on eg. zip codes). All those address line 1, address line 2, etc. inputs are just so annoying if you have an address that doesn't fit well with that format (and, you know, there are other countries than the US).

참고URL : https://stackoverflow.com/questions/310540/best-practices-for-storing-postal-addresses-in-a-database-rdbms