gpt4 book ai didi

database - 最佳数据库结构 - 'wider' 表具有空字段或更多表?

转载 作者:太空狗 更新时间:2023-10-30 01:42:40 24 4
gpt4 key购买 nike

我需要将额外的数据放入数据库,我可以选择修改现有表 (table_existing) 或创建新表。

这是 table_existing 现在的样子:

table_existing
-------------------------
| ID | SP | SV | Field1 |
| .. | WW | 1 | ...... |
| .. | WW | 1 | ...... |
-------------------------

选项(A)

table_existing
----------------------------------------------------------------------
| ID | SP | SV | Field1 | Field2 | Field3 | Field4 | Field5 | Field6 |
| .. | XX | 1 | ...... | ...... | ...... | ...... | ...... | ...... |
| .. | YY | 2 | ...... | ...... | ...... | ...... | ...... | ...... |
----------------------------------------------------------------------

选项(B)

table_existing would be converted into table_WW_1_data
---------------
| ID | Field1 |
| .. | ...... |
| .. | ...... |
---------------

table_XX_1_data
------------------------
| ID | Field1 | Field2 |
| .. | ...... | ...... |
| .. | ...... | ...... |
------------------------

table_YY_2_data
---------------------------------
| ID | Field1 | Field2 | Field3 |
| .. | ...... | ...... | ...... |
| .. | ...... | ...... | ...... |
---------------------------------

上下文:SP、SV 的组合决定了将填充的字段的“数量”。例如,(XX, 1) 有 2 个字段。 (YY, 2) 有 3 个字段。

如果我选择选项 (A),我会在“更宽”的表中有许多空值/NULL 值。

如果我选择选项 (B),我基本上是在创建更多的表……一个用于 SP、SV 的“每个”组合 - 总共可能有 4-5 个。但是每个都将完全填充正确数量的字段。 table_existing 也会更改。

从速度的角度来看,更优的数据库结构是什么?我认为,从可维护性的角度来看,方案(B)可能更好。


编辑1

这两个选项都不是我的应用程序中最关键/最常用的表。

在选项(B)中,数据被拆分后,根本不需要 JOINing 它们。如果我知道我需要 XX_1 的字段,我将转到该表。

我试图了解拥有一个包含许多未使用值的大表与将相同数据拆分到更多表之间是否有利弊。大量的表是否会导致数据库性能下降(我们已经有大约 80 个表)?

最佳答案

从速度的角度来看,更优化的数据库结构是什么?

嗯,什么是正确的,最佳实践等,被称为规范化。如果你这样做正确,将没有可选列(不是字段),没有空值。可选列将位于单独的表中,行数较少。当然,您可以安排表格,使它们成为一组可选列,而不是(一个 PK 加)每个列。

将子表中的行组合成一个 5NF 行很容易,在 View 中执行此操作(但不要通过 View 更新,通过事务存储过程直接对每个子表执行此操作)。

更多、更小的表是规范化关系数据库的本质。习惯它。由于缺乏规范化、重复和空值,更少、更大的表更慢。在 SQL< 中加入很麻烦,但这就是我们所拥有的。联接本身没有成本,只有被联接的表(行、行宽、联接列、数据类型、不匹配、索引[或不])。数据库针对规范化表进行了优化,而不是针对数据堆。以及大量的表格。

这恰好是最佳性能,不足为奇。有两个原因:

  1. 表格更窄,因此每页有更多行,每个物理 I/O 获得更多行,同一缓存空间中有更多行。

  2. 由于您没有空值,因此这些列的长度是固定的,无需解包以提取列的内容。

具有许多可选(空)列的大型表没有优点,只有缺点。从来没有违反标准的专业人士。

无论您是考虑 4 张还是 400 张新 table ,答案都不会改变。

  • 如果您正在认真考虑那么多表格,有一个建议:您正在朝着第六范式的方向前进,但没有意识到这一点。所以意识到这一点,并正式地这样做。 400 张 table 将得到更好的控制。如果您请专业人士来做,他们会将其标准化,并最终回到低于 100。

关于database - 最佳数据库结构 - 'wider' 表具有空字段或更多表?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/4286698/

24 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com