我想知道是否有某種「標準」用於在數據庫中存儲美國地址？看起來這是一個普遍的任務，應該有某種標準。在SQL數據庫中存儲地址的最佳實踐/標準
我在找什麼是特定數據庫表應該如何工作和交互的模式，已經以第三範式，包括數據類型（MySQL）。一個好的UML文檔將起作用。
也許我只是懶惰，但這是一個非常普遍的任務，我相信有人發佈了一個有效的方法來做到這一點。我只是不知道去哪裏看，而Google也沒有幫助。請指點我的資源。謝謝。
編輯
雖然這更是一個普遍的問題，我想澄清我的特定需求。
地址將用於指定事件地點的公路地址。這些地址需要採用最佳分解和搜索格式，也可以由任何可能最終將我的數據源鏈接到的第三方應用程序使用。
也。數據在輸入時會被地理編碼（長，緯度）並單獨存儲，因此它必須符合任何地理編碼器/應用程序/庫所做的（尚未確定的）協議。
http://www.upu.int具有國際地址的格式標準。出版物28在http://usps.com具有美國格式標準。像http://semaphorecorp.com這樣的CASS軟件驗證和標準化美國地址。
美國郵政總局希望串聯在一行以下unpunctuated地址組件：
* house number
* predirectional (N, SE, etc)
* street
* suffix (AVE, BLVD, etc)
* postdirectional (SW, E, etc)
* unit (APT, STE, etc)
* apartment/suite number
例如，102 N MAIN ST SE APT B.
如果你把整個地址線作爲單場在你的數據庫中，輸入和編輯很容易，但是搜索可能更困難（例如，在SOUTH EAST LANE是東EET的街道EAST，還是SEE LANE ST的LANE？）。
如果您將地址解析到單獨的字段中，搜索街道名稱或公寓等組件變得更容易，但您必須將所有內容附加在一起輸出，您需要CASS軟件才能正確解析，並且郵政信箱，農村路線地址，APO/FPO地址有特殊的解析。
在該位置有多個地址的物理位置是多單元建築物，在這種情況下APT和STE等單元后的字母/數字指定地址，或者它是商業郵件接收代理（例如UPS商店）和maildrop /私人信箱號碼被追加（如100 MAIN ST STE B PMB 102），或者它是一家擁有一個USPS交付點的公司，並且郵件在USPS交付後路由（通常需要公司可能需要的單獨的mailstop字段，但USPS將不會在地址線上）。
具有多個實際地址的聯繫人通常是具有街道地址和郵政信箱的公司或個人。請注意，每個地址都有不同的郵政編碼是很常見的。
這是非常典型的，一個商業交易可能有一個送貨地址和一個賬單地址（再次，不同的郵政編碼）。我把每個地址的信息是：
* name prefix (DR, MS, etc)
* first name and initial
* last name
* name suffix (III, PHD, etc)
* mail stop
* company name
* address (one line only per Pub 28 for USA)
* city
* state/province
* ZIP/postal code
* country
我通常打印郵件而此人的姓名和公司之間停止，因爲國家包含狀態/ ZIP其中包含包含包含包含公司的地址城市包含該人的郵件停止。我使用CASS軟件在輸入或編輯時驗證和標準化地址。
我前段時間看過這個，但對於國際地址。我沒有找到太多的共識。然而，對於美國，我發現了一個名爲簡潔美國要道，地標和郵寄地址數據標準（草案）：
http://www.fgdc.gov/standards/projects/FGDC-standards-projects/street-address/index_html
我不認爲他們實際上提供任何具體的數據庫模式想法，但它可能是一個很好的起點。
首先，存儲地址的「最佳」方法很大程度上取決於它將如何使用。僅僅是爲了參考還是在說城市搜索？你打算處理信封嗎？您是否要與FedEx或UPS等運輸系統集成？你會存儲非美國地址嗎？一旦你進入與裝運事物整合的領域，你應該開始尋找CASS。這是處理USPS地址的規範。有那些應用程序是CASS認證，將存儲和驗證地址。因此，第二個最好的做法是儘量避免重新發明輪子，看看是否有一個系統可以解決你的問題，特別是如果你打算走向國際。你想利用這樣一個事實，即其他人已經制定了關於如何正確和有效地存儲世界各地許多國家地址的所有細節，而不必自己做這種調查。
我不得不嘗試這樣做，我發現this document，給你一些指針。我最終擱置了我的模式，因爲我的應用程序確實需要處理國際地址。
首先，作爲一個專門負責地址工作的人，他們很難從數據的角度進行管理。
如果你問5個人他們住在什麼地址;你會發現你得到5個不同的答案。雖然你我可以告訴123大街公寓1和公寓1 123大街 是相同的地址，數據庫程序將有一個挑戰。
如果您使用的是美國中心地址，幾乎任何供應商的CASS認證軟件都會將您的地址合理地標準化。我會推薦一個簡單的格式如下：
但是，如果您想要一個通用地址，我會查看IdeaAlliance的ADIS標準。該標準可用於將幾乎任何國家的地址分解（解析）到相關部分。然後，可以使用基於萬國郵政聯盟標準（UPU S42國際郵政地址組件和模板標準）的模板/組件將它們放回到一起。
這種格式的一大優點是，不存在於像CASS這樣的郵政數據庫中的地址可以作爲單獨的部分輸入和存儲。
Google/Android提供了他們如何在http://developer.android.com/reference/android/provider/ContactsContract.CommonDataKinds.StructuredPostal.html 以及http：// 3277行的源代碼的示例。 android.git.kernel.org/?p=platform/frameworks/base.git;a=blob;f=core/java/android/provider/ContactsContract.java;h=a56bb4593ba23848954819885436c0f3bfb15505;hb=HEAD – Don 2010-06-22 18:28:54
Android佈局使得在同一記錄中包含單獨的郵政信箱和街道地址，但只允許一個郵政編碼的經典錯誤。郵政信箱和街道地址很少共享相同的ZIP。 – 2010-11-03 20:59:55