So now the story has changed from the initial
When you enter a phone number it must be split to the logical parts according to the rules of the country it's been entered in. You may have a peek how to do it from your smart phone.
And every part of a number must be stored separately.
Down to "oh no it stores separately everything it recognizes, but puts the rest in a string if it doesn't".
Which kind of begs the question, if you are going to let anyone store anything at all anyway, and put what you don't recognize into a string, and only create an error when they attempt to dial it, why would you be parsing that string and storing it in separate numbers in the contacts database when they are entering it as opposed to when dialling? Just so that it would be a nanosecond faster to dial? You are going to now define 3 numeric and one string columns in your database schema and the benefit you get from it is to do absolutely nothing at all differently until the dialling attempt is made, at which point you could have done all the same things anyway?
I mean you seemed awfully sure (and gloriously condescending) that no one would wait until the number dials to parse out the various sections. But of course we have established that the dialler can parse them (since you can dial ad hoc), and you have basically conceded that it will try to sequence whatever you entered whether it makes sense to the phone or not. So if it can correctly do all that why does it need 3-4 distinct places to store the pieces?
When I enter a sequence of digits into the phone number textbox I can see the phone tries to parse it straignt away.
For example (I enter only digits, no spaces):
08 - still not a number, remains a string
08 1 - ooops, 08 is a possible long distance code, separate it from the rest of the number
0811 - nah, "08" cannot be a code within such sequence, single string again
0811 4 - "0811" might be one of those "free calling" access codes (again, according to the rules of the country where I'm in), must be separated.
0811 456 7 - we use to separate 1st triplet of a number for human convenience, so it follows the common convention
0811 456 7422 - the number seems completed and valid, all good
081145674221
That would be a display mask. But you'd have me believe that it is parsing it once for display, and then again to store. Which would mean that when you retrieved the contact with 0811 456 7422 and added a 1 and clicked save, it changed three numeric fields to nulls and dumped everything back into a string because the parsing had failed.
I mean, you keep telling me how smart smartphones are. But if you take 0811 456 7422 and add a pause and another 4 digits for an extension that could still be perfectly valid. Why not have the phone numbers it recognized in your magical integers and just dump the rest into the string?
Leading zeroes are stored in the dialing rules pattern, not in the phone numbers.
Leading zeroes as in, for example, a french area code, where the 0 is dialed if not including the country code, but not dialed using the international one (and there are other countries which can have the zero in the area and never strip it off, including apparently New Zealand). Thus if you store in a numeric area code field, you need to then know to dial the phantom 0 in the calling sequence.
Which begs the question. Since clearly it took the 0811 456 7422 number you entered above and stored in in 3 (2?) different numeric fields, and since you entered no country code for it, if you bring the phone to north america and open the number in your contacts does it display as 8114567422 ? After all, whatever country specific rule is putting the 0 back on your integer phone number won't apply as you are in a different country and have nothing in your country code field.
“Nothing is good but mediocrity. The majority has settled that, and finds fault with him who escapes it at whichever end.”
? Blaise Pascal, Pensées
“Whenever you find yourself on the side of the majority, it is time to pause and reflect.”
? Mark Twain
“Wrong does not cease to be wrong because the majority share in it.”
? Leo Tolstoy, A Confession
"Simply because the herd can be wrong does not mean that every animal that strays from it is right" - me
Put another way, we could all potentially be stupid for eating cooked dead cows. That would not make the person who instead eats a raw dead chicken necessarily a genius. You need more evidence than the presence of consensus to prove that the consensus is wrong, and you need way more to prove that anything that is not the consensus is right.
You never know how your data will be used, so you better keep in in order.
And if you maintain it in a consistent format, then when the use case changes adaptation is easy. Hence why you validate.
It seems to me this is only a concern if you have programmers who can figure out how to split a data entered number into 3 integer fields, and then correctly apply them when dialling (including re-adding some zeroes), but who somehow cannot use the same logic to validate the data entered number to ensure the format is consistent, store it as a consistent string then parse it and correctly apply when dialling.
Even if those numbers to be presented only to humans - it's better to separate long distance codes from the actual number while saving rather than force people to parse it while reading.
And if you validate the numbers well, applying a display mask to make the displayed number easier to read is elementary.
Finally, thanks to android being open source I went and looked up the contacts provider, and found that the number is indeed being stored and moved around as a single string. Link. You may now feel free to argue that it puts the numbers back together into a string when passing contacts around, and only parses on the way to the DB or the phone, but since you tried to cite the display masking when you entered it as proof it is breaking it up, I'm just not sure how plausible that would be.