How should international geographical addresses be stored in a relational database?

前端 未结 9 1367
耶瑟儿~
耶瑟儿~ 2020-11-30 16:46

Given the task of storing international geographic addresses in a relational table, what is the most flexible schema? Should every part of the address be broken out into the

9条回答
  •  被撕碎了的回忆
    2020-11-30 17:01

    Be careful not to over-analyze address formats. When you do, you're quite likely to end up with a specification most users will need to work around, effectively forcing them to use the wrong fields, or only filling the primary fields and ignoring the extra fields.

    Keep things simple.

    A StreetType like mentioned by BenAlabaster will cause problems when you start working with languages different from isolating languages like English or Spanish.

    To show you how bad things can get in the wild: the "Henriette Roland Holststraat" in Amsterdam, built up from "Henriette" + "Roland Holst" + "straat", which can be abbreviated as the "Roland Holststraat", or "Roland Holststr.", or misspelled as "H.R.Holststr." or "Henriette Roland-Holst straat", depending on the weather. Unless you've got an up-to-date street register for each country on earth, you'll be going nowhere.

    And finally, be careful that in some multilingual countries, names can be different from one language to another! For instance in Brussels where many streets have both a French and a Dutch name: "Avenu du Port" and "Havenlaan", depending on the addressee's preferred language. (Google Maps shows both names alternately, just to be on the safe side.)

    You can try to devise all kinds of clever tricks here, but are the sales reps. going to understand this?

提交回复
热议问题