TL;DR: Use a single text field, store as a single string, show an address label preview.
Separate fields have served limited purpose, such as safely identifying the country, town or zip code area someone lives in. They also allowed to enforce some constraints, such as providing a fixed list of countries. They also - in theory - allowed to "reduce the number of changes made" if a customer record changes. On the more esoteric end, it could help determining left side of the road from right side, by looking at even / odd numbers1.
This is wrong today for two reasons:
for reference, see "Falsehoods programmers believe about adresses"2)
Online map services do a continuously better job at understanding a plaintext address, and can answer all the queries you might want to (such as which country, which town, which is our closest delivery center factoring in typical thursday afternoon traffic conditions)
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.
One perceived benefit of multi-field is validation.
Indeed it may protect you against missing significant parts (Chechov's "Wanka" comes to mind). Yet with all the adressing schemes out there, only a human can decide whether any part of the address has meaning individually. For automated processing, address has significance only as a whole.
In my contrieved opinion, showing an address label preview with the usual formating, style and background ("this is how we would address a package to you. Does this look right?") should be enough to prime users to verify the address is correct.
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.
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.
1) this actually was suggested to me some 15 years ago as a good reason why a street number should be a separate field. I don't know if this ever had practical use.
2) While you are at it, also see the equally excellent "Falsehoods ... about names". The conclusions from that would be even further reaching.