Note that these are actually two issues:
- Should data entry offer a single multiline field, or multiple fields?
- Shoud the backend store address as a single field, or as multiple fields?
However, I'd argue both benefit or at least are not harmed by a single field.
ValidationRationale would be In favor
One perceived benefit of separate inputs, though: Itmulti-field is easier to accidentally omit some partvalidation.
Indeed it may protect you against missing significant parts - suhc as(Chechov's "Wanka" comes to mind). Yet with all the street number, or worseadressing schemes out there, only a human can decide whether any part of the town + zip codeaddress has meaning individually. For automated processing, address has significance only as a whole.
Another option would be using an online map service to show the location you understand from the address entered.
Single field advantages
A single field looks more approachable than half-a-dozen individual fields. Multi-field might border indimidating if you want to cover all possibilities (Now what do I enter in building extension?)
While "address" is rarely requested in first signup, the appearance of a complex form may affect conversion and finish rates.
Input can be expected to be faster, as many users still switch between mouse and keyboard when selecting a new field (casual observation).
A single field allows copy & paste of the address as a whole for advanced users.
@phresnel brings up common errors in data entry, that are usually corrected by the delivery company - further making quesitonable the quality of the data entered.
On the backend, a single field reduces complexity, even if marginal. Moreover, it drives home the point that the address should be handled as a whole, should be considered opaque unless you really do know what you are doing.
Slowing down overzealous developers from attempting validation that almost always will turn out incorrect might be considered a tangible benefit, too.
History
We did have good reasons for separate fields. Early automated processing tools might expect fixed locations for certain fields. We did not have powerful and easily accessible "address to location" conversions, and had to rely on individual field when querying e.g. for sales by country.
Good reasons for multi-field:
You might not have access to internet servives, you might need to be compatible with restrictive processing equipment, your users might rely on aut-form-fill tools that have problems with single-field-adresses. You might be catious and and want to be prepared for a future need of separate fields.