Мне пришло в голову решение создать еще один класс ProductBase со статической переменной products (@var Product[]) и методов getProduct() (@return Product), который в случае, если экземпляр этого продукта был уже создан возвращал его из переменной products, иначе создавал такой экземпляр и сохранял его в эту самую переменную.
Хм....у VK же API имеется. Oauth авторизация и делай, что хочешь(в пределах возможностей API). Ограничение 3 запроса в секунду, но у VK есть свой JS-подобный язык, позволяющий сделать до 25 вызовов за одно обращение.
Если группировка делается по одному столбцу, то да, если по двум - по двум и будет сгруппировано, по трем - ...и т.д.
Если нет необходимости получения какой-либо агрегатной информации, то можно воспользоваться DISTINCT.
В PostgresSQL нет понятия ENGINE, также нет понятия AUTO_INCREMENT, но есть понятие sequence, который является отдельным объектом в данной СУБД.
P.S. Вы предпочитаете бежать от проблемы, чем решать ее. PostgresSQL по умолчанию настроен таким образом, чтобы запуститься даже на калькуляторе, так что неизбежно придется конфигурировать те или иные параметры.
Все дело в сортировке (да и вездесущие LEFT JOIN ничего хорошего не принесут). Сортировка, слияние результатов таблиц(join merge) очень дорогое удовольствие.
Смотрите SHOW STATUS.
Скорей всего в буферы не помещается результат - sort_buffer_size, tmp_table_size, max_heap_table_size и т.д. Зависит от результата SHOW STATUS и используемого движка.
P.S. Даже, если все будет помещаться в буферы, то врят ли удастся получить приемлемое время выполнения. Здесь несколько путей:
- повысить процессорную мощь и более производительную подсистему хранения использовать(SSD)
- разбить запрос на несколько мелких
- денормализовать БД
- установить Sphinx и скормить данные ему.
Главная
Помощь
Поиск
Пользователи
Найдено сообщений: 129
