我面临以下问题。我有一张非常大的桌子。该表是以前从事该项目的人员的传承。该表在MS SQL Server中。

该表具有以下属性：

1. 它有大约300列。它们都具有“文本”类型，但是其中一些最终应表示其他类型（例如，整数或日期时间）。因此，在使用它们之前，必须先将这些文本值转换为适当的类型
2. 该表有100余行。该表的空间很快将达到1 TB
3. 该表没有任何索引
4. 该表没有任何已实现的分区机制。

您可能会猜到，不可能对该表运行任何合理的查询。现在人们只将新记录插入表中，而没有人使用它。因此，我需要对其进行重组。我计划创建一个新结构，并用旧表中的数据重新填充新结构。显然，我将实现分区，但这不是唯一要做的事情。

该表最重要的功能之一是，那些纯文本字段（即不必将其转换为另一种类型）通常具有频繁重复的值。因此，给定列中值的实际变化范围是5到30个不同的值。这引发了进行规范化的想法：对于每个这样的文本列，我将创建一个附加表，其中包含该列中可能出现的所有不同值的列表，然后在该附加表中创建一个（tinyint）主键，然后将在原始表中使用适当的外键，而不是将这些文本值保留在原始表中。然后，我将在此外键列上放置一个索引。用这种方法处理的列数约为100。

它提出了以下问题：

1. 这种归一化是否真的会提高查询条件在这100个字段中的某些字段上施加条件的速度？如果我们忘记了保留这些列所需的大小，那么由于将初始文本列替换为tinyint列而导致性能会有所提高吗？如果我不进行任何归一化处理，而只是在这些初始文本列上添加索引，那么性能是否将与计划的tinyint列上的索引相同？
2. 如果我执行上述归一化，则构建一个显示文本值的视图将需要将我的主表与约100个其他表连接在一起。一个积极的时刻是，我将为“ primary key” =“ foreign key”对进行这些联接。但是仍然应该连接大量的表。这是一个问题：对该视图进行查询的性能与对初始非规范化表的查询性能相比是否会更差？SQL Server Optimizer是否真的能够以允许利用规范化好处的方式优化查询？

抱歉，这么长的文字。

感谢您的每条评论！

PS我创建了一个有关加入100张桌子的相关问题。
联接100张桌子