Именно так. Но правда в том, что у тебя не будет ни 100 тыщ пользователей, ни 100 тыщ событий. И не всем пользователям нужны все события.

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

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

Под чем собираешь?

Тулчейн какой?

Под чем собираешь?

под виндой

Тулчейн какой?

да тут свой какой то от техаса

Хм

Хмхм

** Build Finished **

под виндой

А что, так тоже можно?

поубивавбы

А что, так тоже можно?

а че нет? хоть под ведроидом собирай

Хз. У меня все stb-шные проекты под бубунту

Хз. У меня все stb-шные проекты под бубунту

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

тулчейну то какая разница под чем работать. код то на выходе вообще для другого процесора

щас бум курить мануал с регистрами куда там их втыкивать

Да понятно. Я тоже однажды по незнанию запустил проект под виндой. Хотя он под винду и не был предназначен :)

Потом когда доку открыл - сам офигел

Здрасти. Допустим у меня есть модель сообщения для чата в базе данных. На это сообщение можно ставить лайки, этих лайков предвидится много. Частым запросом в БД будет получение сообщения вместе с количеством лайков. Стоит ли оптимизировать работу базы данных за счет создания поля с кэшируемым количеством лайков? При создании лайка это поле будет инкрементироваться а при удалении декрементироваться.

Если нет то бывают ли вообще таки случаи когда очень хорошей оптимизацией было бы кэширование какой то инфы в поле модели?

Данные в бд перстистентны, если это не in memory, о каком ты кеше, парень?

Данные в бд перстистентны, если это не in memory, о каком ты кеше, парень?

в случае примера с сообщениями допустим были две модели: Сообщение с полями: текст, автор Лайк с связью на сообщение и автором Стоит ли добавить в модель Сообщения поле “кэшированное количество лайков” и манипулировать его в зависимости от операций создания или удаления лайка?

для оптимизации

Если тебе не нужно знать кто лайкал - колонка с каунтером идеальный вариант

Если тебе не нужно знать кто лайкал - колонка с каунтером идеальный вариант

спасибо, а то я боялся что изобретаю велосипед и типо современные бд и так кэшируют такие вещи

Единственное я бы наверное нормализовал, и отделил бы мессаджи от свойств

Единственное я бы наверное нормализовал, и отделил бы мессаджи от свойств

Можно поподробнее, от каких свойств?

лайки, дизлайки, прочий мусор

лайки, дизлайки, прочий мусор

отдельную модель лучше для этого сделать?

если свойств более чем одно, или возможно, что их станет больше чем одно, стоит вынести возможно даже сделать entity-attribute-value, что это такое можешь поинтересоваться в гугле

если свойств более чем одно, или возможно, что их станет больше чем одно, стоит вынести возможно даже сделать entity-attribute-value, что это такое можешь поинтересоваться в гугле

хорошо, спасибо за советы

спасибо, а то я боялся что изобретаю велосипед и типо современные бд и так кэшируют такие вещи

Это не кэширование, это либо денормализация, либо вообще просто решения при проектировании структуры БД.

если свойств более чем одно, или возможно, что их станет больше чем одно, стоит вынести возможно даже сделать entity-attribute-value, что это такое можешь поинтересоваться в гугле

Не понятно, с какого перепуга ты так решил. Если свойства надо добавлять пользователю в процессе эксплуатации, без модификации БД, то да, без EAV никак. Но если такой задачи не стоит (а видимо это именно так), то ни EAV, ни выделение свойств в отдельную таблицу не нужны

Доброго вечера! Ребят вопрос написал на форуме. Не посмотрите?