場合によっては、ピース・データを整数（4バイト）または文字列で表すことができます。例：bigint（8バイト）の電話番号、int（4）などの郵便番号など3つの列として索引値記述トリプレットの大きな表があり、インデックスは5桁の整数（順次ではありません）、我々はintとしてそれを持っています。 DBAはそれが貧弱な設計であると言っていますが、auto-inc PKのような保証された整数でない限り、そのようなデータを保存するには常にvarcharを使用する必要があります。同意しますか？なぜ、なぜそうではないのですか？データベース表の列データ型の設計に関する質問
あなたが行う必要があるのは、idを表す必要がある場合は、インデックス列としてVARCHARを使用することをお勧めします。第1に、VARCHARの索引付けには無駄な処理オーバーヘッドがあります。オーバーヘッドは、索引付けの目的でVARCHAR値を比較前にデータベースのCOLLATIONを介して変換する必要があるという事実に起因します。第二に、可変長データ型を持つ理由はありません。これは、非効率的な索引付けを可能にします。第3に、VARCHARとして整数を表すのにINTよりも5倍のスペースが必要です。これは、索引がVARCHARを使用して最大5倍大きくなることを意味します。最後に、数値データが列に入り込む可能性が常にあります。これはあなたのインデックスを蝕み、おそらくデータベースの参照整合性を破るでしょう。
私の経験則では、それに数学を行うつもりがなく、代理キーの代理キーまたはfkでない場合は、文字列データです。電話番号は、文字列である整数ではなく、郵便番号と同じです（US BTW以外の数字ではありません）。文字列として格納された数値には、INTまたは小数点として格納する先行ゼロ（米国の郵便番号を参照）が必要な場合が多く、有効な値を入力することはできません。それが自動生成されていない場合、どのように整数データである必要があることを知っていますか？もしあなたが100％正であるならば、それは整数以外のものであってはならない（そして先行ゼロがない）、それをintにすることは悪いデータが入ることを防ぐでしょう。しかし、本当に本当に確信してください。それは後でデータを文字列にします（国際化して、あなたのポジティブコードがもはや数字ではないことを知るときなど）。
あなたがやっていることについてより良いアドバイスをするには、あなたが話しているデータのタイプのより良い例が必要です。あなたのテーブルデータのニーズは完全に私には分かりません。
主に電話番号と郵便番号が記載されています。電話番号の数字を使用して、3 /エリアコード、7 /数字、5/extn-15の数字を構成します。いくつかのチェックはareacode> = 200などのように行われます。郵便番号<5桁 - 私たちはそれを作るために0を前に付けます5.我々は国際的ではないことを知っていますが、米国の顧客基盤のために開発しています。しかし、私はあなたの経験則が好きで、ちょっと噛んでください。 –
DBがOracleの場合、DBAが正しい可能性があります。 VARCHAR2型は、パーティションおよび索引の方がINTより効率的です。
さらに、INTフィールドで集計などをしないと、利益はありません。
DBはオラクルではありません（MySQLですが、今はオラクルと呼んでいますか？）私はそれらの分野で集計をしているとは思わない。 –
いいえ、まだ:)まだMySQLです。どのような「選択」文がありますか？ – Uordek
これは、私たちが最初に整数を選択した理由です - メモリの使用（ただし、5倍もかかっていませんでした）。挿入ステートメントはサーブレット・メソッドによって生成され、非数値データは関連する例外をスローします。だから私たちの主な関心事は、（1）メモリの使用と（2）効率でした - Integer.parseInt（ResultSet.getString（ "id"））ではなくResultSet.getInt（ "id"）が必要でした。 –
UnicodeバージョンのNVARCHARは最大5倍です。それ以外の場合は2.5倍です。 – ThomasMcLeod