Нормализация чрезвычайно большого стола

Я сталкиваюсь со следующей проблемой. У меня очень большой стол. Эта таблица является наследием людей, которые ранее работали над проектом. Таблица находится в MS SQL Server.

Таблица имеет следующие свойства:

в нем около 300 столбцов. Все они имеюттекст" тип, но некоторые из них в конечном итоге должны представлять другие типы (например, целое число или datetime). Поэтому необходимо преобразовать эти текстовые значения в соответствующие типы, прежде чем использовать ихтаблица содержит более 100 миллиом строк. Место для стола скоро достигнет 1 терабайтатаблица не имеет индексовВ таблице нет реализованных механизмов разбиения.

Как вы можете догадаться, невозможно выполнить какой-либо разумный запрос к этой таблице. Теперь люди только вставляют новые записи в таблицу, но никто не использует их. Так что мне нужно его реструктурировать. Я планирую создать новую структуру и пополнить новую структуру данными из старой таблицы. Очевидно, я буду реализовывать разбиение, но это не единственное, что нужно сделать.

Одна из наиболее важных особенностей таблицы состоит в том, что эти поля являются чисто текстовыми (т.е. они недолжны быть преобразованы в другой тип) обычно имеют часто повторяющиеся значения. Таким образом, фактическое разнообразие значений в данном столбце находится в диапазоне 5-30 различных значений. Это наводит на мысль о нормализации: для каждого такого текстового столбца я создам дополнительную таблицу со списком всех различных значений, которые могут появиться в этом столбце, затем я создам первичный ключ (tinyint) в этой дополнительной таблице и затем будет использовать соответствующий внешний ключ в исходной таблице вместо сохранения этих текстовых значений в исходной таблице. Затем я добавлю индекс в этот столбец внешнего ключа. Количество столбцов, которые будут обработаны таким образом, составляет около 100.

Возникают следующие вопросы:

действительно ли эта нормализация увеличит скорость наложения условий на некоторые из этих 100 полей? Если мы забудем о размере, необходимом для хранения этих столбцов, будет ли какое-либо увеличение производительности из-за замены исходных текстовых столбцов на tinyint-столбцы? Если я не делаю никаких нормализаций и просто помещаю индекс в эти исходные текстовые столбцы, будет ли производительность такой же, как для индекса в запланированном столбце tinyint?Если я выполню описанную нормализацию, то для построения представления с текстовыми значениями потребуется объединить мою основную таблицу с примерно 100 дополнительными таблицами. Положительным моментом является то, что ясделаю эти соединения для пар "первичный ключ "="иностранный ключ", Но все же довольно большое количество таблиц должно быть объединено. Здесь возникает вопрос: будет ли производительность запросов, выполненных в этом представлении, сравниваться с производительностью запросов к исходной ненормализованной таблице, не хуже? Сможет ли оптимизатор SQL Server действительно оптимизировать запрос так, чтобы можно было воспользоваться преимуществами нормализации?

Извините за такой длинный текст.

Спасибо за каждый комментарий!

PS Я создал связанный вопрос относительно объединения 100 таблиц;Объединение 100 столов

Ответы на вопрос(4)

Ваш ответ на вопрос