將街道地址拆分為單獨的列可以解決哪些問題？
我們有一個為軟體開發人員設計表格和關係的團隊。在我們的組織中，他們對執行 3NF 規範化非常嚴格——老實說，考慮到我們組織的規模以及需求或我們的客戶如何隨時間而變化，我同意這一點。只有一個方面我不清楚他們設計決策背後的原因：地址。
雖然這主要集中在美國的地址上，但我認為這可能適用於任何這樣做的國家。地址的每一部分在地址表中都有自己的列。例如，以這個粗糙的美國地址為例：
Attn: Jane Doe 485 1/2 N Smith St SW, APT 300B Chicago, IL 11111-2222它將像這樣在數據庫中拆分：
- 街道號碼：485
- 街道分數：1/2
- 街道預方向：N（北）
- 街道名稱：史密斯
- 街道類型：ST（街道）
- 街道後向：SW（西南）
- 城市：芝加哥
- 州：IL（伊利諾伊州）
- 郵編：11111
- 郵編：2222
- 國家（假定為美國）
- 注意：簡·多伊
- 郵政信箱：空
- 戶型：APT（公寓）
- 戶數：300B
還有其他一些與農村路線和契約路線相關的專欄。此外，我們的特定應用程序中可能會有一些國際地址。數據建模人員表示，他們將添加特定於國際地址的列，這將是正常的第 1 行、第 2 行欄位。
起初我認為這太過分了。反复上網查是指使用地址行 1、2、3 可能還有 4，然後拆分出城市、地區和郵政編碼。對於我們的新應用程序，我們確實有一個案例，這種粒度是有益的。我們必須驗證使用者沒有創建重複的業務，並且檢查地址是驗證之一。我們可以讓它與地址行 1 和 2 一起工作，但這會更加困難。
至於我們的具體應用，我們需要為企業和人員儲存多種地址（物理地址、郵寄地址、運輸地址等）。我們可能需要生成可列印的套用信函，但到目前為止還沒有討論過這個要求。
我們組織中的一些其他應用程序需要支持：
- 審計（帶有完整的歷史表）
- 列印郵寄標籤
- 生成列印表單
- 報告（針對國家和地區政府）
雖然我們的應用程序可能不會做所有其他應用程序所做的一切，但將地址分成多個組件是我工作的*企業標準。*不管我們的應用程序是否會從中受益，我們都被迫這樣做。
半相關的 StackOverflow 問題：Where is a good Address Parser which was closed，但說明了解析地址有多麼困難。
為了讓我更好地理解他們的設計決定，並向我們的客戶推銷這個想法……
將街道地址拆分為單獨的列可以解決哪些問題？
任何實施了這樣的系統的人都會獲得獎勵積分，因為他們遇到了問題。
拆分可以解決的問題包括
驗證名稱的任何一部分都可以與主列表進行比較。那些不匹配的可以被拒絕。郵政編碼/郵政編碼是一個明顯的例子。這些由獨立的權威機構發布和維護。唯一有效的是由該機構頒發的。
分揀和選擇我見過一些案例，如果將郵件交給已經在一定程度上組織起來的遞送服務，則可以減少郵寄費用。擁有相應的列會產生有形的商業價值。
分析以地理分層方式了解您的訂單的去向可能很有用。這可能會推動銷售計劃、產品開發或佣金支付等。
程式碼複製通過讓組織中的所有應用程序採用相同的數據模型（最複雜的消費者的數據模型），可以在企業範圍內採用單個程式碼庫並進行一致的維護。可以避免無休止地重複頭髮分裂，或者至少委託給螺旋槳頭。組織不同部分持有的地址可以持續更新。可以提高客戶服務和滿意度。開發工作可以集中在系統的獨特、高價值部分。
法律問題法律和稅收因司法管轄區而異。通過單獨擷取詳細的地址值，可以更輕鬆地將交易數據與合規性要求進行交叉引用。
重複通過將一個元素移動到下一行或對某些部分重新排序來欺騙作為文本保存的地址很簡單。完全解析的地址更容易比較。這可能是一個簡單的數據質量問題，或者可能會影響合規性或信用問題，例如，如果多家空殼公司向同一個送貨地址發出大宗訂單，或者使用信用卡在短時間內向許多分散的地點送貨。
單獨保存的格式化元件可以以適合目前需要的任何方式組合。例如，如果長而薄的列印標籤變得便宜，您可以重新格式化以使用它們。
當然，這些都不可能適用於任何特定的應用程序。這種類型的數據在收集時比在後期分析中更容易在源頭解析和驗證。因此，即使是 YAGNI，最好還是提前付出額外的努力，以降低成本並在未來節省大量資金。
最後，我不會忽視人的因素。數據模型由數據建模者生成。這就是他們所做的。那是他們的職業。他們不會告訴你把它轉儲到一個 BLOB 中，是嗎？