テーブル

テーブルは、データベースのすべてのデータを格納するデータベース オブジェクトです。 テーブルでは、スプレッドシートのように、データが論理的に行と列の形式にまとめられます。 各行は一意なレコードを表し、各列はレコードのフィールドを表します。 たとえば、会社の従業員のデータを格納するテーブルを、各従業員に相当する行と、従業員の社員番号、姓名、住所、役職名、自宅の電話番号などの情報を格納する列から構成する場合があります。

• データベース内のテーブルの数は、データベースで許可されているオブジェクトの数 (2、147、483、および 647) によってのみ制限されます。 標準のユーザー定義テーブルは、最大で 1, 024 の列を持つことができます。 テーブルの行の数は、サーバーの記憶域容量によってのみ制限されます。

• テーブルやテーブルの各列にプロパティを割り当てて、許可されているデータや他のプロパティを制御することができます。 たとえば、列に NULL 値を許容しない制約を作成したり、値が指定されない場合の既定値を設定したりすることができます。また、テーブルにキー制約を割り当てて一意性を強制したり、テーブル間のリレーションシップを定義したりすることもできます。

• テーブル内のデータは、行ごとまたはページごとに圧縮できます。 データを圧縮すると、より多くの行をページに格納できます。 詳細については、「データの圧縮」を参照してください。

テーブルの種類

SQL Server には、標準的な役割を果たす基本的なユーザー定義のテーブル以外に、データベース内で特別な目的で使用される次のようなテーブルがあります。

• パーティション テーブル
  パーティション テーブルはデータが行方向に分割されているテーブルで、パーティションがデータベースの複数のファイル グループに分散される場合もあります。 大きなテーブルやインデックスをパーティション分割すると、コレクション全体の整合性を維持しながら、データのサブセットに対するアクセスや管理を迅速かつ効率的に行うことができるので、大きなテーブルやインデックスを管理しやすくなります。 SQL Server 2012 では、最大 15,000 個のパーティションを既定でサポートしています。 詳細については、「パーティション テーブルとパーティション インデックス」を参照してください。

• 一時テーブル
  一時テーブルは tempdb に格納されます。 一時テーブルには、ローカル一時テーブルとグローバル一時テーブルの 2 種類があります。 この 2 種類の一時テーブルでは、名前、表示設定、および可用性が異なります。 ローカル一時テーブル名の先頭には、番号記号 (#) が 1 つ付いています。このテーブルは、作成したユーザーの現在の接続でのみ表示され、このユーザーが SQL Server のインスタンスから切断すると削除されます。 グローバル一時テーブル名の先頭には、番号記号が 2 つ (##) 付いています。このテーブルは、作成されるとすべてのユーザーに表示され、このテーブルを参照するすべてのユーザーが SQL Server のインスタンスから切断すると削除されます。

• システム テーブル
  SQL Server では、サーバーの構成とすべてのテーブルの構成を定義したデータが、システム テーブルという特殊なテーブル セットに格納されます。 ユーザーは、システム テーブルに対して直接クエリや更新を行うことはできません。 システム テーブル内の情報は、システム ビューから入手できます。 詳細については、「システム ビュー (Transact-SQL)」を参照してください。

• 幅の広いテーブル
  幅の広いテーブルでは、スパース列を使用して、テーブルに持たせることができる列の合計数が 30,000 まで増加します。 スパース列は、NULL 値用にストレージが最適化されている通常の列です。 スパース列によって、NULL 以外の値を取得するためのオーバーヘッドは増大しますが、NULL 値に必要となる領域は削減されます。 幅の広いテーブルでは列セットが定義されています。これは、型指定されていない XML 表記であり、テーブルのすべてのスパース列を 1 つにまとめて構造化した出力です。 インデックスと統計情報の数も、それぞれ 1,000 と 30,000 に増加します。 幅の広いテーブルの最大行サイズは 8,019 バイトです。 そのため、特定の行のデータの大部分を NULL にする必要があります。 幅の広いテーブルの非スパース列と計算列の最大数は合わせて 1,024 のままです。

  幅の広いテーブルは、パフォーマンスに対して次のような影響を与えます。

  • 幅の広いテーブルは、テーブルのインデックスの管理にかかるコストを増加させる場合があります。 幅の広いテーブルのインデックスの数は、ビジネス ロジックで必要なインデックスの数に制限することをお勧めします。 インデックスの数が増加すると、DML のコンパイル時間および必要なメモリ容量も増加します。 非クラスター化インデックスは、データのサブセットに適用されるフィルター選択されたインデックスにする必要があります。 詳細については、「フィルター選択されたインデックスの作成」を参照してください。

  • アプリケーションでは、幅の広いテーブルから動的に列を追加したり削除したりできます。 列が追加または削除された場合、コンパイルされたクエリ プランも無効になります。 スキーマの変更が最小限になるように、予測されるワークロードに合わせてアプリケーションを設計することをお勧めします。

  • データが幅の広いテーブルから追加および削除される場合、パフォーマンスに影響が生じる可能性があります。 テーブルに対する変更が最小限になるように、予測されるワークロードに合わせてアプリケーションを設計する必要があります。

  • クラスター化キーの複数の行を更新する、幅の広いテーブル上での DML ステートメントの実行を制限します。 これらのステートメントのコンパイルおよび実行には、大量のメモリ リソースが必要になる場合があります。

  • 幅の広いテーブルでのパーティションの切り替え操作は、実行速度が遅く、処理に大量のメモリが必要になる場合があります。 パフォーマンスおよびメモリの要件は、切り替え元のパーティションと切り替え先のパーティションの両方の列の合計数に比例します。

  • 幅の広いテーブルの特定の列を更新する更新カーソルは、FOR UPDATE 句で明示的に列を列挙する必要があります。 これは、カーソルを使用する場合にパフォーマンスを最適化するのに役立ちます。

一般的なテーブルのタスク

次の表に、テーブルの作成や変更に関連する一般的なタスクへのリンクを示します。

次の表に、テーブル内の列の作成や変更に関連する一般的なタスクへのリンクを示します。

関連項目

概念

主キー制約と外部キー制約

UNIQUE 制約と CHECK 制約