處理這個問題的方式可以是：
採用三種觀點的地址/電話號碼/ POST代碼等
第一種觀點是，地址（比如說）爲多行的的文字。
第二種觀點是地址標記（更多見下文）。
第三視圖是爲地址
所需要這種方法是用於驗證的通用過程（類/觸發）的其它部件的驗證規則;用於打印目的的格式化例程;和一個規則庫，以及一個管理員機制來更新驗證規則。即使它不符合規則庫中的任何規則，一個「catchall」規則表明這是一個有效的地址 - 它已經被手動驗證過。
組件： 1地址由多行組成，每行都有一個關聯的序列號和一些標記（通常爲一個）。它也可以與地址線相關聯，這是一組規則和它們經過驗證的規則版本，但這是一種改進，取決於您的更新/插入/計算速率。
2地址標籤就像城市;鎮;門牌號碼;並確定地址的不同行。有可能有一個沒有任何標籤的地址行，但在這種情況下，只有通用搜索（例如紐約）可能在整行行上。搜索「城市=紐約」）是不可能的。
3以域專用語言編寫的規則。這可能是正則表達式;一種特定於你的語言;你的正常開發語言（儘管這可能是最不實用的方法，因爲編程語言可能難以精確準確地表達我所談論的規則。代表性規則的一個例子可能是（處理你對美國郵遞區號） - 前五個字符必須是數字
前五個字符表示「區號」
郵政編碼必須是地址的最後一行
的。規則將被分成組和集（例如美國地址）規則必須能夠引用其他規則以及地址數據。
您的驗證例程需要佔用地址的行並將規則應用於它（通常通過設置）。它將返回一個布爾型的有效或無效地址，以及可選的驗證規則集。
打印例程將再次將相應的規則集（可能與驗證集不同）應用於地址數據以提供格式化的地址。
我希望其他組成部分是明顯的整體方法。
這種做法是爲了應對你的問題確定了這些問題：
的電話代碼分區。
正在使用的可能區號的數量有限。
爲特定目的保留的電話號碼塊。
數據標準化 - 數據被標準化。但是，除了數據倉庫軟件和包含大量實時傳感器信息的數據庫，通常不會使用這種標準化（反向索引）。在實施此解決方案時，您可能最終選擇（可控地）重複數據。這不是解決方案的固有部分，但可能很方便。
我強烈建議不要爲每個變體添加類 - 這不是可縮放的，也不可維護的。
搜索將在下面詳細介紹。
避免使用怪物表 - 規則庫很可能是實際數據之外的數百到數千條規則的順序。
該解決方案是可擴展的 - 只需添加或修改規則即可。
並且還處理一些相關的問題。
即使你可以將驗證規則地址的國家形式，總會有例外的標準爲特定國家。我自己的地址就是一個例子 - 我住在一條船上，並且需要我的地址中包含的其他信息，超出郵局標準地址。這種異常總是可能需要人工干預 - 因此人工干預可以接受這一規則。
不同的國家有不同的地址排列順序 - 例如中國的地址寫爲：國家;郵政編碼;市;城區;街道名稱;門牌號碼;人名。
接受您沒有規則的地區的第一個地址，並且國家的規則與您所記錄的地區不同。
希望使用（例如辦公室）地址與「他們的」地址不同的地址的人。
具體的個人解決問題 - 有人希望隱藏他們離他們最近和最親愛的信件。
該解決方案可以擴展到像問題 - 例如指一個人。這可能涉及標題 - Dr，Rev等;多重連字符（ffoulkes-symthe）; （CPA，BSC等;以及家族資格（第三等）;以及取決於人文化的多種命名模式（來自印度次大陸的人們通常沒有姓氏，並且每個人顯然會有不同的姓氏。）
變化解決規則（例如增加了一個新的發展的新郵編），可以方便，快捷地取得
問題仍然出現在：
搜索會更復雜一些需要搜索地址的所有行和相關標記而不是特定地址字段
建立此類規則庫需要時間 - 儘管初始規則加載可以相當快地完成 - 示例存在於您的問題 - 只有在處理了多個異常和異常後，纔會出現完整集合。
編輯：
我不知道的BigTable的時候，我寫我的迴應。在看了這篇文章之後，它似乎是一個非常相似的概念。至於在ACID開發中實現它，我認爲這對聯繫人數據集和規則數據庫是可能的。根據我的經驗，我知道它很容易在這樣的環境下輕鬆擴展到5 * 10^7套聯繫人詳細信息（儘管有背景，不需要時間關鍵的聯繫方式驗證）。
在考慮ACID/SQL的情況下，我對單詞「view」的使用可能已經開始了一個向我不打算的方向發展的兔子。一個更合適的詞可能是概述或展望（沒有關係模型或DBMS運費的東西）。事實上，我將把我稱之爲視圖的每一件事都視爲候選人桌。
我爲我的方法提供了一個草圖，以幫助討論。這個模式使用了一些M：N連接，這顯然會在一個實現中被標準化爲關聯表。這是留給讀者的練習:-)。我已將一些示例屬性和數據放入一些表中。
在草圖中，規則集的編輯;規則;並且與其他規則（管理應用程序）相關的規則顯然可以通過Address User上的SQL Normal CRUD操作使用ACID屬性完成;地址;和地址行可以同樣以ACID/SQL方式完成，將地址行作爲用戶的輸入。您可能希望對交易進行一些預處理，以從道路名稱中分離（在我的示例中）房屋號碼，並因此丟失「道路名稱」規則。其他可能有用的預處理是大寫的標準化 - 儘管這也可能是驗證步驟的一部分。也可以簡單地接受完整的「9 Richmond Road」作爲輸入，並將其標記爲「需要驗證」。在任何一種情況下，我都沒有問題（我知道）關於創建此事務ACID的問題。
我不太清楚的是驗證和後續標記如何結合到ACID/SQL事務中。看起來，要進行驗證步驟ACID，可能需要根據規則集對測試應用進行排序（首先測試最常見的情況，並在驗證成功時停止）。此外，爲了使交易ACID只針對最常見的情況進行驗證，可能有必要將其他標籤標記爲「需要驗證」，然後將其作爲後臺任務完成。
驗證的實際任務涉及檢查整個規則庫，按集合設置，直到找到一組驗證所有輸入行的規則。數據本身顯然有潛在的指導原則 - 如果您記錄了國家/地區，那麼這兩者都可以讓您立即在國家/地區標記該行，併爲必須測試的規則集提供過濾器。我很抱歉，但就目前來說，我可以採取這一方面。順便提一句，這個草圖模式只是部分走向了總歸一化。如圖所示，每個地址都有其自己的地址線序列，並且沒有超出各行的數據標準化作爲輸入（加或減您選擇執行的任何預處理）。有可能進一步採用這種方法 - 通過在地址和地址線M：N之間建立鏈接並確保地址線表的線域是其主鍵。
當談到這個概念更詳細的資源時，我有兩個問題。
第一個（也是微不足道的）一個是，這個概念是我的原創工作，基於我作爲方法顧問和IT策略顧問的20多年經驗，對開發環境技術和開發方法有着特別的興趣。我所有的工作生活都是在環境中度過的，環境中的聯繫方式一直是主要關注的問題（出於財務和法規/立法原因）。事實上，在我讀完你的問題之前，我對你的問題的原始回答在我的腦海中完成了，儘管它讓我花了四分之三個小時才完成。
更重要的原因是這個想法的一些來源是保密的或祕密的。在我的工作生涯中，我的部分工作涉及與技術發展保持同步，並預測十年後技術對業務的影響。這涉及訪問研究實驗室並與主要研究人員就各種主題進行討論。雖然我不是，我自己是一流的研究人員，但我似乎很擅長綜合其他人的研究成果。然而，在這樣做的時候，我總是在商業機密和/或軍事保密的條件下運營。我的答案都沒有違反這些條件。由於這個原因，我只能給出如何得到信息的模糊指導。
我的來源是：
被CĴ日期進行的，在IBM，探索正常化的進一步下游和關係模型（而不是作爲在SQL中實現的關係模型）的研討會。這包括探索第五（？）和第六（？）正常形式。
一段時間內與Oracle技術人員進行的一系列討論，討論元數據;元元數據;和其他這樣的概括。
與英國軍事研究機構的討論。儘管這是幾年前的事情，但我不確定在我們正在討論的主題上是否發佈過任何內容。
在一家大型金融機構工作，其聯繫細節系統與我的建議非常相似，但是源於非關係型根源;在記憶，持久記憶和備份容量成爲主要關注的時代，最初的技術動力是節省空間的。
編輯：
我完成上述編輯，閉嘴我的電腦，做了一些家務，上牀睡覺，勞改了下來，閉上了眼睛，我有解決部分我無法完成之前的編輯。
雖然標記/驗證大部分工作實際上是閱讀和比較，但仍有更新需要完成。因此它是樂觀鎖定的主要候選者。在僞代碼，這將是這樣的：
Start read transaction
Read set of address lines where one or more lines are "Needs Validation"
Read all rule set names
Read all rule lines which belong to the first rule set
If read is not successful then abandon and start process again
End read transaction
Do while address not validated and not end of rule sets
If set of address lines validates against first rule set then
prepare transaction by allocating the tags to be applied to each line of the
address and temporarily recording the rule set that has validated the address
Start validation transaction
Read same set of address lines and rule set (all fields)
Is the address and the rule set identical to what was obtained in the read
transaction?
If identical then
create appropriate set of Tag Usage records
if successful then
commit validation transaction
end overall process
if not successful or
if not identical then
rollback validation Tag and Tag Usage
** This is the point where there might be problems if the rule set has
changed since reading it. The ordering may have changed due to amendment
deletion or creation of rule sets. This is the reason for the read of all
the read set names initially. However if there is such a change one can
afford to fail to validate and move on, aiming to come back to this address
later.
End of validation transaction
Start read transaction
Read rule lines which belong to the next rule set
End read transaction
End while loop
If end of rule sets reached and address not validated
begin create Tag Usage transaction
create tag usage pointing to Tag "Manual Intervention needed"
end create Tag Usage transaction
所有三種類型的交易（地址，地址線的更新，規則集，規則更新，以及標籤，標籤的使用更新）符合酸性條件。我堅信（但沒有證明）這三種交易類型的任何交織，組合或交集都將滿足ACID條件。
這真的很有趣的問題。您是否希望從存儲過程或觸發器中驗證這些數據，還是希望DB客戶端驗證它們？ – 2010-11-05 13:20:58
我有一種感覺，在實現中可能需要這些組合，但理論上我認爲存儲過程和觸發器可能是最佳選擇。 – Incognito 2010-11-05 17:27:29