私が働いた最後の 3 つの会社では、電話番号の列は varchar(n) 型です。その理由は、拡張機能 (ext. 333) を保存する必要があるためです。ただし、いずれの場合も、挿入および更新時に「-」文字が取り除かれます。「.ext」文字は保存できるのに「-」文字は保存できない理由がわかりません。他の誰かがこれを見たことがありますか? このようにする理由は何だと思いますか? 格納したいのが数値だけなら、int フィールドを使用したほうがよいのではないでしょうか? 逆に、数値を文字列/varchar として保存する場合は、すべての文字を保持し、表示時の書式設定や書き込み時の消去に煩わされる必要はありません。
また、電話番号の保存が他の場所で実装されている他の方法についても聞きたいです。
簡単なテスト: 電話番号を加算/減算/乗算/除算しますか? いいえ。SSN と同様に、電話番号は実際の番号を含むことができる個別のデータであるため、おそらく文字列型が最も適切です。
電話番号を格納する 1 つのポイントは先頭の 0 です。
例: 01202 8765432
int 列では、0 が取り除かれ、電話番号が無効になります。
私は推測を危険にさらします-スペースと交換されるのは、実際には何の意味もないからです
例: 123-456-789 = 123 456 789 = 123456789
個人的には、電話番号がどこからのものかによって、意味が異なる可能性があるため、文字を削除することはありません. 電話番号は、入力したとおりの形式のままにしておいてください。これは、入力した人が見慣れている方法であることは明らかです。
電話番号を「数字」としてではなく、文字列として保存すると考えることができるもう 1 つの理由は、多くの場合、データベース (PHP、私はあなたを見ています) にアクセスするために使用するソフトウェア スタックの十分な部分がそうではないからです。より長い電話番号やエキゾチックな電話番号の一部を格納できるように、(ネイティブに) 十分な大きさの整数をサポートします。
32 ビットが符号なしで伝送できる最大数は 4294967295 です。これは、ロシアの携帯電話番号だけでは機能しません。たとえば、4959261234 のような番号です。
そのため、32 ビットを超える数値データを運ぶ方法を見つけるのに、さらに不便を感じることになります。データベースは長い間非常に大きな整数をサポートしてきましたが、ショーストッパーのためにチェーン内の不良リンクが 1 つあれば十分です。再びPHPのように。
一貫性がある限り、どのように保存するかは問題ではありません。通常はフォーマット文字を取り除きますが、これらの値を照会する必要がある場合は、国コード、市外局番、交換局、および内線番号を個別に格納することもできます。繰り返しますが、要件は一貫性があることです。それ以外の場合、クエリは PITA です。
良いもの！重要な点は、電話番号のフォーマットは実際にはデータの一部ではなく、ソース国の側面であるということのようです。それでも、数値の拡張子部分をそのままにしておくと、データからフォーマットを分離するというモデルを破っている可能性があります。すべての国が拡張機能を説明するために同じ構文/形式を使用しているとは思えません。さらに、電話システムとの統合が（可能性のある）要件である場合は、内線番号を個別に保存し、期待どおりにメッセージを作成する方がよい場合があります。しかし、Markはまた、一貫性がある場合は、クエリと処理も一貫して行うことができるため、どのように保存するかは問題にならないという良い点も示しています。
他の質問へのリンクをありがとうエリック。
数字を文字列として保存し、表示コードにさまざまな "()" と "-" を追加することを選択します。国際番号の場合はさらに難しくなります。国に応じてさまざまな「国際化」された表示形式で対応しています。
電話番号が北米などの特定の地域内にのみあることがわかっている場合、私がやりたいことは、エントリを 4 つのフィールドに変更することです。市外局番に 3、プレフィックスに 3、回線に 3、内線に 5 などです。次に、これらを '-' と拡張子を指定する 'e' を使用して 1 つのフィールドとして挿入します。もちろん、検索も同じプロセスに従う必要があります。これにより、より定期的なデータを取得できるようになり、- と内線番号を削除すると、実際に電話をかけるために番号を使用することもできます。元の 4 フィールドにも簡単に戻せます。
データベース テーブルが別のシステム (たとえば、ある種の IP テレフォニー) を駆動する場合、一部の文字を削除して他の文字を許可すると、影響が生じる可能性があります。関連するシステムによっては、etc.333 をサフィックスとして使用することは正当である場合がありますが、開発者は文字列内の「-」を考慮していない可能性があります (はい、私はここで推測しています...)
int ではなく varchar として格納することに関しては、これは私にとって単なる常識です。前に述べたように、int フィールドでは先頭のゼロが削除される可能性があり、int フィールドに対するクエリは暗黙の数学関数を実行する可能性があります (テキストから「-」を削除することも説明できます。555-1234 を入力して、 -679として保存されましたか？）
要するに、正確な理由はわかりませんが、いくつかの可能性を推測できます。