Checkbox-mutator, есть такая возможность, и есть ли в этом смысл?
Например, когда добавляешь новый товар, я ставлю галочку, и у меня появляется что новинка, а можно сделать так, чтобы при добавлении товар становился автоматически новым на какое-то время (которое я укажу), а после окончания времени с него снималась метка. Если же на товар больше всего человек заходило, то он становился рекомендованным или топовым, что-то такое, такая вот идея пришла, если есть возможность, то есть в этом что-то?
Всё же лучше отдельное поле. тоже временную метку, которая указывает, до какого времени товар будет считаться новым.
Так можно и автоматом при создании ее ставить, и вручную в любое время, и снять в любое время у любого отдельного товара.
Сергей delphinpro, чем лучше? Тем более если у нас пара миллионов товаров обход для снятия галки или упаси боже мы меняем что у нас теперь новинки это которые 3 дня назад добавлены, а не 2 - такое себе. Не говоря о том что у вас 99% товаров не будет использовать это поле 99% времени своего существования в базе
Дата новинки определяется временем добавления товара или изменения - она у нас есть из коробки. Имхо не надо умножать сущности сверх необходимого
Дмитрий, ну да. Вы торгуете мобильниками. 23-й год на дворе. А вы в первый раз продаете в своем магазе Nokia 2. У вас – это новинка. Но может менеджеры не хотят этот древний товар выставлять как новинку?
Я к тому, что должно быть пространство для маневров.
И безапелляционно считать created_at точкой отсчёта - неправильно.
а можно сделать так, чтобы при добавлении товар становился автоматически новым на какое-то время (которое я укажу), а после окончания времени с него снималась метка.
А может быть они хотят нокией торговать?
Но может менеджеры не хотят этот древний товар выставлять как новинку?
Тогда я даю манагерам возможность поменять дату добавления товара - и бац, о чудо - товар не будет появляться как новинка. Можно даже это реализовать как галку - отжал нажал - и дата добавления товара меняется +- нужное количество дней. Не надо умножать сущности сверх необходимого - пока у нас хватает полей для реализации пользуемся.
Дмитрий, ок. сегодня это подойдет. А завтра, пиздец, но так бывает, понадобится использовать поле created_at, невероятно, но понадобится поле updated_at...
Сущности множить не надо, но их не надо множить без необходимости. Хотя я бы тут добавил "без необходимости с оглядкой на перспективу".
Сегодня можно и штатными полями обойтись. А послезавтра придется перепиливать половину приложения, потому что зажали завести лишнее (как казалось, ненужное) поле в таблице.
А послезавтра придется перепиливать половину приложения, потому что зажали завести лишнее (как казалось, ненужное) поле в таблице.
Вы и так его перепилите. Про преждевременную оптимизацию читали?
А завтра, пиздец, но так бывает, понадобится использовать поле created_at, невероятно, но понадобится поле updated_at...
А давайте пока еще на сегодня посмотрим - окей добавляем вашу галку. базу берем самую распространенную - MySQL 5.7. Каков будет запрос к бд что бы вывести сначала новинки, потом остальные с вашей галкой?
Если же на товар больше всего человек заходило, то он становился рекомендованным или топовым,
на первый взгляд можно просто добавить счетчик просмотров и при достижении порогового значения товар будет вылетать в топчик. Однако разумнее определять топ по просмотрам за определенный период. Тут уже нужно не просто счетчик хранить, а каждый просмотр с датой, и делать выборку по количеству просмотров к примеру за последнюю неделю.