SQL Server 2005で電話番号を保存するには、どのデータ型を使用する必要がありますか？
電話番号をテーブルに保存する必要があります。どのデータ型を使用すべきかを提案してください。 待ってください。返信する前に読んでください。
このフィールドは、営業担当者が検索（ワイルドキャラクター検索を含む）にこのフィールドを使用できるため、頻繁にインデックスを作成する必要があります。
現時点では、電話番号はさまざまな形式（XMLファイルから）になると予想されています。統一フォーマットに変換するためにパーサーを作成する必要がありますか？何百万ものデータ（重複）が存在する可能性があり、ソースデータが送信されるたびに（前処理が多すぎるなどのアクティビティで）サーバーリソースを使いたくありません。
どんな提案でも大歓迎です。
更新：ソースデータを制御できません。XMLファイルの構造が標準であるということだけです。XML解析を最小限に抑えたいと思います。一度データベースに入れれば、検索は迅速になります。ここでは、Ajaxオートコンプリート機能でも動作するはずです（営業担当者は一致するものをすぐに見ることができます）。OMG!!
これには以下が含まれますか：
- 国際番号？
- 拡張機能？
- 実際の番号以外のその他の情報（「ボビーに尋ねる」など）
これらすべてがいいえの場合、10文字のフィールドを使用して、すべての非数値データを取り除きます。最初がyesで、他の2つがnoの場合、2つのvarchar（50）フィールドを使用します。1つは元の入力用で、もう1つはすべての非数値データをストライプ化してインデックス作成に使用します。 2または3がyesの場合、2つのフィールドと何らかのクレイジーパーサーを実行して、拡張機能やその他のデータを判断し、適切に処理すると思います。もちろん、インデックスを作成するときに余分な文字を削除するインデックスを使用して、2番目の列を回避できますが、2番目の列を作成し、おそらくトリガーで文字を削除します。
更新：AJAXの問題に対処するために、あなたが思うほど悪くないかもしれません。これが現実的にテーブルに対して行われる主な方法である場合、私が言ったようにセカンダリ列に数字のみを格納し、その列のインデックスをクラスター化したものにします。
Varchar（15）を使用し、確かにそのフィールドにインデックスを付けます。
その理由は、国際標準は最大15桁をサポートできるからです。
国際電話番号をサポートしている場合は、World Zone CodeまたはCountry Codeを個別に保存して、クエリをより適切にフィルタリングし、電話番号フィールドの長さを解析および確認して、米国への折り返し電話を制限しないようにすることをお勧めします例
米国の電話番号のみを保存する場合は、CHAR（10）を使用します。数字以外はすべて削除します。
私はおそらくここで明白なことを見逃していますが、varcharはあなたの予想される最長の電話番号に十分な長さではありませんか？
もし私がam明らかな何かを見逃しているなら、誰かがそれを指摘してくれたらそれが大好きだ...
Varchar（22）を使用します。内線番号付きの北米の電話番号を保持するのに十分な大きさ。厄介な「（」、「）」、「-」の文字をすべて削除するか、それらをすべて1つの統一された形式に解析する必要があります。
アレックス
varcharの使用は非常に非効率的です。お金の種類を使用し、その中からタイプ「phonenumber」を宣言したユーザーを作成し、正の数字のみを許可するルールを作成します。
（19,4）と宣言すると、4桁の内線番号を保存でき、国際電話番号に十分な大きさで、9バイトのストレージしか必要ありません。また、インデックスは高速です。
SQL Server 2005は、インデックス付きのvarcharフィールドのテキストの部分文字列クエリ用に最適化されています。 2005年には、インデックスフィールドの文字列サマリーに新しい統計が導入されました。これは全文検索に非常に役立ちます。
「x」または「ext」を使用して拡張子を示すのはかなり一般的であるため、15文字（完全な国際サポート用）プラス3（「ext」用）プラス4（拡張子自体用）に合計22文字を許可します。それはあなたを安全に保つはずです。
または、入力で正規化して、「ext」が「x」に変換され、最大20になるようにします。
可能な限り標準化するための前処理を備えたnvarchar。拡張機能を抽出して、別のフィールドに保存することをお勧めします。
データを正規化してから、varcharとして保存します。正規化は難しい場合があります。
これは1回限りのヒットです。次に、新しいレコードが入力されると、それを正規化されたデータと比較します。非常に高速でなければなりません。
長さ制限のあるvarcharフィールドを使用します。
多くの異なる電話番号形式に対応する必要があるので（おそらく内線番号などを含める必要があります）、他のvarcharと同じように扱うのが最も理にかなっています。入力を制御できれば、データをより便利にするためにいくつかのアプローチをとることができますが、そのようには聞こえません。
単純に他の文字列として扱うことにした場合、不良データ、不可解な電話番号のフォーマット、その他のポップアップに関する避けられない問題を克服することに集中できます。私の意見では、データを保存する方法ではなく、データの適切な検索戦略を構築することが課題になります。収集を制御できない大量のデータを処理することは、常に困難な作業です。
SSISを使用して、情報を抽出および処理します。これにより、SQL Serverから分離されたXMLファイルの処理が可能になります。必要に応じて、別のサーバーでSSIS変換を実行することもできます。 VARCHARを使用して、電話番号を標準形式で保存します。 NVARCHARは不要です。これは、数字と、「+」、「」、「（」、「）」、「-」などのいくつかの文字について話しているためです。
私はこのスレッドが古いことを認識していますが、特に.NETフレームワークで、書式設定の目的で数値型として格納する利点に言及する価値があります。
IE
.DefaultCellStyle.Format = "(###)###-####" // Will not work on a string
電話番号などの複数の値を持つ属性に対して個別のテーブルを用意することを常にお勧めします。
ソースデータを制御できないため、XMLファイルのデータを解析して適切な形式に変換し、特定の国の形式に問題が生じないようにし、別のテーブルに保存して、 インデックス作成と取得の両方が効率的です。
ありがとうございました。