Должен ли я использовать отдельную таблицу для повторяющихся значений (varchar)?

Question

У меня есть таблица, в которой три строки данных добавляются в секунду и в которых я намерен хранить около 30M строк. (Старые данные будут удалены).

Мне нужно добавить столбец: varchar (1000). Я не могу заранее сказать, что это будет, но я знаю, что он будет очень повторяющимся: тысячи-миллионы строк будут иметь одинаковое значение. Это обычно около 200 символов.

Поскольку данные добавляются с помощью хранимой процедуры я вижу две опции

1. Добавить столбец VARCHAR (1000)
2. Создать таблицу (интермедиат идентификатор, VARCHAR 1000) значение() В StoredProcedure , посмотрите, существует ли значение в этой другой таблице или создайте его. Я бы ожидал, что эта другая таблица будет иметь максимум 100 значений за все время.

Я знаю некоторые из компромиссов между этими двумя вариантами, но мне трудно решить вопрос.

Вариант 1 тяжелее, но я получаю более быстрые вставки. Требуется меньше соединений, поэтому запрос проще. Вариант 2 - более легкая вставка, занимающая больше времени, но запрос может быть быстрее. Я думаю, что я ближе к нормальной форме, но тогда у меня также есть таблица с одним значимым столбцом.

Из информации, которую я вам дал, какой вариант кажется лучше? (Вы также можете выбрать другой вариант).

Answer 1

Вы также должны исследовать page compression, возможно, вы можете сделать простую вещь и по-прежнему получить небольшую (иш) таблицу. Хотя, если вы говорите, это SQL Express, вы не сможете использовать его, как требование Enterprise Edition.

Я неоднократно использовал в своих проектах свой второй подход. Каждая вставка должна пройти через хранимую процедуру, которая получает идентификатор идентификатора поиска или вставляет новый, если не найден, и возвращает идентификатор. Специально для таких больших столбцов, как ваш, кажется, с большим количеством строк, но так мало отдельных значений, сохранение в пространстве должно превзойти дополнительные накладные расходы внешнего ключа и затраты на поиск в соединениях запросов. См. Также Disk is Cheap... That's not the point!.