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

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

0 голосов
/ 09 декабря 2011

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

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

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

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

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

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

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

1 Ответ

2 голосов
/ 09 декабря 2011

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

Я неоднократно использовал в своих проектах ваш второй подход. Каждая вставка должна проходить через хранимую процедуру, которая получает идентификатор поискового значения, или вставляет новую, если она не найдена, и возвращает идентификатор. Специально для таких больших столбцов, как вы, кажется, с большим количеством строк и небольшим количеством различных значений, экономия пространства должна превысить дополнительные издержки внешнего ключа и стоимость поиска в соединениях запросов. Смотрите также Диск дешевый ... Не в этом дело! .

...