May 1, 2015 at 12:11 pm
I don't dispute that the phone identifies it, but it is the calling function that parses it. It is not stored that way.
May 1, 2015 at 4:58 pm
Nevyn (5/1/2015)
I don't dispute that the phone identifies it, but it is the calling function that parses it. It is not stored that way.
So, we have 2 options:
1) store a phone number as it's entered and parse it into logical blocks on every attempt to make a call (using the rules of that country where the number was entered), and then build a dialling sequence from the blocks;
2) parse the phone number once when it's entered, identify the logical blocks and save them separately. Then when you need to make a call build a sequence from already prepared blocks.
P.S.Did you ever fill a paper form with "phone number" field in it?
Did you notice separate blocks of blanks for area code (and country code, where appropriate)?
Turns out, the people who designed such forms 50 or 80 years ago already knew that it's better to separate logical blocks on data entry and store them separately rather than parse a randomly entered single set of digits.
And now, several generations later you have not see a single database with phone numbers stored in logical blocks.
Apparently, the movie "Idiocracy" was right on the spot.
_____________
Code for TallyGenerator
May 1, 2015 at 6:39 pm
Sergiy (5/1/2015)
So, we have 2 options:1) store a phone number as it's entered and parse it into logical blocks on every attempt to make a call (using the rules of that country where the number was entered), and then build a dialling sequence from the blocks;
2) parse the phone number once when it's entered, identify the logical blocks and save them separately. Then when you need to make a call build a sequence from already prepared blocks.
I'm somewhat at a loss as to why a phone cares about format. When I make a call, my phone simply pushes out the sequence of numbers that it obtains either from my contacts list or from what I enter there and then - it doesn't care about formats. Last time anything had to worry about formats was when prefixing an in-country number with the country dial code caused you to be charged at a different rate, which may still happen in some places but not in any I've been in in the last decade.
P.S.Did you ever fill a paper form with "phone number" field in it?
Did you notice separate blocks of blanks for area code (and country code, where appropriate)?
Turns out, the people who designed such forms 50 or 80 years ago already knew that it's better to separate logical blocks on data entry and store them separately rather than parse a randomly entered single set of digits.
The paper forms are for people to read; separating the fields is useful because it saves the trouble of entering unneeded fields when dialling or pressing buttons. Not for anything else (except perhaps that it makes it easier to see how to adapt a number when a digit is added to an area code or the local number to increase the number of phone numbers available in some area or region or country). There's probably no point in separating the fields in a phone, unless you are stuck with using some archaic system and it requires delays between dialling the various fields.
And now, several generations later you have not see a single database with phone numbers stored in logical blocks.
Apparently, the movie "Idiocracy" was right on the spot.
No Idiocracy, just people applying the KISS principle, I think.
Tom
May 1, 2015 at 11:23 pm
TomThomson (5/1/2015)
I'm somewhat at a loss as to why a phone cares about format. When I make a call, my phone simply pushes out the sequence of numbers that it obtains either from my contacts list or from what I enter there and then - it doesn't care about formats. Last time anything had to worry about formats was when prefixing an in-country number with the country dial code caused you to be charged at a different rate, which may still happen in some places but not in any I've been in in the last decade.
How would you record an Australian number in your contacts?
I ususally do it as +61....
61 is a code for Australia.
And "+" ? What is that?
Does my phone really include "+" into the actual dialing seqiuence?
No, of course.
It replaces "+" with "00".
But why not just record it "0061..."?
Because if I need to call the same number from US I need to use a difference sequence: "01161..."
If I'm in Russia I need to used something totally different: "8P{ause}1061..."
Talking about Russia.
If I'm trying to call a Moscow number from, say, Vladivostok, I need to dial:
8P095NNNNNNNN.
And I need to do it from NZ I have to dial
00795NNNNNNN.
Which string should my phone be storing, as for you?
_____________
Code for TallyGenerator
May 1, 2015 at 11:26 pm
TomThomson (5/1/2015)
separating the fields is useful because it saves the trouble
Exactly.
If you hid the trouble inside of a computer it does not mean it's gone.
_____________
Code for TallyGenerator
May 1, 2015 at 11:40 pm
TomThomson (5/1/2015)
No Idiocracy, just people applying the KISS principle, I think.
It only seems simple for someone who never had to deal with real calling systems.
5 developers for almost 2 years were trying to fix the issues with our faxing module using fax numbers recorded as strings.
And we still had lost invoices, unnecessary long distance charges, failures to connect, ladies had to go through the log, find failed transmissions, figure out the right numbers and sent invoices manually.
And it's only when faxing between Australia and New Zealand.
Only I convinced the boss to store parts of fax numbers separately and use the appropriate logic to build the dialing sequence depending on location of the sending fax service - all the problems were solved. Once and forever.
So, storing phone numbers as single strings is not simplicity, it's indeed idiocracy.
_____________
Code for TallyGenerator
May 4, 2015 at 10:21 am
Sergiy (5/1/2015)
TomThomson (5/1/2015)
No Idiocracy, just people applying the KISS principle, I think.It only seems simple for someone who never had to deal with real calling systems.
5 developers for almost 2 years were trying to fix the issues with our faxing module using fax numbers recorded as strings.
And we still had lost invoices, unnecessary long distance charges, failures to connect, ladies had to go through the log, find failed transmissions, figure out the right numbers and sent invoices manually.
And it's only when faxing between Australia and New Zealand.
Only I convinced the boss to store parts of fax numbers separately and use the appropriate logic to build the dialing sequence depending on location of the sending fax service - all the problems were solved. Once and forever.
So, storing phone numbers as single strings is not simplicity, it's indeed idiocracy.
In my experience the problem has been how to know what to do with +; ideally the phone works out which communications provider it is talking to and interprets + accordingly. Since btween 2000 and 2009 I had to be in touch by phone with people in UK, USA, Barbados, Holland, Germany, France, Lebanon, Kuwait, Qatar, India, Spain, Belgium and Italy I was rather glad that fax was irrelevant (outdated primitive technology) and extremely glad that the suppliers of dirt cheap mobile phones appeared to have it sorted out at least for that range of countries. I can see though that duplicating that in a computer might be interesting.
Tom
May 4, 2015 at 4:04 pm
It seems saying "Yes, I see - storing phone number as a single string does not work" is simply too hard for you. 🙂
P.S. What is so outdated in fax technology?
_____________
Code for TallyGenerator
May 4, 2015 at 4:09 pm
TomThomson (5/4/2015)
Sergiy (5/1/2015)
TomThomson (5/1/2015)
No Idiocracy, just people applying the KISS principle, I think.It only seems simple for someone who never had to deal with real calling systems.
5 developers for almost 2 years were trying to fix the issues with our faxing module using fax numbers recorded as strings.
And we still had lost invoices, unnecessary long distance charges, failures to connect, ladies had to go through the log, find failed transmissions, figure out the right numbers and sent invoices manually.
And it's only when faxing between Australia and New Zealand.
Only I convinced the boss to store parts of fax numbers separately and use the appropriate logic to build the dialing sequence depending on location of the sending fax service - all the problems were solved. Once and forever.
So, storing phone numbers as single strings is not simplicity, it's indeed idiocracy.
In my experience the problem has been how to know what to do with +; ideally the phone works out which communications provider it is talking to and interprets + accordingly. Since btween 2000 and 2009 I had to be in touch by phone with people in UK, USA, Barbados, Holland, Germany, France, Lebanon, Kuwait, Qatar, India, Spain, Belgium and Italy I was rather glad that fax was irrelevant (outdated primitive technology) and extremely glad that the suppliers of dirt cheap mobile phones appeared to have it sorted out at least for that range of countries. I can see though that duplicating that in a computer might be interesting.
I'd be somewhat leery of sending documents to a mobile phone, particularly sensitive documents.
SQL DBA,SQL Server MVP(07, 08, 09) "It's a dog-eat-dog world, and I'm wearing Milk-Bone underwear." "Norm", on "Cheers". Also from "Cheers", from "Carla": "You need to know 3 things about Tortelli men: Tortelli men draw women like flies; Tortelli men treat women like flies; Tortelli men's brains are in their flies".
May 5, 2015 at 11:09 am
Sergiy (5/1/2015)
Nevyn (5/1/2015)
I don't dispute that the phone identifies it, but it is the calling function that parses it. It is not stored that way.So, we have 2 options:
1) store a phone number as it's entered and parse it into logical blocks on every attempt to make a call (using the rules of that country where the number was entered), and then build a dialling sequence from the blocks;
2) parse the phone number once when it's entered, identify the logical blocks and save them separately. Then when you need to make a call build a sequence from already prepared blocks.
You seem to be trying to argue with me about what my smartphone SHOULD do.
I am telling you what it IS doing, since you told me to check.
And among other things it will let me store "+-+-+-+-+-+-+-" in my contacts, and retrieve it later. So I am pretty sure that any parsing or validation of the number is happening when it tries to dial and that it can handle characters. And while it doesn't give me the keyboard for entering with letters it will happily sync with google contacts, which happily lets me store the phone number "this is a string".
If you think that's idiocracy, please feel free to take it up with Samsung, who made the phone, or Google, who wrote the OS and the Contacts app.
Also, FWIW I can also store a comma and a semi-colon at any point in these strings. Which lets me store a phone number that pauses 3 seconds (say before entering an IVR selection or extension) or WAIT for me to press something to continue. Again, not sure what numbers you think it stores for those behind the scenes.
Most of the numbers stored in my phone contain country codes, even for my own home number. Just in case I'll use the phone when abroad.
Nevertheless, I'm not charged with international rates when I call those numbers locally. That means that the phone identifies country codes in the numbers and excludes them from the dialling sequence when it matches the country code for my current location.
Or it means your phone dials that number anyway, but the network is smart enough to recognize that you specified the same country the network is on, and route the call accordingly.
5 developers for almost 2 years were trying to fix the issues with our faxing module using fax numbers recorded as strings.
And we still had lost invoices, unnecessary long distance charges, failures to connect, ladies had to go through the log, find failed transmissions, figure out the right numbers and sent invoices manually.
And it's only when faxing between Australia and New Zealand.
I am sympathetic to you having had a traumatic experience. I am not sure that that experience should be the basis for asserting some sort of universal best practice for storing phone numbers in any database, particularly since a great many (perhaps an overwhelming majority) of them are in no way connecting to any sort of automated dialing system.
I am also not sure how you are handling leading zeroes in your best practice, and still not sure what you are labelling your various phone number columns, since their significance changes country to country (and sometimes varies based on mobile or not). But still eminently curious if you'd like to further propose a best practice.
May 5, 2015 at 5:57 pm
Nevyn (5/5/2015)
You seem to be trying to argue with me about what my smartphone SHOULD do.
I am telling you what it IS doing, since you told me to check.
No, I'm telling you what my smartfone does.
And you're telling what it would do if you'd programmed it.
And among other things it will let me store "+-+-+-+-+-+-+-" in my contacts, and retrieve it later. So I am pretty sure that any parsing or validation of the number is happening when it tries to dial and that it can handle characters. And while it doesn't give me the keyboard for entering with letters it will happily sync with google contacts, which happily lets me store the phone number "this is a string".
Yes, it will let you store whatever you've entered, and if it cannot parse it into a proper number it will store it as a string.
But I can assure you - if you try to call any number stored as a string you're not gonna get anywhere.
Because phones store as a single string only improperly entered numbers.
If you think that's idiocracy, please feel free to take it up with Samsung, who made the phone, or Google, who wrote the OS and the Contacts app.
I'm not gonna take on them because I believe they're doing all right.
I have not used Samsung a lot, so I'll apeak from my exoerience with iPhone and Alcatel (Android phone).
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 - ooops, adding an extra digit makes the number invalid - all the parsing is gone, the sequence to be stored as a string, because the number is obviously incorrect.
If I would be in Australia I'd see the same behaviour when entering numbers starting with 1800 - it's their free calling prefix.
But while I'm in NZ my phone takes everything started with "1800" and unrecognisable sequence and stores it as it is - with no parsing.
Smartphones are much smarter than you think they are.:cool:
Also, FWIW I can also store a comma and a semi-colon at any point in these strings. Which lets me store a phone number that pauses 3 seconds (say before entering an IVR selection or extension) or WAIT for me to press something to continue. Again, not sure what numbers you think it stores for those behind the scenes.
They show you how they save it by placing separation marks inside the sequence of symbols.
Just don't ignore the signs. 🙂
Or it means your phone dials that number anyway, but the network is smart enough to recognize that you specified the same country the network is on, and route the call accordingly.
No it does not mean that.
Our local newspaper regularly publishes letters from the readers (mainly elderly one, who use not so smart old phones) which dial numbers as they are presented in, say, Yellow Pages, including the city codes and then charged with their telco for long distance calls.
The papers raised the issue with the telcos but they responded that they cannot do much about that - as soon as they receive initial digit "0" (operator) the call i redirected to another commutator, and the following sequence of digits is processed over there.
I tried it myself - and yes, I was charged for a long distance call despite I was calling my neighbour.
I am not sure that that experience should be the basis for asserting some sort of universal best practice for storing phone numbers in any database, particularly since a great many (perhaps an overwhelming majority) of them are in no way connecting to any sort of automated dialing system.
“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
You may find more of these here:
http://www.goodreads.com/quotes/tag/majority
I cannot be sure my practice should be taken as a universal best practice for all - the scope of testing was extremely limited.
But the practice which failed even within this limited scope should definitely never be used ever.
You never know how your data will be used, so you better keep in in order.
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.
Those people who separated them on paper forms might had a point, don't you think? 😉
I am also not sure how you are handling leading zeroes in your best practice, and still not sure what you are labelling your various phone number columns, since their significance changes country to country (and sometimes varies based on mobile or not). But still eminently curious if you'd like to further propose a best practice.
Leading zeroes are stored in the dialing rules pattern, not in the phone numbers.
When long distance/international codes are present and different from the dialing location the sequence builder adds them where needed.
Keep in mind - they are not always leading zeroes, they may be "1" as in Australia, or "8" as in Russia, or whatever else those politicians will invent tomorrow.
That's another reason to keep country-specific prefixes and definitions away from actual numbers.
_____________
Code for TallyGenerator
May 5, 2015 at 9:07 pm
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.
May 5, 2015 at 10:04 pm
Nevin,
Let's get rid of the nonsense.
Here is a real life NZ number:
Micrisoft New Zealand
09-362 5800
To call it from abroad you need to dial
{you country international access code} 64 9 362 5800
To call it from Auckland, NZ you need to dial 362 5800
Now, which string in saved in an Android phones of MS employees which allows them to call this number from different countries?
_____________
Code for TallyGenerator
May 5, 2015 at 10:56 pm
Sergiy (5/5/2015)
Nevin,Let's get rid of the nonsense.
Here is a real life NZ number:
Micrisoft New Zealand
09-362 5800
To call it from abroad you need to dial
{you country international access code} 64 9 362 5800
To call it from Auckland, NZ you need to dial 362 5800
Now, which string in saved in an Android phones of MS employees which allows them to call this number from different countries?
First, the MS employee is getting fired for not having a windows phone.
Then,
+64 9 362 5800
If you can't parse that from a string I'm curious how you parsed it into three separate numeric fields instead since, again, there was zero validation and it was entered all at once, not in separate fields, and could have been entered in any country.
The + implies it is an international number, so you can scan the next characters against the country code of the dialling network (the codes don't have subsets). If it finds a match it strips the country code. If it doesn't it adds the international dialing code for its network and dials.
Now I don't know if New Zealand will let you dial an Auckland Number from Auckland with the area code still attached. If it will, you're home. If it won't your phone then needs to know the area code it is in and do the same thing it did with the country code ... strip it if it matches, add the long distance prefix if it doesn't.
There is nothing here that can be done with the phone number stored as many numberic fields that CAN'T also be accomplished by it being stored within a string, because the dialler needs to be able to parse the string input regardless as you can simply enter the characters and press dial.
May 5, 2015 at 11:07 pm
Google's common Java, C++ and JavaScript library for parsing, formatting, storing and validating international phone numbers. The Java version is optimized for running on smartphones, and is used by the Android framework since 4.0 (Ice Cream Sandwich).
https://github.com/googlei18n/libphonenumber
Mapping Phone Numbers to carrier
PhoneNumber swissMobileNumber =
new PhoneNumber().setCountryCode(41).setNationalNumber(798765432L);
PhoneNumberToCarrierMapper carrierMapper = PhoneNumberToCarrierMapper.getInstance();
// Outputs "Swisscom"
System.out.println(carrierMapper.getNameForNumber(swissMobileNumber, Locale.ENGLISH));
_____________
Code for TallyGenerator
Viewing 15 posts - 46 through 60 (of 76 total)
You must be logged in to reply to this topic. Login to reply