We want to store 10 digit mobile number i.e.9999999999. Should it be numeric or string datatype? We don't want to do any calculative or manipulation operation on this
Which is better memory and performance wise?
Mobile phone numbers are not stored as integers, as the integer data type holds values that have the potential to be used in calculations. There is no context for using a mobile phone number as part of a calculation, so it is stored as a STRING value.
I recommend using a string since that gives you more flexibility when it comes to formatting and non numeric characters like extension etc. Show activity on this post. I would suggest using String - aside from anything else, otherwise you won't be able to store leading zeroes.
I generally use VARCHARs to store telephone numbers. Storage is not so expensive these days that I benefit that much from the savings found by storing them as numeric values.
Expressing a telephone number in a different base would render it meaningless. Adding or multiplying two telephone numbers together, or any math operation on a phone number, is meaningless.
It must be a string
as phone number will exceed the limit of int
or even long
. So for handling those scenario string
is always prefered.
ITU-T recommendation E.164 says you need 3 digits for the country code and up to 15 digits for the directory number within the country dialing plan.
And, many people add some punctuation. For example:
+1.212.555.1212 is a North American number. It could also be rendered (212) 555-1212 in a North American centric app.
32 characters of text should do the trick worldwide.
DO NOT use a number, or you'll be sorry. I was: two things.
2.12555E+09
That's almost as stupid as SIRI telling me you have call from two bllion, one hundred twenty five million....Telephone directory numbers are not numeric data types. Take a look at this: Falsehoods Programmers Believe About Telephone Numbers.
A couple of things that are good to keep in mind:
In general, a number that you're not planing to do calculations on, should be stored as a form of string. If you need the number to be able to start with a zero (as you do, because some phone numbers do), this is essential.
Ergo, even if (or when) you're able to store a phone number as a huge integer (you're able to with 64 bit integers), you shouldn't. You will loose data as soon as a number starts with a zero.
When storing a phone number, remember that the country code is a special type of information. You would do best if you separate this from the rest of the number when you store it. This way you can easily query phone numbers by country, and you won't have to deal with parsing of the number more than once (before you store it, rather than every time you fetch it). Also, if you store a phone number together with the country code, you'll need to validate the thing to ensure you always store the country code, because two numbers from two different countries could potentially be identical if one has a country code and the other one doesn't.
Also remember that punctuation is a method of presentation, and thus has nothing to do with the way you store the data. You can always choose to present data the way you want, and the way you want will in all cases depend on a number of factors. For example what kind of data you're presenting, to whom you're presenting it, and in some cases even when you're presenting the data. In the case of phone numbers, you should store the number as a string, without any of the punctuation.
I would recommend that you have a look at Google's library for parsing, formatting and validating international phone numbers (https://github.com/googlei18n/libphonenumber). You can feed this library your phone number and country code, and it will give you a whole lot of useful information about it, such as whether the number is possible and valid, which region it belongs to, what kind of number it is, etc.
Pro tip I: Provide your users with a way to select which country the number belongs to, rather than having them type the country code. Better for you, and better for your users.
Pro tip II: There's rarely such a thing as a "North American centric app" or "insert region here centric app", especially if your app is available on the web. It does happen, but it is rare, so you would be wise to prepare your app for the world, rather than a smaller part of it.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With