Сути нашего не имеющего никакого смысла разговора это не меняет.

лол

Иди книжку почитай.

Математика там.

Это я уже засыпаю, я же написал что я ошибся. А вот 0.2ms для запроса - много ?

Но с тобой я это обсужать не хочу, потому что мы зашли в тупик.

0.2с - много? Или все таки 0.2мс??

Нет, 0.2ms. Я же тебе привёл выше пример COUNT'а по всей базе.

По твоей базе у тебя 0.7ms

Скорость.

Потому что там в 300k раз больше данных, чем у тебя.

Я же выше писал, что у меня и не будет 200ms.

0.2ms

У меня тоже не будет 200

Ну не посчитать их всех за 0.2ms, согласен.

Я про это.

Ладно, слушай, наш замечательный разговор зашёл в тупик недопонимания.

Что я делаю не так?

Да всё так, если ты про запрос.

SELECT COUNT(id) быстрее будет.

Если у тебя основной ключ там.

Разве что.

Ещё был хак с COUNT(1), но вроде бы уже неактуально.

Т.к. PostgreSQL вроде бы уже сам подхватывает это с какой-то версии.

Нет, это (id) никак не влияет

Я имею в виду IS NULL и primary key.

Т.к. основа не может быть NULL.

И часто это свойство используют для составления более быстрых выборок.

А COUNT(1) внутренний оптимизатор раньше жрал по-другому.

Но это было достаточно давно.

тоже COUNT(1) юзал раньше, но с какого-то момента он перестал служить

тоже COUNT(1) юзал раньше, но с какого-то момента он перестал служить

Да там костыль для оптимайзера был.

COUNT(1) на каждую запись вешал единицу и считал единицы.

А COUNT(*) получал записи и считал их.

Сейчас разницы вроде бы никакой уже, потому что уже неактуально.

А раньше какие только костыли не использовали.

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

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

Когда AR генерирует такой SQL: SELECT "cart_items"."id" AS t0_r0, "cart_items"."cart_id" AS t0_r1, "cart_items"."variant_id" AS t0_r2, "cart_items"."quantity" AS t0_r3 это нормально, или лучше избегать такого?

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

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

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

Да.

Так делает Opencart и Magento.

Раз уж про eCommerce зашло.

А потом заказ забирается из базы один раз уже на моменте чекаута.

Т.е. за весь цикл одно чтение из базы только.

Всё остальное - записи (а они быстрее).

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

Ну вот я и решил посоветовать, но видимо как-то плохо получилось.

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

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

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

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

Так почему бы не записать туда корзину и на цикл пользователя сократить 5-10 запросов к базе.

1000 пользователей экономит уже 5-10k запросов.

А это ведь совсем неплохо.

Ок, но это сейчас проблема первая с конца

Я много архитектуры перенял от spree

Там мне как раз и не нравилось что любое маленькое действие ведет за собой гору запросов

А ты как сделал?

Что именно?

Там мне как раз и не нравилось что любое маленькое действие ведет за собой гору запросов

Или ты именно это сейчас и исправляешь?

Ну в целом такие проблемы и получил

Только в меньшем масштабе

Кстати на минутку для юмора, я тут вспомнил 1C-Bitrix может на главной до 30 запросов к базе отхуярить.

230 сообщений сгенерировали за обед

вы издеваетесь?))

Проблема в том что кеширование данных сильно уродует код

Я бы с тобой тут не согласился, но это никого не ебёт.

30 запросов - мелочи))) на первом PHP сайте, где я работал, генерировалось блее 300 за страницу

У 1C-Bitrix ещё есть встроенный cron для шареда.

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

?

)))

я прям точно помню.. там таблица была, выводилось 100 элементов - это первый запрос и по 3-4 запроса для каждого элемента

Слава богу, что проект давно переписали)

Да раньше и мерки были другие.

XML на 100 мегов - ночной кошмар.

Хотя это и сейчас не конфетка.

Possibilities generator https://t.co/X4dJXLuIvD

Всем привет! Кто учил Руби по скринкастам hasBrains(RubyScreencasts)? Не работает код в уроках(вернее тот что я написал по урокам), а именно 28 эпизод 10:30 - там где задает аргументы для корзины - у меня IDE подчеркивает красным. Срабатывает только если передавать обект типа RealItem и его не удаляет если повторно передать(а должен удалять), так же ему рандомно задает цену(она не должна меняться, если не апрель месяц). Если передать объект типа VirtualItem (в примере это car, то пишет что метод weight не определен. Могу скинуть архив или выложить код каждого файла в пастебин.

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

я недавно проходил этот курс, но он мне показался устаревшим

> «IDE подчеркивает красным». IDE не нужны. Пиши в виме.

IDE иногда врут

Когда загрузятся. Я никогда не дожидался этого момента. Работать надо было.

архив с прогой

запускать add_to_cart.rb из ком строки передавая аргументы имя товары

> «IDE подчеркивает красным». IDE не нужны. Пиши в виме.

Кстати да.

Ты издеваешься? А ссылку на репо нельзя дать?

Например, atom неверно отображает синтаксис в slim, когда ты пишешь `=> value` даже когда код верен.

Ну атом ещё терпимо. Там эту херню можно самому поправить

Лень, если честно

А вот с любыми джетбрейновскими монстрами не прокатит

Ага

Лень, если честно

Тогда не жалуйся