数据库设计和连接表关系的可选性

发布于 2024-12-09 19:12:58 字数 2019 浏览 0 评论 0原文

我正在设计一个数据库模型,我想到了一个问题:指定关系的连接表端是否是可选的有什么意义,因为它对生成的 DDL 没有影响?

例如下面两个不同的图:

A_to_B_join 侧 A 和 A_to_B_join 之间具有强制关系的图: mandatory

A_to_B_join 侧 A 和 A_to_B_join 之间的可选关系图:

optional

我注意到它们都严格生成相同的 DDL,即使它们不同!

生成的 DDL:

SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS=0;
SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0;
SET @OLD_SQL_MODE=@@SQL_MODE, SQL_MODE='TRADITIONAL';

CREATE SCHEMA IF NOT EXISTS `mydb` DEFAULT CHARACTER SET latin1 COLLATE latin1_swedish_ci ;
USE `mydb` ;

-- -----------------------------------------------------
-- Table `mydb`.`A`
-- -----------------------------------------------------
CREATE  TABLE IF NOT EXISTS `mydb`.`A` (
  `A_ID` INT NOT NULL ,
  PRIMARY KEY (`A_ID`) )
ENGINE = InnoDB;


-- -----------------------------------------------------
-- Table `mydb`.`B`
-- -----------------------------------------------------
CREATE  TABLE IF NOT EXISTS `mydb`.`B` (
  `B_ID` INT NOT NULL ,
  PRIMARY KEY (`B_ID`) )
ENGINE = InnoDB;


-- -----------------------------------------------------
-- Table `mydb`.`A_to_B_join`
-- -----------------------------------------------------
CREATE  TABLE IF NOT EXISTS `mydb`.`A_to_B_join` (
  `A_ID` INT NOT NULL ,
  `B_ID` INT NOT NULL ,
  PRIMARY KEY (`A_ID`, `B_ID`) ,
  INDEX `fk_A_to_B_join_B1` (`B_ID` ASC) ,
  INDEX `fk_A_to_B_join_A` (`A_ID` ASC) ,
  CONSTRAINT `fk_A_to_B_join_A`
    FOREIGN KEY (`A_ID` )
    REFERENCES `mydb`.`A` (`A_ID` )
    ON DELETE NO ACTION
    ON UPDATE NO ACTION,
  CONSTRAINT `fk_A_to_B_join_B1`
    FOREIGN KEY (`B_ID` )
    REFERENCES `mydb`.`B` (`B_ID` )
    ON DELETE NO ACTION
    ON UPDATE NO ACTION)
ENGINE = InnoDB;



SET SQL_MODE=@OLD_SQL_MODE;
SET FOREIGN_KEY_CHECKS=@OLD_FOREIGN_KEY_CHECKS;
SET UNIQUE_CHECKS=@OLD_UNIQUE_CHECKS;

那么提及该边是可选的还是强制的有什么意义呢?我应该打扰吗? DDL 与 MySQL 相同吗?

问候,

I am designing a database model and a question occurred to me: what's the point of specifying whether the join-table side of a relationship is optional bearing in mind it has no effect on the generated DDL?

For instance take the two different diagrams below:

Diagram with mandatory relationship between A and A_to_B_join on the A_to_B_join side:
mandatory

Diagram with optional relationship between A and A_to_B_join on the A_to_B_join side:

optional

I noticed they both stictly generate the same DDL even though they are different!

Generated DDL:

SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS=0;
SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0;
SET @OLD_SQL_MODE=@@SQL_MODE, SQL_MODE='TRADITIONAL';

CREATE SCHEMA IF NOT EXISTS `mydb` DEFAULT CHARACTER SET latin1 COLLATE latin1_swedish_ci ;
USE `mydb` ;

-- -----------------------------------------------------
-- Table `mydb`.`A`
-- -----------------------------------------------------
CREATE  TABLE IF NOT EXISTS `mydb`.`A` (
  `A_ID` INT NOT NULL ,
  PRIMARY KEY (`A_ID`) )
ENGINE = InnoDB;


-- -----------------------------------------------------
-- Table `mydb`.`B`
-- -----------------------------------------------------
CREATE  TABLE IF NOT EXISTS `mydb`.`B` (
  `B_ID` INT NOT NULL ,
  PRIMARY KEY (`B_ID`) )
ENGINE = InnoDB;


-- -----------------------------------------------------
-- Table `mydb`.`A_to_B_join`
-- -----------------------------------------------------
CREATE  TABLE IF NOT EXISTS `mydb`.`A_to_B_join` (
  `A_ID` INT NOT NULL ,
  `B_ID` INT NOT NULL ,
  PRIMARY KEY (`A_ID`, `B_ID`) ,
  INDEX `fk_A_to_B_join_B1` (`B_ID` ASC) ,
  INDEX `fk_A_to_B_join_A` (`A_ID` ASC) ,
  CONSTRAINT `fk_A_to_B_join_A`
    FOREIGN KEY (`A_ID` )
    REFERENCES `mydb`.`A` (`A_ID` )
    ON DELETE NO ACTION
    ON UPDATE NO ACTION,
  CONSTRAINT `fk_A_to_B_join_B1`
    FOREIGN KEY (`B_ID` )
    REFERENCES `mydb`.`B` (`B_ID` )
    ON DELETE NO ACTION
    ON UPDATE NO ACTION)
ENGINE = InnoDB;



SET SQL_MODE=@OLD_SQL_MODE;
SET FOREIGN_KEY_CHECKS=@OLD_FOREIGN_KEY_CHECKS;
SET UNIQUE_CHECKS=@OLD_UNIQUE_CHECKS;

What's the point then of mentioning whether the side is optional or mandatory? Should I bother? Is the fact that the DDL is the same specific to MySQL?

Regards,

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

万人眼中万个我 2024-12-16 19:12:58

它很可能是 MySQL 特定的。

某些其他产品(Oracle?Postgres?...)可能会生成略有不同的 DDL,查询优化器可以使用差异来决定如何转换包含 Join 的查询。

It could very well be MySQL-specific.

Some other product (Oracle? Postgres? ...) could generate slightly different DDLs, and the difference could be used by the query optimizer to decide how to translate queries that include the Join.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文