2

複数のソースから収集している統計の「拡張」テーブル構造を実装しようとしています。

私の「親」テーブルは次のようになります。

`test_parent` (
  `id` int(11) unsigned NOT NULL AUTO_INCREMENT,
  `date` date NOT NULL,
  `actions` int(11) unsigned NOT NULL,
  PRIMARY KEY (`id`)
)

私の最初の「子」テーブルは次のようになります (最終的には、ソースごとに子テーブルが作成されます)。

`test_child` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `test_parent_id` int(11) unsigned NOT NULL,
  `external_id` int(11) NOT NULL,
  `external_actions` int(11) NOT NULL,
  PRIMARY KEY (`id`),
  KEY `test_parent_id` (`test_parent_id`)
)
CONSTRAINT `test_child_ibfk_1` FOREIGN KEY (`test_parent_id`) REFERENCES `test_parent` (`id`)

これはすべて、私の実装では正常に機能します (Java/Hibernate を使用します)。ただし、最初の子テーブルには、external_id と date の複合一意キーが必要です。テーブル全体で複合一意キーを使用できないことはわかっています。収集している実際の分析はソースによって大きく異なる可能性があるため、すべての統計を格納する 1 つのテーブルを使用したくありません。「親」テーブルを取り除くことにもっとオープンになります。

この問題を見ることができる他の方法はありますか？可能であれば、トリガーを使用して一意性を強制することは避けたいと考えています。

4

2 に答える 2

3

dateで一意の制約を確立する場合は、子テーブルに が必要ですexternal_id。親テーブルにライブを持ち、外部キーを介して参照することもできます。これにより、将来、他の子テーブルで別の方法dateでサポートできるようになります。date

CREATE TABLE `test_parent` (
  `id` int(11) unsigned NOT NULL AUTO_INCREMENT,
  `date` date NOT NULL,
  `actions` int(11) unsigned NOT NULL,
  PRIMARY KEY (`id`, `date`)
);

CREATE TABLE `test_child` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `test_parent_id` int(11) unsigned NOT NULL,
  `date` date NOT NULL,
  `external_id` int(11) NOT NULL,
  `external_actions` int(11) NOT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `test_parent_id` (`external_id`,`date`),
  CONSTRAINT `test_child_ibfk_1` FOREIGN KEY (`test_parent_id`, `date`) 
    REFERENCES `test_parent` (`id`,`date`)
);
于 2011-10-20T14:11:51.480 に答える
-1

フィールドを子テーブルに移動dateし、一意のキーを宣言します。

ALTER TABLE child ADD UNIQUE INDEX parent_date (parent_id, `date`);
于 2011-10-20T14:05:09.627 に答える