I think it’s worth noting that, yes, if you want your database of names/addresses/times/etc. to be fully robust, you need to essentially represent these items as unconstrained strings of arbitrary length (including zero).
However, in practice, most likely you’re not building a fully robust database. For example, you are not solving the problem of, “how can I fully represent all of the marvelous variety of human names and addresses ?”, but rather, “how can I maximize the changes that the packages my company is shipping to customers will actually be shipped to the correct customer ?”.
The second problem is much more heavily constrained, because your database no longer holds arbitrary pieces of information; but rather, instructions to someone (or something) at the package shipping company. All you need to do is implement just enough complexity to make sure you can communicate to that agent. It is highly unlikely that the agent will accept arbitrary strings, because he needs to turn around and convert the strings to instructions for his fleet of delivery truck drivers, and—not being omniscient—he can’t do that if the address says, “That one old guy who lives in the village over by the river”.
he can’t do that if the address says, “That one old guy who lives in the village over by the river”.
As a nitpick—yes, he can. In the third world it’s not uncommon to NOT have a working system of usual addresses and locations are typically specified as town—local landmark—directions from that local landmark.
Right, I was thinking in the context of our Western society. But in the third world, as you said, the opposite is true: an address like “123 Main St., Sometown Somecountry” simply does not work. So it is still not the case that you need to implement a fully general address database that covers all possible cases; you only need to cover the cases that you personally care about.
Of course, you’re much less likely to be shipping a package to those kinds of third world countries, and even if you did, you’d have trouble making sure it gets delivered to its destination for other reasons.
I think it’s worth noting that, yes, if you want your database of names/addresses/times/etc. to be fully robust, you need to essentially represent these items as unconstrained strings of arbitrary length (including zero).
However, in practice, most likely you’re not building a fully robust database. For example, you are not solving the problem of, “how can I fully represent all of the marvelous variety of human names and addresses ?”, but rather, “how can I maximize the changes that the packages my company is shipping to customers will actually be shipped to the correct customer ?”.
The second problem is much more heavily constrained, because your database no longer holds arbitrary pieces of information; but rather, instructions to someone (or something) at the package shipping company. All you need to do is implement just enough complexity to make sure you can communicate to that agent. It is highly unlikely that the agent will accept arbitrary strings, because he needs to turn around and convert the strings to instructions for his fleet of delivery truck drivers, and—not being omniscient—he can’t do that if the address says, “That one old guy who lives in the village over by the river”.
As a nitpick—yes, he can. In the third world it’s not uncommon to NOT have a working system of usual addresses and locations are typically specified as town—local landmark—directions from that local landmark.
Right, I was thinking in the context of our Western society. But in the third world, as you said, the opposite is true: an address like “123 Main St., Sometown Somecountry” simply does not work. So it is still not the case that you need to implement a fully general address database that covers all possible cases; you only need to cover the cases that you personally care about.
Of course, you’re much less likely to be shipping a package to those kinds of third world countries, and even if you did, you’d have trouble making sure it gets delivered to its destination for other reasons.