단일 테이블 또는 여러 테이블 - 정상화

Question

나는 간단 할 수있는 질문이 있습니다 테이블

이미지 세부 사항을위한 하나의 테이블 image_details와 image_paths를 조인하는 다른 테이블과 이미지 경로에 조인하는 다른 테이블 이미지 크기.

또는 모든 이미지 크기를 이미지 테이블에 넣는 것이 가장 좋습니다. 실제로는 하나의 이미지가 있지만 크기가 다릅니다. 최적화를위한 최상의 옵션을 찾고 있습니다. 모든 이미지에는 각 이미지 크기가 있으므로 특정 크기가 아닌 일부 이미지의 경우 중복성이 없습니다. 다른 크기를 추가 할 경우 다른 테이블을 사용하는 것이 가장 좋았는지 확실하지 않았습니다. 그러나 나는

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_paths 및 이미지 경로에 조인 다른 테이블 - image_sizes에 image_details을 조인 다른 테이블에 대해 자세히 설명합니다.

이 정규화되지 않고, 만약 객체의 기본 세부 한 테이블에 더 많은 공간을 차지할 (일반)과 일반적인 필터링에 포함되지 않은 보조 세부 본 할 위치 Vertical Partitioning이라 조건이 다른 테이블로 이동되었습니다. 이것은 첫 번째 테이블의 각 레코드 크기를 줄이기 위해 각 데이터베이스 페이지에 더 많은 레코드가 있으므로 필터링 중에 걸리는 페이지 수가 적고 입출력이 적으며 검색 속도가 빠릅니다.

경우에 따라 이미지의 모든 속성을 단일 테이블에 유지하는 것이 좋습니다.

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?)