相关疑难解决方法(0)

我面临以下问题.我有一张非常大的桌子.此表是以前参与该项目的人员的遗产.该表位于MS SQL Server中.

该表具有以下属性:

1. 它有大约300列.它们都有"文本"类型,但其中一些最终应该代表其他类型(例如,整数或日期时间).因此,必须在使用它们之前将这些文本值转换为适当的类型
2. 该表有超过100毫米的行.桌子的空间很快就会达到1TB
3. 该表没有任何索引
4. 该表没有任何实现的分区机制.

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

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

它提出了以下问题:

1. 这种标准化真的会增加这些100个领域中某些领域的条件速度吗？如果我们忘记了保留这些列所需的大小,那么由于初始文本列与tinyint-columns的替换,是否会增加性能？如果我不进行任何规范化并简单地在这些初始文本列上放置索引,那么性能是否与计划的tinyint-column上的索引相同？
2. 如果我执行所描述的规范化,那么构建一个显示文本值的视图将需要将我的主表加入大约100个附加表.一个积极的时刻是我将为对"主键"="外键"进行那些连接.但是仍然应该加入相当多的表.这是一个问题:对此视图的查询性能是否与初始非规范化表的查询性能相比是否会更差？SQL Server Optimizer是否真的能够以允许规范化的优势的方式优化查询？

抱歉这么长的文字.

感谢您的评论!

PS我创建了一个关于加入100个表的相关问题; 加入100张桌子