Relic HunterИнтернет-магазину оно нафик не сдалось.
Интернет магазину - возможно, а владельцу крупного магазина не помешает. Почему Вы считаете, что статистика в любом ее проявлении - зло?
Relic HunterА для аналитики грузите ежедневные снимки в DWH. Будут им и графики и диаграммы Гауса.
Более того, потребуются кубы - перельем через ETL. Речь о том, что анализироваться будут различного вида документы с различной логикой ценообразования в Вашем случае. Это накладно и трудно поддерживаемо. Я же предлагаю отвязать логику ценообразования, скидок, бонусов и иже об различного вида операций (бизнес-документов - накладных, счетов, проводок, ...). Анализировать и поддерживать такое хозяйство намного проще, быстрее и надежнее. Все в одном месте.

Relic HunterМСУ,

Если-бы было по-вашему, вся-бы онлайн-торговля загнулась под тяжестью своих-же данных. И люди-бы состарились в очередях. Там, где нужня скорость обработки заказа - никаких лишних данных. Кому (покупателю) интересна цена товара, которая была час назад? То время ушло. А аналитик может и подождать и час и два, пока там кубы обрабатываются.
Тут дело не только в том, какая цена была вчера, я говорю вообще про орагнизацию хранилища для подобного бизнеса (это не только интернет магазины). Речь о том, что схема с отвязанными ценами - легко расширяема.

Relic HunterГлавное - продать товар и с максимальной скоростью. Анализировать будем потом, если будет "что". А забивать/замедлять онлайн-процессинг аналитикой это - самим себе ставить палки в колеса.
Еще раз, я говорю не только об аналитике. Речь о гибком инструменте манипулирования ценами, скидками, бонусами в разрезе оперируемых товаров. Прикрутить то или иное правило - без проблем. На общий процессинг подобная универсальная схема сильно не повлияет. Аналитика - дело вторичное.

GerrosСделайте отложенное обновление количества и цены на сервере.
Зачем?

GerrosПри изменении цены это изменение кэшируется на веб-сервере.
Зачем тут вообще кеш? У нас есть полноценная СУБД, с индексами и прочими плюшками. Нужно просто научится правильно работать с БД.

GerrosРаз в минуту веб сервер отправляет на сервер БД один апдейт сразу по всем изменившимся ценам.
Ужос...

GerrosТекущее количество каждого товара - тоже одним апдейтом раз в 10 минут. Джобом на сервере БД, например.
Ужос в квадрате...

GerrosА при добавлении товара в корзину - пересчёт текущего количества по конкретному товару на лету.
Зачем? Добавление товара в корзину ровным счетом ничего не означает. Следовательно и пересчеты никакие не нужны. Пересчет товара на складе - после фактической оплаты. Причем пересчет не отложенный, а по факту.

GerrosВместо непрерывного потока апдейтов будет один-два апдейта в минуту. Нагрузка на БД упадёт и сможете спокойно читать напрямую из неё безо всяких клиентских кэшей.
Нужно автору с индексами сначала разобраться.

rudevelopБудем смотреть в сторону индексов и оптимизации UI.
Только так и никак иначе.
ShSergeнанять за хорошие денюжки бизайнера баз данных
Всё верно, тюнинг хранилища не помешал бы.