1. ホーム
  2. 質問と答え
  3. SQL Server - Null列のパフォーマンス/サイズの欠点

SQL Server - Null列のパフォーマンス/サイズの欠点

2009-03-10 13 views
9

私は、約10個のフィールドに多くのNULL値を含む可能性があるテーブル設計に取り組んでいます。おそらくフィールドが使用されない時間の75％です。SQL Server - Null列のパフォーマンス/サイズの欠点

偽のデータ（100万レコード）を生成しただけで、SQL Server 2005への影響を検出できませんでした。サイズの違いはKB単位でした。性能 - 3つの非ヌル化可能な列に索引を追加した後、測定可能な差異はありません。

私は、SQL Server 2008にスパース列機能があることを知っています（次のSharePointのUserDataテーブルで使用されると想定しています）。私は私のコードが2005年に動作するようにしたい。 現在のSharePoint UserDataテーブルの設計には、多くのNULL値が存在します。 Microsoftのために十分なのであれば...

SQL Serverテーブルの多くのNULL値の周りに欠点や脆弱性に関するホワイトペーパーがありますか？誰でも10ミルまたは100ミルの記録にスケールアップする際に何が起こったかについての経験はありますか？

出典

2009-03-10 BuddyJoe

答えて

7

ギグサイズ100のデータベースであっても、複数のNULL列のパフォーマンスに問題はありませんでした。これらのフィールドでインデックスを実行してからクエリでnullを使用すると、問題が発生する可能性がありますが、これを個人的に問題として見たことはありません。次に、3を除くすべてのフィールドがNULL可能であるデータベーステーブルは作成していません。

一方、ほとんどのデータがnullの場合、アーキテクチャの問題が発生します。一般的な理由は、a）不適切に正規化されたデータベースか、b）データベースにコミットする前にデータを「ビルド」するための別のテーブルを作成するのではなく、ユーザーがエンドテーブルのデータをステージングできるようにすることです。

データベースの最適なアーキテクチャを決定するのはあなた次第です。

  • オプションのデータ

    • 例えば、私は」

    • 必要なデータ：私は非常に一般的である。このような状況で何

    出典

    2009-03-10 21:28:16

    +1

    +1。アドバイスをいただきありがとうございます。 – BuddyJoe

    +0

    $ Gregory A Beamer - 正規化の結果が複数のリンクテーブルの場合はどうなりますか？私はcurently 7つのリンクテーブルがあり、私はこれらをマージしようと思っています - > http://stackoverflow.com/questions/5604435/should-i-merge-my-link-tables – Steven

    -1

    未使用カラムが75％のテーブルを作成しないでください。いつでも使用する列を作成し、他の列にはEAVのようなものを使用するか、別の表に入れてください。

    出典

    2009-03-10 21:25:40

    +0

    に係合することがあり注意して使用する必要があります異なるテーブルのアイデア。なぜなら、私は常に10のフィールドが変わることはないからです。 CouchDB、SimpleDB、Notesなどの柔軟なスキーマではありません。 – BuddyJoe

    +0

    10個のフィールドが決して変更されない場合は、別のテーブルを使用するように追加してください。 –

    2

    私が以前に持っていた問題は、NULL値を持つことのプログラム上の影響に対処しています。たとえば、クライアントに関する問題、またはヌル値がそこにあるために期待されないときにデータを返すクエリーに含まれない問題。

    出典

    2009-03-10 21:26:03 JoshBerke

    2

    さて、NULLはデータベースでは常に奇妙なものです。私はそれがあなたのケースでパフォーマンスの影響をあまり受けないとは思わない - もちろん、すべてのNULL値を別々に扱わなければならないだろう。

    可能な限り、私は代わりにデフォルト値を使用するように努力しています。 INT型のあるID値は、 "値なし"インジケータとして0または-1を使用できます。そうすれば、値のチェック（フィールド< 0）を避け、NULLを個別にチェックする（フィールドIS NULLまたはIS NOT NULL）ことを避けることができます。

    マルク・

    出典

    2009-03-10 21:26:16

    0

    必ずする唯一の方法があります。 100万レコードを挿入し、エンドツーエンドのパフォーマンスを測定します。

    出典

    2009-03-10 21:26:17

    +0

    私は方法としてこれに同意しますが、表面上の何が悪いアーキテクチャであるかをテストするのは比較的厄介な方法です。 –

    +0

    合意し、今後別の列を追加することは不可能に近いでしょう。 – GateKiller

    6

    は、二つのテーブルにアップしたデータを分割することです現在コミュニティのウェブサイトを作成しており、テーブルの1つは明らかにユーザーテーブルになります。私は、ユーザーに関する大量の情報を記録していますので、私は2つのテーブルに私が収集したデータを分割していますUserDetails

    ユーザー表は私の基本的な情報が含まれてい

    • ユーザー
    • ユーザー名、名前、セッション情報などのすべての時間が必要になります。

      UserDetailsテーブルには、プロフィールページ、メールアドレス、パスワード、ウェブサイトアドレス、生年月日などのように、私が頻繁に必要としない追加情報が含まれています。

      これはvertical partitioningとして知られています。

    出典

    2009-03-10 21:28:57 GateKiller

    +0

    +1新しい用語をありがとう。私は行って、今それについていくつかの読書をしなければならないでしょう。何百万というレコードに100億になると、この戦略でどのようなパフォーマンスが得られるのだろうかと思います。物事が修正された場合、1対1のJOINはそれほど費用がかかりません。 – BuddyJoe

    +0

    問題はありません:)レコード全体を表示する必要がある場合にのみ、情報に参加してください。必要なデータは、検索、閲覧、一覧表示などに使用する必要があります.1つの大きなテーブルよりも少し遅いかもしれませんが、はるかにスケーラブルです。 – GateKiller

    1

    カラムにNULLがある確率が高いほど、レコードの最後に近いほど、カラムはテーブルにある必要があります（テーブルのカラムをラストする）。
    行の最後のNULLSにスペースが割り当てられていない場合は、各レコードにリンクされたNULL BITMAPによって決定されます（2バイトで、各ビットはNULL値であることを意味します）記録する）。

    ここで、NULL値は列から読み取られず、NULLビットマップから読み取られます。 NULLが検出されると、実際の値の読み取りが

    をスキップし、疎な特徴は、それがパフォーマンスのために非NULL値 のための時間と空間のオーバーヘッドを呼び出すように、あなたが考えるfiltered indexing on non-null part of a column

    出典

    2010-10-22 08:57:26

    関連する問題

     関連する問題