如果有两个类型相同但性质不同的对象，应该使用什么 table 结构？

Question

假设有两种产品 X 和 Y。X 的主键是 A、B 和 C，而 Y 的主键是 A 和 D。我应该把它们放在同一个 table 吗？为什么我应该，如果我不应该，那是为什么？

我目前将它们放在两个单独的 table 中，但一些同事建议它们属于同一个 table。我的问题是我应该考虑将它们放在相同的 table 中还是继续使用不同的 tables？

下面我给出了上述情况的例子 tables。

CREATE TABLE `product_type_b` (
    `PRODUCT_CODE` VARCHAR(50) NOT NULL,
    `COMPONENT_CODE` VARCHAR(50) NOT NULL,
    `GROUP_INDICATOR` VARCHAR(50) NULL DEFAULT NULL,
    `RECORD_TIMESTAMP` DATE NULL DEFAULT NULL,
    PRIMARY KEY (`PRODUCT_CODE`, `COMPONENT_CODE`)
)
COLLATE='utf8mb4_general_ci'
ENGINE=InnoDB
;

CREATE TABLE `product_type_a` (
    `PRODUCT_CODE` VARCHAR(50) NOT NULL,
    `CHOICE_OF_COVER` VARCHAR(50) NOT NULL,
    `PLAN_TYPE` VARCHAR(50) NOT NULL,
    `RECORD_TIMESTAMP` DATE NULL DEFAULT NULL,
    `PRODUCT_TENURE` INT(11) NULL DEFAULT NULL,
    PRIMARY KEY (`PRODUCT_CODE`, `CHOICE_OF_COVER`, `PLAN_TYPE`)
)
COLLATE='utf8mb4_general_ci'
ENGINE=InnoDB
;

如您所见，某些字段并不为两个 table 所共有，但它们是主键的一部分。还有一些其他字段对 table 来说并不常见。

这是所考虑的系统的大图。

每种产品类型从其发送到系统的地方都有不同的来源。
我们需要将这些产品存储在数据库中。
我想在规范化和性能之间取得平衡，这样我的读写速度就不会因为过度规范化而受到太大影响。
还有一个网络应用程序，其中包含一个页面，用户可以在其中搜索这些产品。
用户将填充某些列字段作为过滤器，我们需要根据这些过滤器获取产品并显示在 UI 上。
子类型的变异目前为 2，预计不会超过 4-5，这又是 go 也许我已经超过十年了。这又是一个 approximation.n 我希望这展示了系统的更大图景。

我想在不牺牲太多的情况下获得良好的读写速度。那么我应该继续这个设计吗？如果不是，应该实现什么设计？

Answer 1

这是典型的 Category/SubCategory 模型问题。有几个选项：

将所有内容放在一个 table 中，其中某些列可为 NULLable 因为不同的子类型没有相同的属性；
一个父 table 用于所有公共属性，并且还具有类型指示栏的栏目。然后每个子类型都有自己的 table 仅针对子类型具有的列。
每个子类型都有自己的table，包括所有子类型。

(1) 如果子类型非常有限则很好；
(3) suitable 如果子类型的变化非常有限。

(2)的优点。 return 所有具有共同列的记录是否容易？如果使用人工键（如 auto-increment id），它确保所有记录，不考虑子类型，都具有唯一的 id。

你的情况没有人工PK，我觉得你的选择还不错。

Answer 2

对于交易系统，考虑到最多 5 种产品类型和非常有限的属性，我更愿意为所有具有代理 PK 的产品使用一个 table。想想交易交易中对产品的引用，这是一个 long 运行中总 DB 内容的最大部分。

描述每个 product-specific 属性及其到一般 table 列的映射的元数据 table 将有助于建立 UI 和 backend/frontend 通信。

搜索索引将根据产品类型反映最流行的用户搜索。

如果有两个类型相同但性质不同的对象，应该使用什么 table 结构？

What table structure to go for if there are two objects of same type but of different nature?

sql

database-design

database-performance

mariadb

database-normalization