这就是table_existing现在的样子：
table_existing ------------------------- | ID | SP | SV | Field1 | | .. | WW | 1 | ...... | | .. | WW | 1 | ...... | -------------------------@H_301_5@选项(A)
table_existing ---------------------------------------------------------------------- | ID | SP | SV | Field1 | Field2 | Field3 | Field4 | Field5 | Field6 | | .. | XX | 1 | ...... | ...... | ...... | ...... | ...... | ...... | | .. | YY | 2 | ...... | ...... | ...... | ...... | ...... | ...... | ----------------------------------------------------------------------@H_301_5@选项(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 | | .. | ...... | ...... | ...... | | .. | ...... | ...... | ...... | ---------------------------------@H_301_5@上下文：SP,SV的组合确定要填充的字段的“数量”.例如,(XX,1)有2个字段. (YY,2)有3个字段.
如果我要使用Option(A),我将在“更宽”的表中有很多空/ NULL值.
如果我使用Option(B),我基本上创建了更多的表…一个用于SP,SV的“每个”组合 – 总共可能有4-5个.但每个都将被完全填充正确的字段数. table_existing也将被更改.
从速度的角度来看,最优的数据库结构是什么？我认为从可维护性的角度来看,选项(B)可能会更好.
EDIT1
两个选项都不是我应用程序中最关键/经常使用的表.
在方案(B)中,数据分割后,完全不需要加入.如果我知道我需要XX_1的Fields,我会去那张桌子.
我想知道如果有一个具有许多未使用的值的一个大表的优点和缺点,而不是将更多数量的数据分割成相同的数据.更多的表会导致数据库中的性能下降(我们已经有80个表)？
解决方法
那么什么是正确的,最佳的做法等,叫做Normalization.如果你这样做,就不会有任何可选列(不是字段),没有空格.可选列将位于单独的表中,行数较少.当然,您可以安排这些表格,使其成为可选列的集合,而不是每个一列(一个PK加号).
将子表中的行组合到一个5NF行很容易,这样做是一个视图(但不要通过视图进行更新,通过事务存储过程直接对每个子表执行).
更多的是,较小的表格是规范化关系数据库的性质.习惯它.由于缺乏标准化,重复和Null,更少的较大的表格较慢.加入在sql<但这是我们所有的.连接本身没有任何成本,只有连接的表(行,行宽度,连接列,数据类型,不匹配,索引[或不]).数据库针对归一化表进行了优化,而不是用于数据堆.和大量的桌子. 哪个恰好是最佳的再次表现,没有什么惊喜.原因有两个：
>表格较窄,因此每页更多行,每个物理I / O获取更多行,并在同一高速缓存空间中获得更多行.
>由于你没有空,那些列是固定的len,没有打包来提取列的内容.
对于具有许多可选(空)列的大型表,没有任何优点,只有缺点.从来没有违反标准的专业人士.
无论您是在考虑4或400个新表,答案都是不变的.
>一个建议,如果你正在认真考虑许多表：你正朝着第六正常形式的方向,而不意识到.所以实现它,正式地这样做.这400张桌子会受到更好的控制.如果你让专业人士做到这一点,那么他们会使其正常化,最终不到100.
