1

ログに記録されたイベントのデータベースを管理する Web アプリケーション (ASP.NET を使用してプログラム) を計画しています。データベースは SQL Server 2008 で管理されます。各イベントは、一連の「ユニット」から発生する場合があります。ユーザーは、ASP.NET インターフェイスを介してこれらの「ユニット」を追加および削除できます。

各「ユニット」は、最大で 100 万、あるいはそれ以上のエントリをログに記録できる可能性があります。(カットオフは日付によって管理されます。例:

DELETE FROM [tbl] WHERE [date] < '01-01-2011'

私が持っている質問は、そのようなデータベースを構築するための最良の方法は何ですか:

  1. 次のように、すべての「ユニット」のすべてのエントリを 1 つのテーブルに配置します。

    CREATE TABLE tblLogCommon (id INT PRIMARY INDEX, 
                           idUnit INT, 
                           dtIn DATETIME2, dtOut DATETIME2, etc INT)

  2. または、「ユニット」ごとにテーブルを分けることにより、次のようになります。

    CREATE TABLE tblLogUnit_1 (id INT PRIMARY INDEX, dtIn DATETIME2, dtOut DATETIME2, etc INT)
CREATE TABLE tblLogUnit_2 (id INT PRIMARY INDEX, dtIn DATETIME2, dtOut DATETIME2, etc INT)
CREATE TABLE tblLogUnit_3 (id INT PRIMARY INDEX, dtIn DATETIME2, dtOut DATETIME2, etc INT)
--and so on
CREATE TABLE tblLogUnit_N (id INT PRIMARY INDEX, dtIn DATETIME2, dtOut DATETIME2, etc INT)

エントリを参照するという観点からすると、アプローチ 1 の方が簡単に思えます。アプローチ 2 では、変数 N 個のテーブルを処理する必要があるからです (ユーザーは「ユニットの追加と削除が許可される」と述べたように)。

ただし、アプローチ 1 では、後でこれらのログ エントリへのアクセスが非常に非効率になる可能性があります。ASP.NET インターフェイスを介して、これらのログからレポートを生成する必要があります。

コーディングを始める前に、あなたの意見を聞きたいですか?

編集:テーブル内の列の数が違いを生むことに気づきませんでした。悪い！テーブルの実際の列数は 16 です。

4

4 に答える 4

3

テーブルは（幅に関して）それほど大きくないように見え、インデックスを適用して検索/選択を改善できるため、アプローチ1を使用します。

これに加えて、パーティション化されたテーブルとインデックスを確認することもできます。

パーティション テーブルとインデックスの作成

于 2012-08-15T03:58:27.193 に答える
1

別々のテーブルに分割すると、挿入と検索の速度が向上します。

1 つのテーブルの違いは、idUnit のインデックスです。そのインデックスを使用すると、個別のテーブルとほぼ同じ速度で検索できます (単一のクエリで idUnits 全体を検索できます)。1 つのテーブルがヒットする場所は挿入ですが、それは小さなヒットです。

于 2012-08-15T13:49:48.280 に答える
0

このデータをどのように使用するかによって大きく異なります。データを複数のテーブルに分割する場合、複数のテーブルに対してクエリを実行するのでしょうか、それともすべてのクエリが定義された日付範囲内にあるのでしょうか。データが挿入および更新される頻度。

言い換えれば、正解はありません！

また、パーティションテーブルを使用するためにSQLエンタープライズのライセンスを購入できますか？

于 2012-08-15T08:06:51.867 に答える
0

SQL Server 2008 Express を使用して、ローカル コンピューター接続を使用し、ネットワーク遅延なしで実際のデータに対していくつかのテストを行いました。これがテストされたコンピューター: デスクトップ、Windows 7 Ultimate、64 ビット、CPU: i7、@2.8GHZ、4 コア。RAM: 8GB; HDD（OS）：1TB、260GB空き。

最初に、すべてのレコードが「SINGLE」テーブルに配置されました (アプローチ #1)。すべてのレコードはランダム データで生成されました。それぞれの特定の「unitID」を処理する複雑な SELECT ステートメントが、CPU 負荷: 12% から 16%、RAM 負荷: 53% から 62% で 2 回 (次々と) 試行されました。結果は次のとおりです。

UnitID   NumRecords   Complex_SELECT_Timing
1        486,810      1m:26s / 1m:13s
3        1,538,800    1m:13s / 0m:51s
4        497,860      0m:30s / 0m:24s
5        497,860      1m:20s / 0m:50s

次に、同じレコードが同じ構造を持つ 4 つのテーブルに分割されました (アプローチ #2)。次に、同じ PC で、CPU と RAM の負荷を同じにして、同じSELECT ステートメントを前と同じように 2 回実行しました。次に結果です。

Table   NumRecords   Complex_SELECT_Timing
t1       486,810      0m:19s / 0m:12s
t3       1,538,800    0m:42s / 0m:38s
t4       497,860      0m:03s / 0m:01s
t5       497,860      0m:15s / 0m:12s

興味のある方にシェアしようと思いました。これはほとんどあなたの答えを与えます...

貢献してくれたみんなありがとう！

于 2012-08-16T08:36:38.647 に答える