Ребят, привет) Какой индекс посоветуете повесить на timestamp колонку, чтобы использовался в запросах с where year(RecordTimestamp) = 2014, например?

Никакой

Если ты оборачиваешь индексируемую колонку в функцию индекс работать не будет

Не знал, спасибо

Mysql к сожалению не умеет функциональных индексов

Придется писать запросы типа where dt between 20140101 and 20140101 + interval 1 year - interval 1 second

Mysql к сожалению не умеет функциональных индексов

Постгрес умеет не знаете?

Умеет

круто

Постгрес умеет не знаете?

Вот так и переходят на постгрю )

Вот так и переходят на постгрю )

Дв, вот задумываюсь, все чаще об этом)

Хотя если у вас возникают такие вопросы

Я думаю особой разницы вы не почувствуете

Postgres несколько строже к приведению типов... Это может быть больно поначалу

Ну и вообще он строже к group by тому же

уже не строже. постгрес уже тупее чем mysql в плане group by

и функциональные индексы уже 2 года как есть, хоть и через виртуальные колонки. но у такого подхода как водится есть не только минусы, но и плюсы

Какие плюсы?

уже не строже. постгрес уже тупее чем mysql в плане group by

Ну вот да... с group by мне уже пытались объяснить, что указывать половину колонок из набора это круто - но я так и не понял

Какие плюсы?

Например что колонку можно не хранить

Это как?

Она будет вычисляться на лету

Как такое возможно? Если функциональный индекс сформирован, его надо куда-то на диск записать, иначе как по нему искать быстро?

Индекс хранится

А колонка нет)

эммм

Ну так и в постгресе. Вопрос то в чем такой подход лучше чем подход потсгреса

Какие плюсы

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

Ну вот да... с group by мне уже пытались объяснить, что указывать половину колонок из набора это круто - но я так и не понял

почитай про функциональные зависимости колонок в group by. Вот mysql c 5.7 умеет вычислять функциональные зависимости в пределах одной таблицы и между таблицами в join-ах. А постгрес только в пределах одной таблицы

Какие плюсы?

плюсы в том, что виртуальные колонки можно использовать для разных кейсов, не только для создания функциональных индексов. И там, где в Oracle, MSSQL и MySQL можно создать хранимую или виртуальную вычисляемую колонку, в постгресе нужно что-то колхозить в зависимости от ситуации. И при миграции с других СУБД тоже

вспомнил ещё один случай, где group by в mysql умнее, чем в постгрес: loose index scan постгрес не умеет, хотя пользователи просят уже лет 10. в mysql появился в 2005 году

Ну вот для меня было не очевидным указывать в group by 2 поля из 5

Хотя возможно, там да - были вычисляемые поля

Это вообще не про вычисляемые поля

Это про то, что с 1999 года SQL стандарт допускает запросы вида select id, k group by id, если есть уникальный индекс по id

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

В том примере было несколько иное. Про опцию ONLY_FULL_GROUP_BY было...

Если найду - скину пример

Это про то, что с 1999 года SQL стандарт допускает запросы вида select id, k group by id, если есть уникальный индекс по id

Хотя тут от group by никакого смысла

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

В том примере было несколько иное. Про опцию ONLY_FULL_GROUP_BY было...

Мы с помощью этой опции нашли багу в запросе

Так что указывать все колонки в group by это хорошо :) и правильно что постгрес так действовал всегда. Хоть иногда это и кажется излишним.

Был интересный случай. На аутсорс отдавали 2 проекта. Один php+mysql, второй php+oracle. С первым команда справилась на ура (сразу видно знакомая связка), а вот со вторым были проблемы... То union all между строкой и числом не шёл, то группировки не работали

Так что указывать все колонки в group by это хорошо :) и правильно что постгрес так действовал всегда. Хоть иногда это и кажется излишним.

Постгрес так действовал не всегда. Он понимает функциональные зависимости по крайней мере с 9.5, но не все

А до этого приходилось колхозить ненужные агрегаты там, где они были не нужны

Э да, я имею в виду просто тупое перечисление всего без анализа всяких зависимостей, я это еще в 9.3 делал

Ну вот анализ зависимостей в постгресе туповат. И до сих пор приходится колхозить

а еще вродь с транзакциями чет не лучше чем в mysql

Был интересный случай. На аутсорс отдавали 2 проекта. Один php+mysql, второй php+oracle. С первым команда справилась на ура (сразу видно знакомая связка), а вот со вторым были проблемы... То union all между строкой и числом не шёл, то группировки не работали

ну вы еще хотели чтобы группировки в оракле работали ) это ж моветон

Они работают ) и даже неплохо (в плане стоимости), но различия с mysql есть.

Вообще, я вижу, что mysql в дефолтные настройки с каждой версией тянет все больше "ограничений". Все ближе к pg, oracle

если честно - не могу представить чтобы они работали хуже чем в проприетарном продукте

другое дело что mysql позволяет самому себе выстрелить в ногу

Вот для начинающих разработчиков использование mysql я бы крайне не рекомендовал. Приучает к таким "вольностям"

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

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

например?

Например можно вставлять строку длиннее чем позволяет схема и оно молча проглотит

В 5.7 все стало сильно лучше

Ну вот, а что не стало лучше?

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

например?

разные режимы SQL_MODE

возможность вручную(!) указать значение cost

возможность вручную(!) указать значение cost

