Do you break up addresses into street / city / sta

问题:

My current app needs to store address information for a user. I'm currently debating whether to use the customary street address / city / state / zip textboxes and dropdowns or to go with Google's method of simply having everything on one line. Any thoughts on the pros/cons of storing address information in either of these manners?

回答1:

You should split it up. It will make it far easier to do reporting down the road. What happens if you want to pull up all the residents of a state or zip code, or city? If you use all one field, you will be stuck and wish you had split it up.

Also, users will forget to put in all the information you need if you don't prompt them for it.

回答2:

Judging by the user-input tag on your post, I assume you are referring to how the user enters the data, and now how you are storing the data in your back-end database.

Presumably your database will still need to store this information as separate fields, if you want to be able to sort and analyse the information (e.g. for reporting and statistics purposes).

In this case, I think it would depend on how confident you are that you could parse the addressing information properly into its individual fields.

One hybrid option would be to allow the user to enter the address as a single line, and then do a best-effort parsing of the information into the separate fields. This is similar to how Outlook manages addresses for contacts - you enter all of the information into a single memo field, and then it splits it up for you. You can then correct if it interpreted any of the fields wrong.

回答3:

I would be very much against just having a single text field where users enter their address. You'd be surprised how many people will leave out their zip code or some other important info if you don't have a specific field for it. Also, as others have mentioned, it make reporting much easier to report on this information later if all the data is pre-parsed. As other users mentioned, programs like outlook will parse this information, but only because the source of the data is often the signatures of emails, which is something that is never in a consistent format.

回答4:

I tend to split it up, allows searching to be done for a specific section of the address and you can limit the addresses you want to handle by knowing the formatting i.e. Only ship to east coast addresses.

回答5:

1) You should split it.

2) May I recommend you read this before you attempt to do international address input?

回答6:

I concur with Kibbee. I was even surprised to see people don't even read the field's labels, inverting first and last name, postal code and city, etc.
No, you can't determinate if a postal code is valid, in a Web application targeting international customers...
Some countries have alpha characters in postal code, various lengths, no state info, etc.

回答7:

Definitely split the input. If you can help it--and depending upon your business requirements--it may be wise to perform address verification at the point of entry. This will allow you to know that your addresses are going into your database clean and allow you to do a number of other things such as fraud prevention. Having a verified address can help reduce shipping costs if you're shipping physical goods to your customers and can help reduce credit card merchant fees by ensuring the correct ZIP Code is submitted during AVS verification.

In the interest of full disclosure, I'm the founder of SmartyStreets. We offer CASS-certified address verification services. Users can upload a list for scrubbing (CSV/Excel/etc) to our website or use our address verification web service API called LiveAddress.