Модуль Вы уже смотрели (история просмотров)

[ocdev_pro]

Dotrox, В любом случае, если тебе нужно будет в БД писать, то в модуле уже почти все готово и нужно будет 5 строчек изменить

[ArtemPitov]

2 часа назад, Dotrox сказал:

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

1) Одно ограничение на количество хранимых товаров все решает

2) Разбухания базы + это еще одна таблица  + чревато мусором, а если гостей от 1к в день то сомнительная перспектива 

3) Для гостей можно даже в локалсторидже хранить и дергать аяксом нужные товары и проблем не будет

[Dotrox]

1 час назад, Waha сказал:

кука в  100 товаров весит примерно 2800 байт

А если у товаров будут пятизначные id?

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

И, кстати, 2800 байт - это более 2,5Кб, что довольно много всего лишь для одного из заголовков.

 

1 час назад, Waha сказал:

с учетом того, что можно ограничить куку, все будет норм..

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

Это в обычных модулях проблема решается фиксом в виде обрезки списка до лимита вывода (авторы почему-то ленятся сделать это самостоятельно), но там этот лимит обычно не превышает десятка, ибо для вывода в блоке нет смысла в большем.

 

 

1 час назад, Waha сказал:

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

Сократите им время хранения (незарегистрированным, то есть).

 

1 час назад, Waha сказал:

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

Либо вы сильно преувеличиваете, либо вы что-то перемудрили.

 

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

 

 

Кстати, о каких пользователях идёт речь вот здесь (про логин):

Цитата

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

?

 

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

 

 

7 минут назад, ArtemPitov сказал:

+ это еще одна таблица

Которая и так есть. Или вы думали о хранении в разных таблицах истории зарегистрированных и не зарегистрированных?

 

 

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

 

[ocdev_pro]

Dotrox, Учту, то что вы говорите.

А вот вечный логин, ну это уже сами крутите, в чистом oc такого нет, я уведомил о функционале.

 

Мне немного ваша позиция не ясна, Вы хотите помочь советом в разработке или же просто критикуете? 

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

[Dotrox]

14 часов назад, Waha сказал:

Мне немного ваша позиция не ясна, Вы хотите помочь советом в разработке или же просто критикуете? 

Я хочу, чтоб ваш модуль был готов к работе в реальных магазинах. Альтернативные модули в оригинале для реального использования не пригодны (из-за куки). Но и ваш не будет пригоден, если вы будете полагаться на то, что никто не будет ставить больших лимитов или, что в магазинах не могут быть пятизначные (и даже ещё большие) id или, что зарегистрированных будут единицы и т.д.

 

17 часов назад, Waha сказал:

Приводите тогда понятные решения в личку или в тему поддержки

Что непонятного в идеи, что в куки не должен храниться список товаров? Я уже многократно расписал недостатки этого подхода.

Если модуль уже умеет хранить списки в базе для зарегистрированных, то какое ещё решение вам нужно?

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

[ocdev_pro]

Я сторонник все же, что бы такие данные хранились на стороне клиента, а не сервера. Связано это с тем, что магазин с посещаемостью хорошей будет тупить, если постоянно от гостей и ботов просмотренные товары будут писаться/читаться из базы, это не мысли "с потолка", а факты основаны на личном опыте.
Поэтому cookie изначально есть и localStorage будет в конечном итоге.

[chukcha]

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

 

7 минут назад, Waha сказал:

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

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

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

Хранить в локалсторедж можно, но ведь это все равно как-то нужно отдавать потом на сервер,

 

[ocdev_pro]

chukcha, Да я знаю все эти ньюансы, за ботов с куками я не парюсь, а с localStorage уже разобрался там тоже проблем нету.
Единственное неудобство, что запись в хранилище на стороне js происходит. Поэтому изначально массив можно создать в сессии а потом отдать во вьюху и там уже в хранилище поместить и аналогично из хранилища по ajax дернуть значение и передать массив id в контроллер..
Что бы окончательно решить как делать надо потестить, но я более чем уверен что localStorage всяко быстрее будет чем писать и читать из БД

[Dotrox]

В 09.07.2017 в 16:08, chukcha сказал:

Для незарегистрированных вполне хватит и кук, но таки да, ее можно ограничит 10-15 штук

И в случае простых модулей просмотренных это обычно и решает проблему. Но в данном случае фишка модуля то как раз в том, чтоб можно было смотреть условно "всю" историю просмотров. Иначе для незарегистрированных он не будет особо отличаться от остальных модулей. Да, отдельная страница, но на ней те же 10-15 товаров, которые можно и в обычном блоке вывести.

 

В 09.07.2017 в 15:58, Waha сказал:

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

Это один лишний запрос на чтение и ещё один на запись. И на запись только для страниц товаров. Запрос к одной таблице, без каких-либо джоинов, запрос на выборку одной записи и на вставку/обновление одной записи.

Если у магазина такая посещаемость, что этот один запрос создаст существенные тормоза (или хотя бы вообще просто будет заметен), то, возможно, магазину стоит подумать о переезде с шареда?

 

 

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

 

[chukcha]

7 минут назад, Dotrox сказал:

он не будет особо отличаться от остальных модулей.

И не надо

 

Все ограничено жизнью сессии для незарегистрированных смысл хранить в базе

 

В кухах хранить только текущие
а в сессии можно хранить и все сессионные

 

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

А с сервера отдавали только данные

 

 

[Dotrox]

2 минуты назад, chukcha сказал:

Все ограничено жизнью сессии для незарегистрированных смысл хранить в базе

Жизнь не ограничивается рамками сессии

 

Смысл то как раз в том, чтоб писать в куки свой идентификатор и его же в базу. И тогда пофиг на сессию. При чём один механизм и для зарегистрированных и для незарегистрированных. Просто для зарегистрированных будет ещё дописываться id покупателя. И тогда вдобавок никаких проблем с привязкой к акаунту покупателя товаров просмотренных до входа/регистрации.

 

 

6 минут назад, chukcha сказал:

Ну.. я видел людей, которые писали толстого клиента, и тонкий сервер

Для магазинов идеальное решение - это гибридное приложение, то есть SPA, но с серверным рендером при входе (прямом запросе).

[ocdev_pro]

Dotrox, Ну вот по делу и аргументировано заговорил)) Спасибо, выделю пару дней и перепишу)

[Dotrox]

3 минуты назад, Waha сказал:

Ну вот по делу и аргументировано заговорил))

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

[ocdev_pro]

Обновление завершено