Разумно ли использовать временные таблицы? - PullRequest
Новая
       15

Разумно ли использовать временные таблицы?

3 голосов
/ 29 апреля 2010

У нас есть таблица базы данных mySQL для products. Мы используем уровень кэша, чтобы уменьшить нагрузку на базу данных, но мы считаем, что было бы неплохо минимизировать фактические данные, необходимые для хранения на уровне кэша, чтобы еще больше ускорить работу приложения.

Все товары в базе данных, которые видны посетителям, имеют прикрепленную цену:

Цены хранятся в другой таблице, которая называется prices. Существует несколько ценовых категорий в зависимости от того, к какому уровню скидки относится каждый посетитель (клиент). Время от времени проводятся кампании, что означает, что для каждого продукта доступна специальная цена. Специальные цены хранятся в таблице под названием specials.

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

Он будет иметь только необходимую информацию и, конечно, будет кэшироваться. 

-------------|-------------|------------ 
| productId  |  hasPrice   | hasSpecial
-------------|-------------|------------ 
  1          |  1          | 0
  2          |  1          | 1

Сделав это, было бы очень легко узнать, действительно ли конкретный продукт имеет цену, без необходимости перебирать полную таблицу prices или specials каждый раз, когда продукт должен быть указан или представлен.

  • Являются ли временные таблицы обычным явлением для веб-приложений или это просто плохой дизайн?

Ответы [ 2 ]

2 голосов
/ 29 апреля 2010

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

1 голос
/ 01 мая 2010

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

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

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

По сути, вы можете увеличить объем работы на пути записи, чтобы уменьшить объем на пути чтения, если вы планируете читать намного больше, чем писать.

...