Типа как в pg у функций?

прямо в таблице в схема mysq.*

поставил ssd вместо обычных - можешь "подкрутить" значение i/o cost для оптимизатора

engine_cost и server_cost таблички

Привет всем как можно закинуть api на сайт???

Читай, что такое api

Ребят, вопрос ламерский, коенчно, но не могу допереть, может кто мне подскажет. Суть в чем, необходимо выбрать несколько записей из таблицы, через "in". where column_1 in (..) AND column_2 in (..). Сложность в том, что поля дублируются. Можно ли как-то указать соответствие первого элемента в in - первому элементу во втором in. Ибо выборка работает некорректно. Заранее спасибо

не совсем ясно, о чём речь, но предполагаю, что нужна конструкция where (column_1, column_2) in ((c1, c2), (c3, c4), ...)

Так я еще не пробовал. Если спасет ситуацию - огромнейший респект и благодарность. Сейчас тарйну

То ли я дебил, то ли лыжи не едут Выдавало ошибки, взял в скобки, запрос отрабатывает, но нчиего не находит, но ведь, конструкция правильная: (pf.`virtuemart_custom_id`, pf.`customfield_value`) IN (("35","37"),("стальной","16")) ? соответствие полей указано верно, дважды проверил. Ничего не возвращает, увы, в чем может быть корень проблемы?

а where pf.virtuemart_custom_id = "35" and pf.customfield_value = "37" что-нибудь возвращает? подозреваю, что требуется на самом деле не это

Нет, не возвращало, ну и не возвращает. Проблема в том, что это Виртумартовский модуль Джумлы, править который хоть немного в этом запросе - переписывать его структуру в целом.

Запрос работает в цикле

Когда он один - отрабатывает корректно, но что бы совместить их - что нужно сделать - ума не приложу. Если where cn_1 in () and cn_2 in () - как бы все окей. Но возвращает значений больше, чем хотелось бы

Ибо соответствием первого со вторым даже и не пахнет

а какое соответствие нужно?

По факту, 35 - стальной 37 - 16 etc

Ага, прошу прощения. Видать в Сессиях что-то сохранилось, или запрос был только по одному "in", но если их сопоставить - выводит опять таки нчиего. За дезинформацию прошу прощения

но тогда (("35","стальной"),("37","16"))?

Сейчас попробую

Что-то есть, секунду

Вот к сожалению, все, да не все

Выводит два товара, в моем случае. У одного соответствие по двум параметрам, у дргуого - лишь по одному

А нужно, что бы было соответствие по двум, если они указаны.. Короче говоря, обыкновенная фильтрация по параметрам. ТО есть человек выбирает один парметр - ему выводится несколько товаров, а потом подставляется данный скъюэль, служащий для объединения параметров поиска

Но на данный момент оно рабоатет как "OR", а хотелось бы, что бы как "AND"

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

Ну смотрите. Как рабоатет фильтрация в любом из нормальных магазинов - человек выбирает один парааметр фильтрации, к примеру - цвет: красный. Соответственно выводятся все товары красного цвета, если же он параллельно выбирает размер, предположим пятый - то выборка всех товаров, у которых есть красный цвет и пятый размер. Собственно, нужно сделать тоже самое. Учитывая то, что это Вирутмарт, в котором запрос пишется вовсе не по людски, или же я просто слишком глуп для этого - то проще править сам sql. Изанчально все было просто если после выбора одного параметра фильтрации был выбрал следующий, то подставлялся следующий. А первый попросту улетучивался. Могу предоставить сам файл, в котором происходит все веселье, если это как-то улучшит ситуацию

Ну смотрите. Как рабоатет фильтрация в любом из нормальных магазинов - человек выбирает один парааметр фильтрации, к примеру - цвет: красный. Соответственно выводятся все товары красного цвета, если же он параллельно выбирает размер, предположим пятый - то выборка всех товаров, у которых есть красный цвет и пятый размер. Собственно, нужно сделать тоже самое. Учитывая то, что это Вирутмарт, в котором запрос пишется вовсе не по людски, или же я просто слишком глуп для этого - то проще править сам sql. Изанчально все было просто если после выбора одного параметра фильтрации был выбрал следующий, то подставлялся следующий. А первый попросту улетучивался. Могу предоставить сам файл, в котором происходит все веселье, если это как-то улучшит ситуацию

я понял. это ж key-value, он же schemaless, он же eav. если я правильно понимаю исходник, в virtuemart это сделано самым тупым способом. я могу накидать ссылок, как это делать правильно, но вряд ли вам это поможет, потому что требует другой организации данных

а в такой модели, как в virtuemart это только джойн, джойн, кладбище, боль

Я, конечно, знаю, что программист из меня не ахти, но рад услышать, что код изначально был не очень, спасибо. Голвоу посетило немного другое решение, на самом деле. Коенчно, править тот цикл и вообще пхп в данном файле - так себе идея, но можно написать свой цикл, в котором написать свой sql, который будет выводить необходимые значения, в зависимости от выбора фильтра, а в само по себе $where ='..' вставить айдишники, котоыре я получу в результате сделанного мной цикла. Еще раз спасибо, и прошу прощения за потраченное время

Проще говоря, получаю айди, а после "where product id in (74,76, etc)"

Как по мне, даже не сильно костыль, хотя может всякие гуру меня камнями закидают