Mysql 单表或多表-标准化_Mysql_Database Design

Mysql 单表或多表-标准化

mysql database-design

Mysql 单表或多表-标准化,mysql,database-design,Mysql,Database Design,我有一个问题可能很简单，你可以回答我在下面有一张图片表一幅图像可以有多种尺寸——有三张桌子更好吗一个用于图像详细信息的表另一个表将图像\详细信息连接到图像\路径，另一个表-图像\大小连接到图像路径或者最好将所有图像大小都放在图像表中。实际上，我有一个图像，但大小不同。寻找优化的最佳选择。所有图像将具有每个图像大小，因此对于某些没有特定大小的图像，将来不会有冗余。我不确定是否最好使用另一张桌子，以防我们增加其他尺寸。但是，我可以为图像表添加另一列以获得新的图像大小图像_表 CREATE

我有一个问题可能很简单，你可以回答

我在下面有一张图片表

一幅图像可以有多种尺寸——有三张桌子更好吗

一个用于图像详细信息的表另一个表将图像\详细信息连接到图像\路径，另一个表-图像\大小连接到图像路径

或者最好将所有图像大小都放在图像表中。实际上，我有一个图像，但大小不同。寻找优化的最佳选择。所有图像将具有每个图像大小，因此对于某些没有特定大小的图像，将来不会有冗余。我不确定是否最好使用另一张桌子，以防我们增加其他尺寸。但是，我可以为图像表添加另一列以获得新的图像大小

图像_表

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

您应该进行规范化，使用多个表，而不是在多个位置存储相同的信息。这种冗余避免了以后任何应用程序生命周期中出现的大量数据问题

因此，在您的情况下，

IMAGE\u SIZE

应该是另一个表，其

IMAGE\u ID

定义为外键

IMAGE
    ID
    IMAGE_ATTRIBUTES

IMAGE_SIZE
    ID
    IMAGE_ID
    SIZE_ATTRIBUTES 

 IMAGE_PATH
    IMAGE_ID or IMAGE_SIZE_ID (depends)
    PATH

您应该进行规范化，使用多个表，而不是在多个位置存储相同的信息。这种冗余避免了以后任何应用程序生命周期中出现的大量数据问题

因此，在您的情况下，

IMAGE\u SIZE

应该是另一个表，其

IMAGE\u ID

定义为外键

IMAGE
    ID
    IMAGE_ATTRIBUTES

IMAGE_SIZE
    ID
    IMAGE_ID
    SIZE_ATTRIBUTES 

 IMAGE_PATH
    IMAGE_ID or IMAGE_SIZE_ID (depends)
    PATH

在这种情况下，一个表可能是处理它的方法。如果所有的图像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?)

在这种情况下，一个表可能是处理它的方法。如果所有的图像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?)

一个表用于图像详细信息，另一个表用于将图像详细信息连接到图像路径，另一个表用于将图像大小连接到图像路径

这不是规范化，指的是希望对象的主要详细信息显示在一个表中，而占用更多空间（通常）且不属于常规筛选条件的辅助详细信息移动到另一个表中。这样做是为了减小第一个表的每条记录的大小，以便在每个数据库页面中有更多的记录，从而在筛选过程中通过的页面数量更少，IO更少，搜索速度更快

在您的例子中，将图像的所有属性保留在一个表中似乎很好

一个表用于图像详细信息，另一个表用于将图像详细信息连接到图像路径，另一个表用于将图像大小连接到图像路径

就你而言，将图像的所有属性保留在一个表中似乎很好。

数据的重新一致性在哪里？如果大小在一个表中，那么图像数据将是冗余的，因为多行将具有相同的图像信息。可能我读错了-我读错了，因为他的单表解决方案是这样的：

ImageID | Detail1 | Detail2.. | SmallImageURL | MediumImageURL…

其中每个ImageID都会显示所有ImageURL。我看不到重复一致性。如果每个值都不同，但没有冗余-即，如果一个图像的详细信息可以属于一个图像，并且一个图像对于每个大小都是不同的路径，那么我永远不会有冗余信息。然而，我不确定是否保留在一个表中违背了标准化的第一条规则。但是，没有联接可能会加快查询速度？在这种情况下，每次都需要添加一列-这不好吗，只是想找到最好的选择数据的重新一致性在哪里？如果大小出现在一个表中，那么图像数据将是冗余的，因为多行将具有相同的图像信息。也许我读错了-我读错了，因为他的单表解决方案是这样的：

ImageID | Detail1 | Detail2SmallImageURL | MediumImageURL…

其中每个ImageID都会显示所有ImageURL。我看不到重复一致性。如果每个值都不同，但没有冗余-即，如果一个图像的详细信息可以属于一个图像，并且一个图像对于每个大小都是不同的路径，那么我永远不会有冗余信息。然而，我不确定是否保留在一个表中违背了标准化的第一条规则。但是，没有连接可能会加快查询速度？在这种情况下，每次都需要添加一列-这不是很好，只是试图找到最佳选项真的。。。在这个设计中。。。对于

Image\u Size

和

Image\u Details

的每个组合，您必须重复所有属性…Image\u Details有一个记录，对于每个图像（不同大小），您都链接到Image\u Details记录和Image\u Size（基本上是小/中/大等）。所以不，这基本上是一个表的解决方案被分成三个-我认为在这种情况下这是不必要的真的。。。在这个设计中。。。对于

Image\u Size

和

Image\u Details

的每个组合，您必须重复所有属性…Image\u Details有一个记录，对于每个图像（不同大小），您都链接到Image\u Details记录和Image\u Size（基本上是小/中/大等）。所以不，这是基本的