單個表或多個表 - 規範化

Question

我有可能是簡單的一個問題爲您解答

我有一個形象見下表

的圖像可以有多個尺寸─是更好的做法有三表格

一個表格用於圖像細節 另一個表格將image_details連接到image_paths，另一個表格連接到圖像路徑的image_sizes。

還是最好把所有的圖像大小放在圖像表中。實際上，我有一個圖像，但大小不同。尋找優化的最佳選擇。所有圖像將具有各種圖像尺寸，因此未來某些不具有特定尺寸的圖像不會有冗餘。我不確定是否最好使用其他表格，但如果我們添加其他尺寸的話。但是我可以另一列添加到圖像表爲新的圖像大小

Image_table

CREATE TABLE IF NOT EXISTS `warrington_main`.`image` ( 
    `id` MEDIUMINT(8) UNSIGNED NOT NULL AUTO_INCREMENT , 
    `user_id` BIGINT(20) UNSIGNED NOT NULL , 
    `alias_title` VARCHAR(255) NOT NULL , 
    `address_id` BIGINT(20) NULL , 
    `geolocation_id` BIGINT(20) NULL , 
    `camera_id` MEDIUMINT(8) NULL , 
    `title` VARCHAR(100) NOT NULL , 
    `description` VARCHAR(2000) NOT NULL , 
    `main_image` VARCHAR(50) NOT NULL , 
    `thumbnail_image` VARCHAR(50) NOT NULL , 
    `thumbnail_image_medium` VARCHAR(50) NOT NULL , 
    `thumbnail_image_small` VARCHAR(50) NOT NULL , 
    `thumbnail_image_gallery` VARCHAR(50) NOT NULL , 
    `hits` BIGINT(20) UNSIGNED NOT NULL DEFAULT '0' , 
    `show_comment` ENUM('0','1') NOT NULL , 
    `feature_in_gallery` ENUM('0','1') NOT NULL , 
    `created_on` DATETIME NOT NULL DEFAULT '0000-00-00 00:00:00' , 
    `date_taken` DATETIME NOT NULL DEFAULT '0000-00-00 00:00:00' , 
    `updated_on` DATETIME NOT NULL DEFAULT '0000-00-00 00:00:00' , 
    `updated_by` BIGINT(20) UNSIGNED NOT NULL , 
    `approved` ENUM('Inprocess','Yes','No') NOT NULL DEFAULT 'Inprocess' , 
    `visible` ENUM('0','1') NOT NULL DEFAULT '0' , 
    `account_type_created` ENUM('S','Y', 'G', 'FL', 'FB') NOT NULL , 
    PRIMARY KEY (`id`) , 
    UNIQUE INDEX `alias_title` (`alias_title` ASC) , 
    INDEX `title` (`title` ASC) , 
    INDEX `approved` (`approved` ASC) , 
    INDEX `visible` (`visible` ASC) , 
    INDEX `feature_in_gallery` (`feature_in_gallery` ASC) , 
    INDEX `fk_image_image_user1_idx` (`user_id` ASC) , 
    INDEX `fk_image_camera1_idx` (`camera_id` ASC) , 
    INDEX `fk_image_address1_idx` (`address_id` ASC) , 
    INDEX `fk_image_geolocation1_idx` (`geolocation_id` ASC) , 
    INDEX `fk_image_user1_idx` (`updated_by` ASC) , 
    CONSTRAINT `fk_image_image_user1` 
    FOREIGN KEY (`user_id`) 
    REFERENCES `warrington_main`.`user` (`id`) 
    ON DELETE NO ACTION 
    ON UPDATE NO ACTION, 
    CONSTRAINT `fk_image_camera1` 
    FOREIGN KEY (`camera_id`)  
    REFERENCES `warrington_main`.`camera` (`id`) 
    ON DELETE NO ACTION 
    ON UPDATE NO ACTION, 
    CONSTRAINT `fk_image_address1` 
    FOREIGN KEY (`address_id`) 
    REFERENCES `warrington_main`.`address` (`id`) 
    ON DELETE NO ACTION 
    ON UPDATE NO ACTION, 
    CONSTRAINT `fk_image_geolocation1` 
    FOREIGN KEY (`geolocation_id`) 
    REFERENCES `warrington_main`.`geolocation` (`id`) 
    ON DELETE NO ACTION 
    ON UPDATE NO ACTION, 
    CONSTRAINT `fk_image_user1`  
    FOREIGN KEY (`updated_by`)  
    REFERENCES `warrington_main`.`user` (`id`)  
    ON DELETE NO ACTION  
    ON UPDATE NO ACTION)  
ENGINE = InnoDB  
AUTO_INCREMENT = 23162  
DEFAULT CHARACTER SET = utf8 

Answer 1

一個表詳細列出了加入image_details到image_paths以及連接到圖像路徑的另一個表 - image_sizes另一個表。

這不是歸一化和要在其中一個對象的主細節存在於一個表中，並且佔用更多的空間（通常）和不一般的濾波的一部分輔助信息被稱爲Vertical Partitioning標準被移動到不同的表格。這樣做是爲了減少第一個表中每條記錄的大小，以便每個數據庫頁面中的記錄數量更多，因此過濾期間的頁面數量更少，IO更少，搜索能力更快。

就你而言，在單個表中保留圖像的所有屬性似乎很好。

Answer 2

那麼你應該去哪裏你使用多個表，就在更多的相同信息存儲正常化比一個地方。此冗餘可避免任何應用程序生命週期中稍後的數據問題。

所以在你的情況下IMAGE_SIZE應該是另一個表，其中IMAGE_ID作爲外鍵定義。

IMAGE 
    ID 
    IMAGE_ATTRIBUTES 

IMAGE_SIZE 
    ID 
    IMAGE_ID 
    SIZE_ATTRIBUTES 

IMAGE_PATH 
    IMAGE_ID or IMAGE_SIZE_ID (depends) 
    PATH 

Answer 3

一個表可能是在這種情況下處理它的方式。如果所有圖像X都具有所有尺寸，並且您可能不會添加大小不同的大小。

這三張表格的工作原理也是一樣，但是當你沒有真正獲利時，爲什麼要處理這些連接。圖像

Images 
    ImageDetailsId (PK) 
    ImageSizeId (PK) 
    URL 
    ... 

Image_Details 
    ImageDetailsId 
    ... 

Image_Sizes (where this table is relatively static - small, medium, large..) 
    ImageSizeID 
    ... (width? height? etc?)