In data modeling for an Address entity, which set of fields should be included to support international addresses and ensure data quality?

In data modeling for an Address entity, which set of fields should be included to support international addresses and ensure data quality?

• A. Include street1, street2, city, country_code, postal_code.
• B. Include street1, street2, city, administrative_area, country_code (ISO 3166-1 alpha-2), postal_code, locality, sub_administrative_area, and optional building_number and PO_box; store canonical and local forms.
• C. Use only city and country without postal code.
• D. Store addresses as a single free-text field.

Answer: (B)

Designing an Address entity for worldwide use means breaking addresses into structured parts that align with how different countries format and route mail. Including street1 and street2 for street details, locality and city for local naming, administrative_area for states or provinces, sub_administrative_area for counties or districts, country_code using ISO 3166-1 alpha-2 for a clear, unambiguous country identifier, and postal_code for routing covers the variations you’ll see globally. Making building_number optional helps handle places that don’t use it and keeps the model flexible, while including PO_box captures mail routing in jurisdictions where P.O. boxes are common. Storing both canonical (normalized) and local forms lets you validate data consistently while still presenting addresses in the user’s local format and language, which improves data quality and display.

This approach supports robust validation, accurate formatting, efficient searching and geocoding, and better interoperability across systems. In contrast, only listing city and country omits essential routing and sub-national details, a single free-text field offers poor validation and difficult querying, and using a minimal field set won’t handle many international addressing rules.