最佳数据库结构 - 具有空字段或更多表的“更宽”表？

我需要将其他数据放入数据库中，我可以选择修改现有表（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）可能会更好。 EDIT1 这两个选项都不是我应用程序中最关键/最常用的表。 在选项（B）中，在分割数据之后，根本不需要加入它们。如果我知道我需要XX_1的字段，我会去那张桌子。 我试图了解是否有一个包含许多未使用值的大型表与在更多表中分配相同数据的优缺点。大量的表是否导致数据库中的性能损失（我们已经有~80个表）？     
2019-08-03 6 条评论
分享

没有找到相关结果

    已邀请:

    痰降锭骂奸

    从速度的角度来看，更优化的数据库结构是什么？ 什么是正确的，最佳实践等，称为规范化。如果你这样做，将没有可选列（不是字段），没有Null。可选列将位于单独的表中，行数较少。当然，您可以安排表格，使它们成为可选列的集合，而不是（一个PK +）每列一列。 将子表中的行组合成一个5NF行很容易，我可以查看（但不要通过视图更新，通过事务存储过程直接对每个子表执行此操作）。 更多，更小的表是规范化关系数据库的本质。习惯它。由于缺乏规范化，重复和无效，更少，更大的表更慢。在SQL中加入很麻烦＆lt;但这就是我们所拥有的一切。连接本身没有成本，只有连接的表（行，行宽，连接列，数据类型，不匹配，索引[或不]）。数据库针对规范化表进行了优化，而不是针对数据堆。和大量的表。 这恰好是最佳表现，毫不奇怪。有两个原因： 表格较窄，因此每页有更多行，每个物理I / O可获得更多行，同一缓存空间中有更多行。 由于你有No Nulls，那些列是固定的len，没有解压缩来提取列的内容。 对于具有许多可选（空）列的大型表，没有优点，只有缺点。从来没有一个专业人士违反标准。 无论您是考虑4或400个新表，答案都是不变的。 如果您正在认真考虑许多表格，那么一个建议是：您正朝着第六范式的方向前进，却没有意识到这一点。所以要实现它，并正式这样做。 400表将更好地控制。如果你有专业人士去做，他们会将其标准化，并最终回到不到100。     
    2019-08-03 0 0
    分享

    篮肥炼皖

    我是SQL服务器DBA所以我会建议我在SQL Server 2008中做什么。 将列添加到现有表中为nullable，将列标记为SPARSE。使用稀疏标记不会增加现有表页中额外列的存储空间，并且仍允许您将稀疏列作为列进行查询。 SQL Server在内部以XML格式存储稀疏列，也可以查询或显示它们。 如果有遗留应用程序无法处理新的表结构 重命名表 使用原始表结构创建视图，并将其命名为原始表名 如果您的版本不支持稀疏列，则为现有表构建一个子表，将子表与父表的ID链接到父表。在两个表中创建一个视图以显示数据。     
    2019-08-03 0 0
    分享

    田眯衅

    您的查询是否更可能需要将（XX，1）设置的行与（YY，2）设置等组合起来......？ 如果没有，那么拆分成单独的表会更快，因为用于所有查询的各个表更窄。 如果你将它们组合在一起，它们可能会稍微慢一些，因为你需要UNIONs，这需要对主表进行重复查询。     
    2019-08-03 0 0
    分享

    拟蓬

    我同意DVK的说法，如果你选择（B），你最终将不得不查询几个表来获得所有原始的Field1值，更不用说JOINs等的复杂性了。除非分成单独的表，否则这是没有意义的对应于分离成不同的实体。 我同意Paul的观点，如果不了解所涉及实体的详细信息以及您将要运行的各种查询和更新，您的问题就无法得到真正的回答。     
    2019-08-03 0 0
    分享

    坊岔埠绵

    我记得以前有过这些疑惑。 从数据验证的角度来看，选项（B）更有利。您可以更好地对字段设置约束。这就是为什么你想要将一个
    users
    表拆分为
    students
    ，
    teachers
    等来强制执行NOT NULL约束的原因，具体取决于用户的角色。 通常，由于索引问题，在表中包含大量NULL值会对性能造成影响。 根据经验，只要联接中涉及的表数量为4或更少，您就不必担心性能损失。 编辑：如果你担心数据库中的表数，我建议你看看这里。     
    2019-08-03 0 0
    分享
    为什么被折叠? 0 个回复被折叠

    要回复问题请先登录或注册

    或代码 OrCode.com 备案号：粤ICP备15020848号-1
    Escape time: 0.046546936035156