SQL Server 2005で電話番号を格納するために使用するデータ型は何ですか？

電話番号をテーブルに保存する必要があります。どのデータ型を使用すべきか提案してください。 待つ。返信する前に読んでください。

営業担当者はこのフィールドを検索（ワイルド文字検索を含む）に使用できるため、このフィールドにはインデックスを付ける必要があります。

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

任意の提案を歓迎します。

更新：ソースデータを制御できません。xmlファイルの構造が標準であることだけです。xmlの解析を最小限に抑えたい。データベースに登録されると、取得は迅速になります。この辺りで起こっているクレイジーな提案の1つは、Ajaxオートコンプリート機能でも機能するはずだということです（営業担当者は一致するものをすぐに確認できます）。ああ、神様！！

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

• 国際番号？
• 拡張機能？
• 実際の数以外のその他の情報（「ボビーを求める」など）？

これらすべてが「いいえ」の場合、10文字のフィールドを使用して、数値以外のデータをすべて削除します。最初のフィールドがyesで、他の2つがnoの場合、2つのvarchar（50）フィールドを使用します。1つは元の入力用で、もう1つはすべての非数値データがストライプ化されてインデックス作成に使用されます。2または3が「はい」の場合、拡張機能やその他のデータを判別して適切に処理するために、2つのフィールドとある種のクレイジーなパーサーを実行すると思います。もちろん、インデックスを作成するときに余分な文字を削除するインデックスを使用して2番目の列を回避することもできますが、2番目の列を作成し、おそらくトリガーを使用して文字を削除します。

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

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

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

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

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

米国の電話番号のみを保存する場合は、CHAR（10）を使用してください。数字以外のすべてを削除します。

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

私は場合は午前何かを明らかに不足している誰かがそれを指摘するならば、私はそれを愛するだろう...

varchar（22）を使用します。内線付きの北米の電話番号を保持するのに十分な大きさ。厄介な '（'、 '）'、 '-'文字をすべて削除するか、すべてを1つの統一された形式に解析する必要があります。

アレックス

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

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

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

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

データを正規化してから、varcharとして保存します。正規化には注意が必要です。

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

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

単に他の文字列と同じように扱うことに決めたら、不良データ、不思議な電話番号のフォーマットなど、ポップアップするものに関する避けられない問題の克服に集中できます。課題は、データをどのように保存するかではなく、データの適切な検索戦略を構築することです。収集を制御できなかった大量のデータを処理しなければならないことは、常に困難な作業です。

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

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

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

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

電話番号などの複数値の属性に対して個別のテーブルを用意することをお勧めします。

ソースデータを制御できないため、XMLファイルからデータを解析して適切な形式に変換し、特定の国の形式に問題がないようにして、別のテーブルに保存し、インデックス作成と両方の検索が効率的になります。

ありがとうございました。

このスレッドは古いと思いますが、特に.NET Frameworkで、フォーマットの目的で数値型として格納することの利点について言及する価値があります。

IE

.DefaultCellStyle.Format = "(###)###-####" // Will not work on a string

代わりにlongデータ型を使用してください。intは-32,768〜32,767の整数しか使用できないため使用しないでください。ただし、longデータ型を使用する場合は、-2,147,483,648〜2,147,483,647の数値を挿入できます。