92

電話番号をテーブルに保存する必要があります。どのデータ型を使用すればよいか教えてください。 待って。返信を押す前に読んでください..

営業担当者はこのフィールドを検索 (ワイルド キャラクタ検索を含む) に使用できるため、このフィールドには十分なインデックスを付ける必要があります。

現時点では、電話番号は (XML ファイルから) さまざまな形式で提供されることを期待しています。統一フォーマットに変換するためにパーサーを作成する必要がありますか? 何百万ものデータ (重複を含む) が存在する可能性があり、ソース データが通過するたびにサーバー リソースを拘束したくありません (前処理などのアクティビティで)。

どんな提案も大歓迎です..

更新:ソース データを制御することはできません。ただxmlファイルの構造は標準です。xml の解析を最小限に抑えたいと考えています。データベースに入ると、取得は迅速に行われます。ここで行われているクレイジーな提案の 1 つは、Ajax AutoComplete 機能でも動作するようにすることです (そのため、営業担当者は一致するものをすぐに確認できます)。ああ、神様！！

4

16 に答える 16

65

これには以下が含まれますか?

  • 国際番号？
  • 拡張機能?
  • 実際の番号以外の情報 (「ボビーを頼む」など) はありますか?

これらすべてが「いいえ」の場合、10 文字のフィールドを使用して、数値以外のデータをすべて取り除きます。最初のフィールドが「はい」で他の 2 つが「いいえ」の場合、2 つの varchar(50) フィールドを使用します。2つまたは3つが「はい」の場合、2つのフィールドとある種のクレイジーなパーサーを実行して、拡張またはその他のデータが何であるかを判断し、適切に処理すると思います。もちろん、インデックスを作成するときに余分な文字を削除するインデックスで何かを行うことで、2 番目の列を回避できますが、2 番目の列を作成し、おそらくトリガーで文字の削除を行います。

更新: AJAX の問題に対処するには、思ったほど悪くないかもしれません。これが実際にテーブルに対して行われる主な方法である場合は、前述のように数字のみをセカンダリ列に格納し、その列のインデックスをクラスター化されたものにします。

于 2008-09-16T18:02:48.187 に答える
47

varchar(15) を使用し、そのフィールドに確実にインデックスを付けます。

その理由は、国際規格が最大 15 桁をサポートできるためです。

ウィキペディア - 電話番号の形式

国際番号をサポートしている場合は、ワールド ゾーン コードまたは国コードを個別に保存してクエリをより適切にフィルタリングし、電話番号フィールドの長さを解析およびチェックして米国への返される通話を制限する必要がないようにすることをお勧めします。例

于 2008-09-16T18:03:29.683 に答える
5

米国の電話番号のみを格納する場合は、CHAR(10) を使用します。数字以外のすべてを削除します。

于 2008-09-16T18:00:49.503 に答える
3

私は varchar(22) を使用します。内線付きの北米の電話番号を保持するのに十分な大きさ。厄介な「(」、「)」、「-」文字をすべて取り除くか、それらすべてを 1 つの統一された形式に解析する必要があります。

アレックス

于 2008-09-16T18:00:33.170 に答える
3

私はおそらくここで明らかなことを見逃していますが、予想される最長の電話番号に十分な長さの varchar がうまく機能しませんか?

明らかな何かが欠けている場合は、誰かが指摘してくれるとうれしいです...

于 2008-09-16T18:00:02.420 に答える
2

varcharの使用はかなり非効率的です。マネータイプを使用して、そこからユーザー宣言タイプ「phonenumber」を作成し、正の数のみを許可するルールを作成します。

（19,4）と宣言すると、4桁の内線番号を格納でき、国際番号に十分な大きさで、9バイトのストレージしか必要としません。また、インデックスは高速です。

于 2011-05-03T16:12:23.670 に答える
2

SQL Server 2005 は、インデックス付きの varchar フィールド内のテキストに対する部分文字列クエリ用に最適化されています。2005 年には、インデックス フィールドの文字列集計に新しい統計が導入されました。これは、全文検索に非常に役立ちます。

于 2008-09-16T18:02:01.543 に答える
2

nvarchar を前処理して、可能な限り標準化します。拡張機能を抽出して、別のフィールドに保存することをお勧めします。

于 2008-09-16T17:59:02.970 に答える
1

多くの異なる電話番号形式に対応する必要があるため (おそらく内線番号などを含める必要があるため)、他の varchar と同じように扱うのが最も理にかなっている場合があります。入力を制御できれば、データをより有用なものにするためにいくつかのアプローチを取ることができますが、そうは思えません。

単純に他の文字列として扱うことを決めたら、不正なデータ、不可解な電話番号のフォーマット、その他のポップアップに関する避けられない問題を克服することに集中できます。私の意見では、課題はデータの保存方法ではなく、データの優れた検索戦略を構築することです。収集を制御できない大量のデータを処理するのは、常に困難な作業です。

于 2008-09-16T18:05:57.180 に答える
1

拡張子を示すために「x」または「ext」を使用することはかなり一般的であるため、15 文字 (完全な国際サポート用) と 3 (「ext」用) と 4 (拡張子自体用) の合計 22 文字を許可します。 . それはあなたを安全に保つはずです。

または、入力を正規化して、「ext」が「x」に変換され、最大 20 になるようにします。

于 2013-07-22T09:34:23.890 に答える
1

データを正規化し、varchar として保存します。正規化は難しいかもしれません。

それは一度のヒットになるはずです。次に、新しいレコードが入ってくると、それを正規化されたデータと比較します。非常に高速である必要があります。

于 2008-09-16T17:59:44.480 に答える
1

varchar長さ制限のあるフィールドを使用してください。

于 2008-09-16T18:00:16.977 に答える
1

SSIS を使用して、情報を抽出して処理します。そうすれば、XML ファイルの処理を SQL Server から分離することができます。必要に応じて、別のサーバーで SSIS 変換を実行することもできます。VARCHAR を使用して電話番号を標準形式で保存します。数値と、「+」、「 」、「(」、「)」、「-」などの他のいくつかの文字について話しているため、NVARCHAR は不要です。

于 2008-09-16T18:09:01.510 に答える
0

代わりにデータ型 long を使用してください。-32,768 から 32,767 までの整数しか使用できないため、int は使用しないでください。

于 2020-04-02T20:31:58.887 に答える