SS
есть ж массив changes у модели
там два основных метода у модели для проверки ее изменений isDirty и wasChanged
одно работает до сохранения второе после насколько я помню
Size: a a a
2020 September 18
NE
там два основных метода у модели для проверки ее изменений isDirty и wasChanged
одно работает до сохранения второе после насколько я помню
одно работает до сохранения второе после насколько я помню
спасибо
NE
есть ж массив changes у модели
спасибо
SS
Назрел вопрос по базам...
Есть стандартный проект на L7+php74-fpm+mysql.
Сейчас встала задача собирать много статистики (просмотры товаров, брошенные корзины, etc.). Предполагаю, на данном этапе до 100-150к записей в сутки, дальше может быть больше.
Какую лучше взять СУБД для этой статы? Желательно чтобы primary key был UUID из коробки.
И вообще, насколько это правильно, юзать 2 разных СУБД в проекте?
Т.е., получается, пишем стату в условный postgres, при построении отчета сначала выбираем из него необходимые идентификаторы, а потом с этими идентификаторами уже стучимся в mysql.
Нормально ли так делать? Или лучше все хранить в одной mysql?
Есть стандартный проект на L7+php74-fpm+mysql.
Сейчас встала задача собирать много статистики (просмотры товаров, брошенные корзины, etc.). Предполагаю, на данном этапе до 100-150к записей в сутки, дальше может быть больше.
Какую лучше взять СУБД для этой статы? Желательно чтобы primary key был UUID из коробки.
И вообще, насколько это правильно, юзать 2 разных СУБД в проекте?
Т.е., получается, пишем стату в условный postgres, при построении отчета сначала выбираем из него необходимые идентификаторы, а потом с этими идентификаторами уже стучимся в mysql.
Нормально ли так делать? Или лучше все хранить в одной mysql?
VY
Назрел вопрос по базам...
Есть стандартный проект на L7+php74-fpm+mysql.
Сейчас встала задача собирать много статистики (просмотры товаров, брошенные корзины, etc.). Предполагаю, на данном этапе до 100-150к записей в сутки, дальше может быть больше.
Какую лучше взять СУБД для этой статы? Желательно чтобы primary key был UUID из коробки.
И вообще, насколько это правильно, юзать 2 разных СУБД в проекте?
Т.е., получается, пишем стату в условный postgres, при построении отчета сначала выбираем из него необходимые идентификаторы, а потом с этими идентификаторами уже стучимся в mysql.
Нормально ли так делать? Или лучше все хранить в одной mysql?
Есть стандартный проект на L7+php74-fpm+mysql.
Сейчас встала задача собирать много статистики (просмотры товаров, брошенные корзины, etc.). Предполагаю, на данном этапе до 100-150к записей в сутки, дальше может быть больше.
Какую лучше взять СУБД для этой статы? Желательно чтобы primary key был UUID из коробки.
И вообще, насколько это правильно, юзать 2 разных СУБД в проекте?
Т.е., получается, пишем стату в условный postgres, при построении отчета сначала выбираем из него необходимые идентификаторы, а потом с этими идентификаторами уже стучимся в mysql.
Нормально ли так делать? Или лучше все хранить в одной mysql?
google tag manager
DM
Назрел вопрос по базам...
Есть стандартный проект на L7+php74-fpm+mysql.
Сейчас встала задача собирать много статистики (просмотры товаров, брошенные корзины, etc.). Предполагаю, на данном этапе до 100-150к записей в сутки, дальше может быть больше.
Какую лучше взять СУБД для этой статы? Желательно чтобы primary key был UUID из коробки.
И вообще, насколько это правильно, юзать 2 разных СУБД в проекте?
Т.е., получается, пишем стату в условный postgres, при построении отчета сначала выбираем из него необходимые идентификаторы, а потом с этими идентификаторами уже стучимся в mysql.
Нормально ли так делать? Или лучше все хранить в одной mysql?
Есть стандартный проект на L7+php74-fpm+mysql.
Сейчас встала задача собирать много статистики (просмотры товаров, брошенные корзины, etc.). Предполагаю, на данном этапе до 100-150к записей в сутки, дальше может быть больше.
Какую лучше взять СУБД для этой статы? Желательно чтобы primary key был UUID из коробки.
И вообще, насколько это правильно, юзать 2 разных СУБД в проекте?
Т.е., получается, пишем стату в условный postgres, при построении отчета сначала выбираем из него необходимые идентификаторы, а потом с этими идентификаторами уже стучимся в mysql.
Нормально ли так делать? Или лучше все хранить в одной mysql?
я бы вообще не хранил стату в реляционной БД, по крайней мере не собирал бы статистику по активным таблицам. После завершения покупки скидывал бы статистику в отдельные таблицы без внешних ключей и прочего, читай - логировал бы
SS
google tag manager
заказчику сие не объяснить🌚хочет свою реализацию
ZZ
Добрый день, подскажите что не так пишу 😅😅😅😅😅
ZZ
SS
я бы вообще не хранил стату в реляционной БД, по крайней мере не собирал бы статистику по активным таблицам. После завершения покупки скидывал бы статистику в отдельные таблицы без внешних ключей и прочего, читай - логировал бы
так мне не по таблицам, а например, зашел пользователь на страницу товара - в БД упала строка с его ID, IP, user agent, id товара и датой/временем. И дальше отчеты типа "сколько раз этот пользователь смотрел этот товар" и т.д.
D
Назрел вопрос по базам...
Есть стандартный проект на L7+php74-fpm+mysql.
Сейчас встала задача собирать много статистики (просмотры товаров, брошенные корзины, etc.). Предполагаю, на данном этапе до 100-150к записей в сутки, дальше может быть больше.
Какую лучше взять СУБД для этой статы? Желательно чтобы primary key был UUID из коробки.
И вообще, насколько это правильно, юзать 2 разных СУБД в проекте?
Т.е., получается, пишем стату в условный postgres, при построении отчета сначала выбираем из него необходимые идентификаторы, а потом с этими идентификаторами уже стучимся в mysql.
Нормально ли так делать? Или лучше все хранить в одной mysql?
Есть стандартный проект на L7+php74-fpm+mysql.
Сейчас встала задача собирать много статистики (просмотры товаров, брошенные корзины, etc.). Предполагаю, на данном этапе до 100-150к записей в сутки, дальше может быть больше.
Какую лучше взять СУБД для этой статы? Желательно чтобы primary key был UUID из коробки.
И вообще, насколько это правильно, юзать 2 разных СУБД в проекте?
Т.е., получается, пишем стату в условный postgres, при построении отчета сначала выбираем из него необходимые идентификаторы, а потом с этими идентификаторами уже стучимся в mysql.
Нормально ли так делать? Или лучше все хранить в одной mysql?
self hosted matomo
SS
100 раз обновил страницу - упало 100 записей и т.д.🌚поэтому может быть достаточно много
SC
self hosted matomo
Тю, piwik
D
Тю, piwik
)
DM
А. т.е. нужна статистика запросов страниц, а не история заказов
D
100 раз обновил страницу - упало 100 записей и т.д.🌚поэтому может быть достаточно много
мне кажется для любой нормальной субд это мелочь
DM
clickhouse мб?
D
clickhouse мб?
оверхед же пиздец какой