0

毎日、さまざまなリソースの組み合わせの値を追跡する必要があります。したがって、これを行うテーブルは次のようになります。

CREATE TABLE `data` (
  `id` INT UNSIGNED NULL PRIMARY KEY AUTO_INCREMENT,
  `datetime` DATETIME NOT NULL,
  `res1` INT UNSIGNED NOT NULL,
  `res2` INT UNSIGNED NOT NULL,
  `res3` INT UNSIGNED NOT NULL,
  `res4` INT UNSIGNED NOT NULL,
  `res5` INT UNSIGNED NOT NULL,
  `value` DECIMAL(10,0) NOT NULL,
  UNIQUE INDEX `datetime_res1_to_res5` (`datetime`, `res1`, `res2`, `res3`, `res4`, `res5`)
)

res1～ ～は、res5それぞれのテーブルへの外部キーです。

このテーブルには多くの行が含まれ、簡単に 2,000 万に達するでしょう。

私が興味を持っているのは、外部キーの組み合わせを別のテーブルに入れ、次のような 2 つのテーブルを作成する必要があるかどうかです。

CREATE TABLE `data` (
  `id` INT UNSIGNED NULL PRIMARY KEY AUTO_INCREMENT,
  `datetime` DATETIME NOT NULL,
  `superKeys_id` INT UNSIGNED NOT NULL,
  `value` DECIMAL(10,0) NOT NULL,
  UNIQUE INDEX `datetime_superKeys_id` (`datetime`, `superKeys_id`)
)

CREATE TABLE `superKeys` (
  `id` INT UNSIGNED NULL PRIMARY KEY AUTO_INCREMENT,
  `res1` INT UNSIGNED NOT NULL,
  `res2` INT UNSIGNED NOT NULL,
  `res3` INT UNSIGNED NOT NULL,
  `res4` INT UNSIGNED NOT NULL,
  `res5` INT UNSIGNED NOT NULL,
  UNIQUE INDEX `res1_to_res5` (`res1`, `res2`, `res3`, `res4`, `res5`)
)

どこでdata。superKeys_idへの外部キーsuperKeysです。id.

これにより、テーブルのサイズが大幅に縮小されます。しかし、私が知らない理由でそれが悪い考えであるかどうかはわかりません。明らかに、選択ではデータの内訳を取得するために結合が必要になりますが、これによりオーバーヘッドが少し追加されますが、これが問題になるとは思わないでください。

私の現実の状況では、リソースの 1 つは user_id であり、ユーザーの値を頻繁に合計する必要があるため、そのような列をテーブルdataの一部にするのではなく、そのままにしておくでしょう。superKeysすべてのクエリに参加します。次に、他のリソースの値を合計する必要がある場合にのみ結合を使用しますが、これはそれほど頻繁ではありません。

4

1 に答える 1

1

データのサイズは小さくなりません。一方のテーブルに 2,000 万行のデータを格納し、もう一方のテーブルに 2,000 万行のスーパーキーを格納する必要があります。

5 つの整数は 40 バイトです。2,000 万を掛けると、800 メガバイトに datetime 列と 10 進数が加算されます。そのテーブル全体が私のネットブックの RAM に収まります。

テーブル「データ」を保持します。代理キーをドロップします。

于 2013-02-12T00:41:44.900 に答える