mysql views performance vs extra column

Question

Мой вопрос о выборе наилучшего метода для выполнения задания. я представлю цель и различные решения.

У меня есть список предметов и список категорий. каждый из них может принадлежать нескольким категориям.

items   (id, name, ...other fields...) 
categories  (id, name, ......) 
category_items (category_id, item_id) 

список предметов очень большой и обновляется каждые 10 минут (с использованием cron). список категорий фиксирован.

на моей странице, я показываю большой список предметов, и у меня есть фильтры категорий. вся фильтрация выполняется на javascript на стороне клиента. Причина в том, что доступные в настоящее время элементы ограничены + 1000, поэтому все данные (элементы + категории) будут загружаться вместе.

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

1. запуск одного выбора с использованием join и group_concat. что-то вроде этого:.

   ВЫБРАТЬ I *, GROUP_CONCAT (. CI category_id Сепаратор "") КАК category_list ИЗ items КАК я LEFT JOIN category_items AS КЕ на (CI item_id = я id.). ГДЕ ... ГРУППА BY i. id ORDER BY ...

2. создания представления с выше

3. хранения результата GROUP_CONCAT в качестве дополнительного столбца. это будет обновляться каждые несколько минут в режиме cron.

индексация выполнена правильно, поэтому все методы будут работать относительно быстро. join - тяжелая операция, поэтому мой вопрос о (2), (3):

- это обновление, обновленное только на каждом CRUD, или оно рассчитано на каждый выбор? если он обновляется только на CRUD, он должен быть примерно таким же, как и хранение столбца.

Помните, что таблица элементов будет расти, и будут выбраны только последние строки.

Answer 1

Решение 4. Введите таблицу типов MEMORY, которая будет обновлена ​​с результатами вашего запроса из решения 1, с помощью того же скрипта cron, который обновляет таблицу items.

Кроме этого: 1. и 2. эквивалентны. Представления MySQL не реализованы, поэтому запрос к представлению фактически запустит SELECT из точки 1.

Answer 2

Создание представления просто сохраняет запрос, (2) все равно будет выполнять запрос и соединение. (3), конечно, сэкономит время за счет пространства.

ответа, поэтому вопрос: Есть ли у вас и вашего приложения времени значения или пространство?

Кроме того, вместо использования cron для обновления поля кеша (ваш GROUP_CONCAT) вы можете использовать триггер в таблице category_items;