爲許多屬性存儲歷史數據時，聯結表是否正確？

我正在設計一個存儲與網站相關的SEO指標的網絡應用程序。有大約50個與每個網站有關的指標每天計算和存儲。我需要能夠隨着時間的推移跟蹤這些指標中的每一個的變化。我根據我對標準化的理解設計了以下模式。這似乎是聯結表（tbl_website_metric）會非常快速地增長非常大。我想知道這是否是最佳模式，或者是否有任何設計錯誤。爲許多屬性存儲歷史數據時，聯結表是否正確？

CREATE TABLE `tbl_website` (
    `id` INT NOT NULL AUTO_INCREMENT , 
    `name` VARCHAR(100) NOT NULL , 
    `domain` VARCHAR(100) NULL , 
    `url` VARCHAR(100) NULL , 
    PRIMARY KEY (`id`)) 
ENGINE = InnoDB; 

CREATE `tbl_metric` (
    `id` INT NOT NULL AUTO_INCREMENT , 
    `name` VARCHAR(45) NOT NULL , 
    `description` VARCHAR(100) NULL , 
    PRIMARY KEY (`id`)) 
ENGINE = InnoDB; 

CREATE `tbl_website_metric` (
    `id` INT NOT NULL AUTO_INCREMENT , 
    `metric_id` INT NOT NULL , 
    `website_id` INT NOT NULL , 
    `created` TIMESTAMP NULL , 
    `value` VARCHAR(45) NULL , 
    PRIMARY KEY (`id`) , 
    CONSTRAINT `fk_tbl_website_metric_tbl_metric1` 
    FOREIGN KEY (`metric_id`) 
    REFERENCES `tbl_metric` (`id`) 
    CONSTRAINT `fk_tbl_website_metric_tbl_website1` 
    FOREIGN KEY (`website_id`) 
    REFERENCES `tbl_website` (`id`)) 
ENGINE = InnoDB;

來源

2011-07-06 Michelle

您的數據庫設計似乎很好的場景;幾個建議，但：

我不知道你的應用程序有多少網站存儲的統計信息，但如果不是幾十萬以上，考慮改變tbl_website。 id至SMALLINT UNSIGNED。這將允許您存儲65535個網站
同樣，由於您有大約50個指標，因此更改tbl_metric是有意義的。 id至TINYINT UNSIGNED。這將允許您存儲255個度量標準
我認爲FK會自動在各個列上創建索引，但如果沒有，請考慮爲tbl_website_metric創建索引。 metric_id和tbl_website_metric。 website_id

請注意，1和2，您還需要相應地更改數據類型爲tbl_website_metric。 metric_id和tbl_website_metric。 website_id。

我不確定聯結表可能增長多少，但MySQL能夠處理大型表。無論如何，考慮清除tbl_website_metric中已過時的條目或者將它們歸檔到另一個表格是一種很好的方法。

我想推薦一種替代方法。如果1）您的指標非常不穩定，因爲指標並不經常被添加或刪除，2）所有網站的指標都是相同的，您不妨考慮將指標存儲在列中：

CREATE TABLE `tbl_website_metric` (
    `id` INT NOT NULL AUTO_INCREMENT, 
    `website_id` INT NOT NULL, 
    `created` TIMESTAMP NULL, 
    `metric_1` VARCHAR(45) NULL, 
    `metric_2` VARCHAR(45) NULL, 
    `metric_3` VARCHAR(45) NULL, 
    `metric_4` VARCHAR(45) NULL, 
    ... 
    ... 
    `metric_50` VARCHAR(45) NULL 
);

這意味着每個網站只有一個插入和單個選擇。 Plus會將表中的記錄數減少N次，其中N =度量標準數。

希望它有幫助。

來源

2011-07-06 12:14:13 Abhay

這是非常有益的感謝。您的替代解決方案無法正常工作，因爲度量標準是獨立更新的，因此需要有與每個標準相關聯的時間戳。你同意嗎？ – Michelle

@Michell：好的！如果要求確實是爲每個指標網站對保留單獨的時間戳，則替代方法不起作用。我認爲在網站上次記錄指標時保留時間戳可能沒問題 – Abhay

看起來不錯。

身份證號碼的索引應該保持您的表現健康。

來源

2011-07-06 11:40:26 Randy

一般沒問題......一些小問題，主要是關於列類型：

沒有理由爲tbl_website_metric IMO明確的主鍵。上（metric_id, website_id, created）唯一索引應該足夠
tbl_website_metric.created應該是一個DATE（節省1個字節，是必要的索引的唯一性）
value必須是文字？
你聲明瞭外鍵約束metric_id和website_id;而這當然有一定的優勢，這也意味着鎖定問題，比照http://www.mysqlperformanceblog.com/2006/12/12/innodb-locking-and-foreign-keys/

心連心

來源

2011-07-06 11:59:11 wonk0

爲許多屬性存儲歷史數據時，聯結表是否正確？

回答

相關問題