我需要将其他数据放入数据库中，并且可以在修改现有表(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)中，将数据分割后，根本就不需要联接它们。如果我知道我需要XX_1的字段，我将转到该表。
我试图了解是否有一个具有许多未使用值的大型表与将相同的数据拆分成更多表的关系是否有利弊。大量表是否会导致数据库性能下降(我们已经有约80个表)？
最佳答案
从速度的角度来看，最佳的数据库结构是什么？
好吧，正确，最佳实践等被称为标准化。如果正确执行此操作，将没有可选列(没有字段)，没有Null。可选列将在单独的表中，行数更少。当然，您可以对表进行排列，使它们成为可选列的集合，而不是每列(一个PK加)。
将子表中的行合并为一个5NF行是很容易的，在一个 View 中做到这一点(但不通过 View 进行更新，而是通过事务存储过程直接对每个子表进行更新)。
更多，更小的表是Normalized Relational数据库的性质。习惯它。由于缺少归一化，重复和空值，较大的表较少，速度较慢。在SQL
碰巧是最佳的重新性能，不足为奇。有两个原因:
具有许多可选(空)列的大型表没有优点，只有缺点。从来没有违反标准的专家。
无论您打算使用4个表还是400个新表，答案都不会改变。
关于database - 最佳数据库结构-带有空字段或更多表的 'wider'表？，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/4286698/