这是使用主键和外键将父表和子表与逻辑数据而不是父表链接的正确方法吗

Question

我有两个表，一个是 product，它是一个带有一个主键的父表，我有另一个产品的子表，它是一个 product_details 表。但是子表使用逻辑数据而不是外键与父表（产品）链接，因为我们在编码端的java代码的帮助下建立这种关系，而不是依赖于数据库，这使得它变得紧密夫妇。为了避免表之间的紧密耦合，我们将主键值存储在子表中。

请参考这张图片，其中包含在产品和产品详细信息表之间创建逻辑关系的数据。

脚本是：

CREATE TABLE `tbl_product` (
  `product_id` varchar(200) NOT NULL,
  `product_details_id` varchar(200) DEFAULT NULL,
  `currency` varchar(20) DEFAULT NULL,
  `lead_time` varchar(20) DEFAULT NULL,
  `brand_id` varchar(20) DEFAULT NULL,
  `manufacturer_id` varchar(150) DEFAULT NULL,
  `category_id` varchar(200) DEFAULT NULL,
  `units` varchar(20) DEFAULT NULL,
  `transit_time` varchar(20) DEFAULT NULL,
  `delivery_terms` varchar(20) DEFAULT NULL,
  `payment_terms` varchar(20) DEFAULT NULL,
  PRIMARY KEY (`product_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;



 CREATE TABLE `tbl_product_details` (
  `product_details_id` varchar(200) NOT NULL,
  `product_id` varchar(200) DEFAULT NULL,
  `product_name` varchar(50) DEFAULT NULL,
  `landingPageImage` varchar(100) DEFAULT NULL,
  `product_description_brief` text CHARACTER SET latin1,
  `product_description_short` text CHARACTER SET latin1,
  `product_price_range` varchar(50) DEFAULT NULL,
  `product_discount_price` varchar(20) DEFAULT NULL,
  `production_Type` varchar(20) DEFAULT NULL,
  PRIMARY KEY (`product_details_id`),
  UNIQUE KEY `product_id` (`product_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

请给我建议，我们公司正在遵循这种关系，因为经理说这会给我们带来灵活性。请建议我设计的优缺点。我知道如果我们丢失表中的数据，我们将无法知道两个表之间的关系。

Answer 1

如果您想在数据库设计中使用关系原则，那当然不是。在关系设计中，概念模型中业务领域中的每个实体类型都由逻辑模型中的 R-Table 表示。R-Table 是一个表，当遵循特定学科时，可以获得数学关系的属性，这使得 R-Table 能够以代数方式使用任意复杂的逻辑语句进行操作，并保证结果。概念级别的实体类型共享一组称为属性的属性，用于描述它们。这些属性中的一个或多个被定义为唯一标识类的每个实体，以便将它们区分开来。这些在逻辑级别作为列映射到 R 表，每个实体映射到一行。然后每一行代表一个谓词，

概念级别的一个关键组成部分是业务规则，它准确定义了哪些属性值构成了真正的命题。这些映射到逻辑模型中的约束，这是关系模型提供的一个关键好处。创建时，约束使只能操作符号的 DBMS 能够有效地使输入的数据与数据要表示的真实世界的真相保持一致。

因此，简而言之，如果您不向 DBMS 声明约束条件（例如产品价格必须是一种且仅一种产品），则 DBMS 将无法确保数据与现实世界一致。所有的赌注都是关于正确的查询结果。

然而，关系设计并不容易。它需要对要建模的业务领域进行详细分析，充分理解定义一致数据的业务规则，并仔细映射到 R-Tables 的逻辑级别。我们在实践中经常看到的是我所说的基于文件的设计，其中 SQL DBMS 中的表用于表示其内容完全基于临时设计考虑的文件。有问题的 2 个表 - 产品和产品详细信息 - 是使用基于文件的设计设计的线索是在产品详细信息表的名称中。一个文件保存的东西的细节。一个产品详细信息不是实体类共享公共属性的实体类型。该表中的每一列都被定义为NULL这一事实也证明了这一点。

如果您想要基于文件的设计的优点和缺点，我不是详细说明的合适人选，因为这些优点和缺点将是临时的，完全基于您的具体情况 - 例如技术和工作负载。

可以在 Fabian Pascal 的实用数据库基础系列中找到有关关系设计及其强大功能的优秀入门读物。Fabian 以通俗易懂的语言为日常从业者提供了基础知识。他涵盖了我在这里总结的所有内容，并提供了清晰的解释以及更多内容。我强烈推荐它。