большой таблицы, а потом в приложении делать запросы уже во вьюху со всеми фильтрами и сортировками? Сильно ли это скажется на производительности или вообще нейтрально?
ммм, если честно, мне кажется это избыточным
Надо тестировать, может быть так что некоторые оптимизации не будут работать, и запрос напрямую в основную таблицу будет работать намного быстрее. Зависит от вашей вьшки
нуллифы, dictget'ы, concat'ы)
если обычная вьюха нематериализованная - то без разницы, если материализованная - то так все и делают, единственное что - нужно при апдейтах и делитах ручками обновлять материализованное представление
нематериализованная, да т.е. дополнительных накладных расходов не будет? оно не будет пытаться засунуть таблицу в память? очень слаб в этих вопросах
чтобы прочитать нужные поля из вью, вью прочитает все поля которые будут указаны в основной таблице. если там будут группировки, и потом по ним выбрать еще данные, то естественно это будет медленнее, чем забрать нужные столбцы из оригинальонй таблицы
как правило я забираю все столбцы, группировок нет
нет, будет вложенная query. Normal views do not store any data. They just perform a read from another table on each access. In other words, a normal view is nothing more than a saved query. When reading from a view, this saved query is used as a subquery in the FROM clause.
спасибо! select * from (select * from view where a = b) запрос во вьюхе - сотни миллионов строк в оперативку они не пойдут, все будет хорошо?) формулировка как раз про это?
в оперативку не пойдут, но причина по который вы хотите так делать не очень понятна... естественно лучше если на уровне view вы будете отсекать как можно больше строк
я не до конца уверен, что буду делать так как раз во вьюхе не будет никаких фильтров и сортировок просто из приложения хочу обращаться уже к готовой таблице и разработчикам дать уже готовую таблицу готовую для фильтрации и сортировок из разных приложений так что хотелось бы точно знать не будет ли оно потреблять значительно больше ресурсов если не пойдет в оперативку, то, наверное, все ок и так можно?
Вы хотите от разработчиков скрыть определеные колонки? И поэтому использовать View?
в том числе + заранее сделать всякие такие штуки concat( '', if(Impact = 'HIGH', 'HIGH|', ''), if(lof != '.' or lof = '', 'LoF|', ''), if(nmd != '.' or nmd = '', 'NMD|', ''), if(sr != '', 'SR|', ''), if(sa != '', 'SA|', ''), if(sd != '', 'SD|', ''), if(length(RU) = 1 and toInt8OrZero(REFREP) < 4, 'Rep|', ''), if(length(RU) = 1 and toInt8OrZero(REFREP) > 4, 'HomoP|', '') ) flag_filter
в вашем случае да, есть пушдаун оптимизация если нет всяких групбай и прочего
А давно завезли?
На select a,b,c from tb? Да помоему чуть ли не несколько лет?
Оки, может я что-то не так тестировал тогда
там корнер кейсов много
Обсуждают сегодня