2010-12-13 11 views
1

私は、プライマリキーとして自動インクリメントフィールド(ID)を使用するテーブルを持っています。テーブルは追加のみで、行は削除されません。テーブルは、一定の行サイズを持つように設計されています。データベース行へのO(1)アクセスは可能ですか?

したがって、私はファイル(ID * row_size)内でシークする正確な位置を計算するのが簡単であるため、任意の値をIDとして使用してO(1)アクセス時間を持つことを期待していました。

私はSQL Serverを使用しています。
それは可能ですか?したがって

おかげ

+1

O(1)に近づく唯一の時間はハッシュです。 – KevinDTimm

+1

@KevinDTimm - テーブルに行が1つしかない場合。 :) – Joe

答えて

2

あなたにとって重要なのはパフォーマンスだと思います。 データベースは、インデックスを使用してディスクに書き込まれたレコードにアクセスします。通常、このログであるB +ツリーインデックスを用いて行われ

内部ノードのためのBは、典型的には、100と200の間にあるB Nこれはまだ厳密に対数話している

を(refを参照して、サイズをブロックするように最適化されました)パフォーマンスは良いですが、数え切れないほどのレコードがあれば、リーフノードには3〜4ステップで到達できます。クエリプランニング、セッション開始、ロックなどのオーバーヘッドとともに(これはどうにかなるでしょうマルチユーザー、ACID準拠のデータ管理システムが必要な場合)は確かに一定の時間に匹敵するすべての実用的な理由です。

3

、私は

、(ID * row_size)ファイルに を求めるための正確な位置を計算する 容易であるので、IDとして任意の値を用いてO(1)アクセス 時間を有することが期待さ

ああ。いいえ。オートインクリメントは、削除されていなくても、穴がないことを保証しません。 Holes =インデックスを介して検索します。エルゴ:あなたの前提は間違っています。

1

インデックス付きの読み込みはO(log(n))であり、nの値が大きい場合はO(1)にかなり近くなります。これは、この文脈ではO表記はあまり有用ではなく、実際のタイミングははるかに意味があると言いました。

0

行を直接アドレス指定することができたとしても、クライアントとサーバーのプロトコルスタックを経由してさまざまな検索とメモリ割り当てを実行しなければ結果が得られません。あなたは実用的ではない何かを期待しているようです。本当の問題は何ですか? SQL Serverはあなたのために十分に速くないのですか?その場合は、パフォーマンスを向上させるために使用できる多くのオプションがありますが、ファイル内のアドレスを直接検索することはその1つではありません。

0

できません。 SQL Serverは、キーとインデックスの値に基づいてツリー形式の構造にデータを編成します。 DBの意味における「索引」は、参照帳の索引によく似ており、配列やリストのような索引付けされたデータ構造に似ていません。索引付けされた値を検索するときは、せいぜい、対数パフォーマンスを得ることができます(PKは通常インデックスとして扱われます)。最悪の場合は、索引付けされていない列の表スキャンであり、これは線形です。データベースが非常に大きくなるまで、うまく設計された表に対するよく設計された問合せのシーク時間は、ネットワークまたは名前付きパイプを介してそれを送信するのに必要な時間に比べて薄くなります。

関連する問題