Должен ли я использовать таблицу строк, чтобы сделать базу данных более эффективной?

Question

Допустим, у вас есть база данных с одной таблицей, например ...

---------------------------------------------
| Name    |  FavoriteFood                   |
---------------------------------------------
| Alice   | Pizza                           |
| Mark    | Sushi                           |
| Jack    | Pizza                           |
---------------------------------------------

Было бы более экономно использовать дополнительную таблицу под названием «Strings», в которой хранятся строки, и изменить столбец FavoriteFood на индекс в таблице строк. В приведенном выше примере «Пицца» выглядит так, как будто она хранится дважды, но с дополнительной таблицей она будет сохраняться только один раз. Конечно, предположим, что есть только 1 000 000 строк и 1 000 уникальных строк вместо 3 строк и 2 уникальных строк.

Редактировать: Мы не знаем заранее, что такое FavoriteFoods: они предоставляются пользователем. Программный интерфейс к таблице строк будет выглядеть примерно так ...

String GetString(int ID) { return String at with Row-ID == ID }

int GetID(String s) {
  if s exists, return row-id;
  else {
    Create new row;
    return new row id;
  }
}

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

Answer 1

Вы должны думать о том, что делает хороший дизайн с точки зрения вашей проблемной области, а не эффективности (если вы не ожидаете иметь десятки миллионов + строк).

Хорошо спроектированная база данных должна быть в 3NF (третья нормальная форма). Денормализуйте только тогда, когда вы обнаружили проблему с производительностью путем измерения.

Answer 2

Чем вы измеряете эффективность? Предполагая, что нет никаких других данных, связанных с каждым FavoriteFood (в этом случае очевидно, что вам нужны две таблицы), подход с одной таблицей, вероятно, более эффективен по времени, поскольку ненужное объединение повлечет за собой дополнительные затраты на обработку. С другой стороны, подход с двумя таблицами может быть более экономичным, поскольку для хранения индекса требуется меньше места, чем для строки, но это зависит от того, как конкретная база данных, которую вы используете, оптимизирует хранение повторяющихся строк.

Answer 3

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

Но проблема с этим подходом была бы для вставок. Вам нужно вставить в обе таблицы, а также поддерживать ограничения внешнего ключа, так что это добавляет немного сложности к простой таблице.

Answer 4

Плюсы для отдельной таблицы "Строки":

• Вероятно, меньше места, если строки повторяются очень часто
• Вероятно, более быстрые типичные запросы - из-за меньшего числа операций ввода-вывода

Минусы:

• Вы будете писать более сложные запросы достичь того же результата
• Если коэффициент повторения довольно мал, вы получите более высокое выполнение запроса время. Чтобы разрешить каждый идентификатор в строку (или обратно), сервер базы данных выполнит один поиск (операция поиска) для каждого идентификатора. Итак, вы получаете дополнительный log (Strings.Count ()) фактор ~ для каждого запроса, делающего это.

Но на самом деле это действительно эффективно. Например. большинство полнотекстовых поисковых систем используют почти такой подход для хранения карт документов-слов.