Warning: file_get_contents(/data/phpspider/zhask/data//catemap/7/sqlite/3.json): failed to open stream: No such file or directory in /data/phpspider/zhask/libs/function.php on line 167

Warning: Invalid argument supplied for foreach() in /data/phpspider/zhask/libs/tag.function.php on line 1116

Notice: Undefined index: in /data/phpspider/zhask/libs/function.php on line 180

Warning: array_chunk() expects parameter 1 to be array, null given in /data/phpspider/zhask/libs/function.php on line 181
Sql 如果有两个类型相同但性质不同的对象,那么使用哪种表结构?_Sql_Database Design_Mariadb_Database Performance_Database Normalization - Fatal编程技术网

Sql 如果有两个类型相同但性质不同的对象,那么使用哪种表结构?

Sql 如果有两个类型相同但性质不同的对象,那么使用哪种表结构?,sql,database-design,mariadb,database-performance,database-normalization,Sql,Database Design,Mariadb,Database Performance,Database Normalization,假设有两种产品X和Y。X的主键是A、B和C,而Y的主键是A和D。我应该把它们放在同一张桌子上吗?为什么我应该,如果我不应该,那为什么 我目前将它们放在两个单独的表格中,但一些同事建议它们属于同一个表格。我的问题是我应该考虑把它们放在同一张桌子上还是继续用不同的表格? 下面我给出了上述情况的示例表 CREATE TABLE `product_type_b` ( `PRODUCT_CODE` VARCHAR(50) NOT NULL, `COMPONENT_CODE` VARCHAR

假设有两种产品X和Y。X的主键是A、B和C,而Y的主键是A和D。我应该把它们放在同一张桌子上吗?为什么我应该,如果我不应该,那为什么

我目前将它们放在两个单独的表格中,但一些同事建议它们属于同一个表格。我的问题是我应该考虑把它们放在同一张桌子上还是继续用不同的表格?

下面我给出了上述情况的示例表

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
;
正如您所看到的,某些字段不是两个表所共有的,而是主键的一部分。还有一些其他字段不是这两个表所共有的

以下是考虑中的系统的整体情况

  • 每种产品类型都有一个不同的来源,从那里发送到系统
  • 我们需要将这些产品存储在数据库中
  • 我希望在规范化和性能之间取得平衡,这样我的读写速度就不会因为过度规范化而受到很大影响
  • 还有一个web应用程序,它将有一个页面,用户可以在其中搜索这些产品
  • 用户将填充某些列字段作为过滤器,我们需要根据这些字段获取产品并在UI上显示
  • 目前,亚型的变异为2,预计不会超过4-5,这同样是不可能的 ig可能会超过十年。这又是一个近似值 我希望这能更全面地描述这个系统

我希望有良好的读写速度,而不牺牲太多。那么我应该继续这个设计吗?如果没有,应该实施什么设计?

这是典型的类别/子类别模型问题。有几种选择:

  • 将所有内容放在一个表中,其中有些列可以为空 因为不同的子类型没有相同的属性

  • 所有公共属性的一个父表,以及 类型指示列的列。然后每个子类型都有自己的 表仅用于子类型所具有的列

  • 每个子类型都有自己的表,包括 所有子类型

  • (1) 如果子类型非常有限,则为良好
    (3) 适用于子类型变化非常有限的情况

    (2)的优点。返回具有公共列的所有记录是否容易。如果使用人工键(如自动递增id),则确保所有记录(不考虑子类型)具有唯一id


    在您的情况下,没有使用人工PK,我认为您的选择不错。

    这是典型的类别/子类别模型问题。有几种选择:

  • 将所有内容放在一个表中,其中有些列可以为空 因为不同的子类型没有相同的属性

  • 所有公共属性的一个父表,以及 类型指示列的列。然后每个子类型都有自己的 表仅用于子类型所具有的列

  • 每个子类型都有自己的表,包括 所有子类型

  • (1) 如果子类型非常有限,则为良好
    (3) 适用于子类型变化非常有限的情况

    (2)的优点。返回具有公共列的所有记录是否容易。如果使用人工键(如自动递增id),则确保所有记录(不考虑子类型)具有唯一id


    在您的情况下,没有使用人工PK,我认为您的选择不错。

    对于交易系统,考虑到最多5种产品类型和非常有限的属性数量,我希望所有产品都有一个单独的表,带有代理PK。想想对交易交易产品的引用,从长远来看,这是数据库总内容的最大部分

    描述每个产品特定属性及其到general table列的映射的元数据表将有助于构建UI和后端/前端通信


    搜索索引将根据产品类型反映最受欢迎的用户列表。

    对于交易系统,考虑到最多5种产品类型和数量非常有限的属性,我希望所有产品都有一个单独的表,带有代理PK。想想对交易交易产品的引用,从长远来看,这是数据库总内容的最大部分

    描述每个产品特定属性及其到general table列的映射的元数据表将有助于构建UI和后端/前端通信


    搜索索引将根据产品类型反映最受欢迎的用户列表。

    问题better suites dba.stackexchange.com可能重复。无论如何,对所讨论的系统有一个更大的了解将有助于评估选项的利弊。@Serg用更大的了解更新了文章。请通过编辑澄清,而不是评论。请在新帖子中提出新问题。每个帖子问一个问题。请不要插入编辑/更新,只是让您的文章成为目前为止最好的演示文稿。PS您没有给我们提供任何信息来解决2NF,因此这并不反映我们对2NF的理解。问一个问题,看看你的课本。但这种子类型/继承的重新排列无论如何都不是规范化的。同样,您的问题并没有反映出对规范化的理解。抱歉,正如前面所说的,我不确定我提到2NF的部分。我将编辑这篇文章,以便只问“一个问题”。这个问题可能重复,请访问dba.stackexchange.com。无论如何,对所讨论的系统有一个更大的了解将有助于评估选项的利弊。@Serg用更大的了解更新了文章。请通过编辑澄清,而不是评论。请用新的语言提出新的问题
    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
    ;