[解決済み] 正規化された電話番号をデータベースに格納するための規格はありますか？

質問

データベースのフィールドに電話番号を格納するための良いデータ構造とは何でしょうか。 国際的な番号を扱うのに十分柔軟性があり、また、番号のさまざまな部分を効率的に照会できるようなものを探しています。

編集してください。 ここでユースケースを明確にするために。私は現在、1 つの varchar フィールドに数値を保存しており、顧客が入力したとおりにしています。 そして、コードで番号が必要になったとき、私はそれを正規化します。 問題は、数百万行をクエリして一致する電話番号を見つけたい場合、次のような関数が必要になることです。

where dbo.f_normalizenum(num1) = dbo.f_normalizenum(num2)

というように、非常に非効率的です。 また、市外局番のようなものを探すクエリも、単一の varchar フィールドである場合は非常にやっかいになります。

[編集]

人々はここでたくさんの良い提案をしてくれました。更新として、私が今やっていることは次のとおりです。しかし、クエリ時に正規化するのではなく、レコードが挿入または更新されたときにすべての作業を行うトリガーを持っています。そのため、クエリが必要な部分にはint型またはbigint型を使用し、これらのフィールドはクエリをより速く実行するためにインデックス化されています。

どのように解決するのか？

まず、国番号以上の規格はありません。せいぜい、国番号によって特定の電話番号がどの国のものかを認識し、残りの番号をその国の形式に従って処理することくらいです。

しかし、一般に、電話機器などは標準化されているので、ある電話番号を次のような構成要素に分解することができる場合がほとんどです。

• C 国番号 1 ～ 10 桁 (現在は 4 桁以下ですが、変更される可能性があります)
• A 市外局番（州/地域）コード 0～10桁（実際には1つの市外局番ではなく、地域フィールドとエリアフィールドが別々に必要な場合があります。）
• E Exchange (プレフィックス、またはスイッチ) コード 0 ～ 10 桁
• L 回線番号 1～10 桁

この方法だと、国番号、地域番号、局番が同じなので、例えば近い人同士を見つけることができる可能性があります。携帯電話では、もはや当てになりませんが。

さらに、国によって規格が違う。アメリカでは（AAA）EEE-LLLにいつでも頼れるが、別の国では都市部では（AAA）EE-LLL、地方では（AAA）LLLLという単純な回線番号の交換が行われているかもしれないのだ。何らかの形でツリー状にトップから始めて、情報に応じてフォーマットする必要があります。 たとえば、国番号 0 は残りの番号の形式がわかっていますが、国番号 5432 の場合は、残りの番号を理解する前に市外局番を調べる必要があるかもしれません。

を処理したい場合もあるでしょう。 vanity のような数字も扱いたいと思うかもしれません。 (800) Lucky-Guy のような数字がありますが、これは、それが米国の番号である場合、桁数が 1 つ多いこと (そして、広告やその他の目的のために完全な表現が必要な場合がある) と、米国ではドイツとは異なる文字と数字の対応付けがあることを認識する必要があります。

また、後で戻って、状況が変化したときに数字を再パースできるように、あるいは、誰かが特定の国の形式を解析するための悪い方法を提出し、情報が失われた場合のバックアップとして、番号全体をテキスト フィールド (国際化あり) として別々に保存したいと思うかもしれません。