地址的哪些部分应该是必需的？
假设我将地址存储在数据库表中，在这个相当常见的细分中：（
address_street_line_1,
address_street_line_2,
address_city,
address_state,
address_zip,
address_country_id
注意：我已经阅读了有关进一步拆分、街道类型、门牌号等的问题，对于这个应用程序，我认为这会使事情变得不必要地复杂化。 )
为了更好地与国际用户合作，以下哪些字段不应该是必需的？
我在想：
address_street_line_1 REQUIRED
address_city REQUIRED
address_country_id REQUIRED
我应该需要状态还是邮政编码？
谢谢！ 泽维尔
Say I am storing addresses in a DB table, in this fairly common break down:
address_street_line_1,
address_street_line_2,
address_city,
address_state,
address_zip,
address_country_id
(Note: I have read the questions on splitting down further, street type, house number, etc. and for this application I think it would unnecessarily complicate things.)
To work best with international users, which of these fields should NOT be required?
I'm thinking this:
address_street_line_1 REQUIRED
address_city REQUIRED
address_country_id REQUIRED
Should I require state or zip?
Thanks!
Xavier
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（10）
您可能只需要一个字段：国家/地区。
但你真正应该做的是让逻辑依赖于国家。请查看按国家/地区列出的地址格式以获取完整列表。这也不仅仅是必填字段。这也与正确的格式有关。美国地址可能是：
8031 Main Street
斯普林菲尔德俄亥俄州 12345
美国
，而瑞士：
Bodenstr。 173
8043 苏黎世
瑞士
注意：瑞士的街道号码和邮政编码采用“相反”顺序（与英语国家使用的顺序相比）。
此外，您的数据类型需要足够广泛，以涵盖其他国家/地区使用的数据。邮政编码绝对不是数字类型。例如，“EC2R 8AH”是有效的英国邮政编码。
这又回到了这个原则：如果你不对它执行算术运算，它就不是数字类型。这是文字。
另外，尽量不要向最终用户将其称为邮政编码。这是美国独有的术语。几乎在其他地方，它都被称为邮政编码、邮政编码或邮政编码。另请注意，英国邮政编码由字母数字组成，并包含空格。
You can probably only require one field: country.
But what you should really be doing is making the logic dependent on country. Take a look at Address Formats by Country for a comprehensive list. That isn't just about required fields either. It's also about correct formatting. A US address might be:
8031 Main Street
Springfield OH 12345
USA
whereas in Switzerland:
Bodenstr. 173
8043 Zürich
Schweiz
Note: the street numbers and post codes are in the "reverse" order for Switzerland (compared to what English speaking countries use).
Also, your data types need to be broad enough to cover data used in other countries. Zip/post code should absolutely not be a numeric type. For example, "EC2R 8AH" is a valid UK postcode.
That goes back to this principle: if you don't perform arithmetic on it, it's not a numeric type. It's text.
Also, try not to call it Zip Code to end users. That's a US only term. Pretty much everywhere else its call a Postcode, Post code or Postal Code. Also note that the UK postal codes are alphanumeric and include a space.
并非所有国家/地区都使用邮政编码，例如，在 2006 年左右之前，新西兰就很少使用邮政编码。我认为爱尔兰根本不使用它们。
如果您是真正的国际化企业，像新加坡这样的城邦实际上并不需要“城市”字段。
在用户界面中，您可以（也许应该）为您已经知道需要邮政编码的国家/地区设置所需的邮政编码，因为这不太可能改变。而且，如果您使 UI 足够动态，则如果所选国家/地区是美国，则可以将其称为“邮政编码”；如果选择的国家/地区是美国，则可以将其称为“邮政编码”；对于加拿大，则可以将其称为“邮政编码”；对于英国，则可以将其称为“邮政编码”，等等。
Not all countries even use postal codes, for example they were rarely used in New Zealand prior to 2006 or so. I think Ireland doesn't use them at all.
If you're truly international, city-states such as Singapore don't actually need a City field.
In the user interface, you can (and perhaps should) make the postcode required for countries where you already know it's required, since that isn't likely to change. And, if you make the UI dynamic enough, you can call it "Zip code" if the selected country is the United States, "Postal code" for Canada, "Postcode" for the UK, etc.
不做任何要求怎么样？如果用户想要联系，他们将输入足够的信息。或者，输入一个文本字段并让他们输入自由格式的信息。他们比您更清楚邮政递送需要哪些字段才能送到他们家门口。
How about making none required? If the user wants to be contacted they'll enter enough information. Or, enter a single text field and let them enter free form information. They know better than you what fields are required for postal deliveries to make it to their door.
我会说除了 street_line_2 和 state- 之外的所有内容，并将“zip”视为更多的邮政编码 而不是邮政编码 - 正如您可以从基于原籍国的各种格式中看出的那样，这应该具有相当开放的格式。
I would say everything except street_line_2 and state- and think of 'zip' as more of a postal codes instead of zip code - as you can tell from the variety of format based on the country of origin, this should have a pretty open format.
即使在美国，大部分地址也不是必需的。美国邮政编码的很大一部分被分配给各种企业和组织 - 任何发送到这些邮政编码之一的邮件都将以相同的方式投递，无论地址的其余部分如何。例如：
通用电气
斯克内克塔迪, NY 12345
国税局
Ogden, UT 84201-0027
这个城市和州都很好，但邮件可能无法投递。
Even in the U.S., most of the address is not required. A large fraction of U.S. zip codes are allocated to various businesses and organizations - any mail to one of those zips will be delivered the same regardless of the rest of the address. For instance:
General Electric
Schenectady, NY 12345
Internal Revenue Service
Ogden, UT 84201-0027
The city and state are nice, but the mail will probably get delivered without.
我发现解决这个问题的最好方法是抽象应用程序层中的逻辑，而不是持久层。我见过的最干净/最简单的方法之一是将值对象中的用户数据（创建一个易于验证的通用接口）传递给具有当前国家/地区代码的验证器，这确保了所有必需的属性在该语言环境的值对象中正确设置。假设它通过验证，请将值对象传递到应用程序的持久性端进行存储。
这里的关键是值对象 - 您正在创建一个通用接口，应用程序的多个部分可以与该接口进行通信、验证和读/写。然后，您还可以在显示地址时使用相同的值对象：让持久层获取信息，将其放入值对象中，将其传递给具有当前语言环境的工厂，该工厂返回所需的地址格式，然后将该输出发送到前端。
The best way that I have found to solve this problem is by abstracting the logic in your application layer, and not the persistence layer. One of the cleanest/simplest ways I've seen this done is by passing the user's data in a value object (creating a common interface that's easy to validate against) to a validator with the current country code, which makes sure all the required attributes are set properly in the value object for that locale. Assuming it passes validation, pass the value object along to the persistence side of your application for storage.
The key here is the value object - you're creating a common interface that multiple pieces of your application can talk to, validate, and read/write from. You can then also use that same value object when displaying the address: have your persistence layer get the information, put it in the value object, pass it to a factory with the current locale which returns the desired address format, and send that output to the front end.
新西兰没有州，所以它绝对应该是可选的。所以我认为你的问题有正确的答案。
There are no states in New Zealand, so it should definately be optional. So I think you have the right answer in your question.
如果您不打算进行任何特定的查找，例如按邮政编码或按城市搜索，我建议将所有地址合并到一个字段中。这样您将支持来自不同国家的不同地址。
您还将支持奇怪的地址。
如果您担心需求会发生变化，您可以将地址存储为 Xml 字段。只要您使用架构，Sql Server 2005 和 2008 等现代数据库就可以在 Xml 列内的 Xml 节点上拥有索引。
这一切都取决于要求。如果客户端需要按国家/地区对网格内的数据进行分组，那么您需要一个国家/地区列。
If you are not going to do any specific lookup, like searching by postal code or by city, I'd say to all combine the address in a single field. This way you will support the different address from different countries.
You will also support address oddities.
If you fear that the requirements are going to change, you could store the address as a Xml field. Modern database like Sql Server 2005 and 2008 can have an index on a Xml node inside a Xml column as long as you are using a schema.
It all come down to requirements. If the client need to group the data inside a grid by country, then you need a country column.
将字段设置为必填始终是一种权衡。如果这个人不想填写信息，那么他们就不会——他们会输入句号或垃圾来跳过“必填字段”保姆。
我的应用程序中只需要 street_address_1。此外，对于美国和许多国家/地区，您可以购买邮政编码与规范城市/州之间的映射。价格不贵。 （各个街道地址和邮政编码之间的映射要昂贵得多。）
对于美国，请参阅 http://www.usps.com/ncsc/addressinfo/citystate .htm
如果您包含 Ajax Web 界面，请先询问国家/地区，然后询问邮政编码。如果在美国，则使用 Ajax 从 zip 中获取并填写用户的城市/州。
如果您要求人们填写他们的“首选地址”，一些非美国国家（例如英国）可以有 3 行街道地址，例如：
Larry
Making fields required is always a tradeoff. If the person doesn't want to fill in the info then they won't -- they'll put in a period, or garbage to get past the "required field" nanny.
I only require street_address_1 in my apps. Also, for the US and many countries, you can buy the mapping between the postal/zip code and the canonical city/state. It's not expensive. (The mapping between individual street addresses and zip is much more expensive.)
For the US, see http://www.usps.com/ncsc/addressinfo/citystate.htm
If you're including an Ajax web interface, ask for the country first, then the post code. If in the US, then use Ajax to fetch and fill in the city/state for the user from the zip.
Some non-US countries, eg UK, can have 3 lines of street addresses if you're asking people to fill in their "preferred address" Eg:
Larry
事实上，美国甚至不需要城市。
许多人的乡村地址都位于州道和县道上。邮政服务网站的出版物 28 有详细信息。不同的公司最终使用“城市”字段来存储其他信息。这也适用于军事基地地址。
出版物 28 链接
Actually, city isn't even required in the US.
Many people have rural addresses on state and county roads. Publication 28 at the postal service web site has details. Different companies end up using the "city" field to store other information. This also applies to military base addresses.
Publication 28 link