Кеширование вьюх. (Свойство CacheLookup для View)

[Logger]

Цитата:

Сообщение от Vadik

А если абстрагироваться от версии, как Вы считаете должно было бы работать кэширование? У view же нет первичного или уникального ключа

Думаю, что если по правильному делать, то надо было бы у вьюхи сделать подветку в AOT -
Caching keys

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

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

Получается дурацкая ситуация - берем кверик, на основе которого сделана вьюха, используем его в запросе - отрабатывает кеширование, SQL не нагружается. Используем вьюху на основе этого кверика, использующую те же поля, которые кверик возвращает или их часть - все запросы летят в SQL. Лучше бы сделали наоборот. Дать программисту возможность настроить кеширование для вьюх, и забить на джоины. Это особенно актуально, потому что из-за нормализации базы многие вьюхи - это простые джоины, и если делать запрос без вьюхи, то кеширование работает.

Касательно отсутствия у вьюхи ключа, я подумал что в простом случае джоина можно было бы попробовать использовать ключ от таблички. Похожий подход использован в union Query. Там поля первого датасорса определяют набор полей, названия и типы для юниона. Здесь аналогично можно было бы сделать. Хотя, конечно, это полумера.