Тогда я не совсем понимаю в чём проблема? Занесите значение цен для зон в базу данных, и отслеживайте клик по зоне - там будет информация о том на какой зоне кликнули.
WorldEn: Вот Вы сами и ответили на свой вопрос. У нас в городе крупнейшия сеть из 10 точек сократилась до 3-х. Живут только за счёт печати на сувенирах и майках.
Один и тот же скрипт использует несколько клиентов, какая именно база данных используется - определяется через субдомен. Список субдоменов и их баз данных хранится в служебной базе данных. Как бы Вы решали такую задачу?
Задача именно заставить нормально работать ORM. Проблема в том, что в классе
Doctrine\DBAL\Connection свойство _params объявлено приватным, потому невозможно просто расширить класс и внести методы для изменения.
На данный момент, получилось это сделать через ReflectionObject (всё работает и нормльно) - но это как-то по варварски. Хотелось бы более изящного решения.
Помоему, тут решение для ограниченного набора соединений? Тоесть только то, что прописано в конфигурационном файле. А для ситуации, когда данные по соединению приходят в момент выполнения - там нет решения. Или я что-то пропустил?
mamayama:
Разумеется один сервер держит несколько тысяч пользователей, но это результат кеширования.
Данные в системе постоянно меняются, то, что возможно - уже закешировано. Остальное требует максимально возможной актуальности данных.
Что значит "вы отдаете клиенту данные из большого каталога непосредственно из CRM" - В CRM работают сотрудники, клиенты не имеют доступа ни к каталогу, ни к системе. Данные поставщиков и магазинов приходят чере REST интерфейсы. Связь с внешними системами тоже через API.
mamayama: Вы же в курсе, что у них не единственный сервер? про кеширование, наверное, тоже знаете? И наверняка знаете чем, в плане политики кеширования, отличается CRM и социальная сеть?
К тому же в facebook не случайно разработали HHVM.
В любом случае при постраении графа из реляционной базы данных требуется ЛИБО извлекать сразу большое количество данных и их обрабатывать ЛИБО делать большое количество запросов. Первый вариант - быстрый но затратный по ресурсам, второй - наоборот.
Эта система кроме того, ведёт складской учёт, продажи, закупки, подсчёт статистики и генерация отчётности (временами довольно замысловатой). В работе используется почти всё, что есть в базе. (средней размер базы данных 75gb). Запихивать всё это в память - нереально.
значительная часть запчастей идентична - нет. они взаимозаменяемы но не одинаковы.
mamayama: Вы опять путаете нагрузку по каличеству запросов и 1 запрос на на серьёзную обработку данных.
Скажем на построение полного графа аналогов какой либо запчасти от всех, известных системе, поизводителей и поставщиков. Чтобы было понятно: 740 миллинов наименований запчастей, 4000 поставщиков, есть список оффициальных и неоффициальных (по конкретному поставщику) замен, каждая запчасть может быть связана с другими через 5-6 промежуточных звеньев. Общее количество аналогов в 1 графе - от 3 до 500.
Для решения подобной задачи, нужно много времени, но не очень много ресурсов. Однако на время её выполнения замедлится работа всей системы.
Видимо, я недостаточно корректно выразился - естественно речь идёт о подсчёте данных, которые будут сохранены. Я имел в виду, что на стороне клиента - это только представление для удбства. данные для сохранения пересчитываются на сервере.
Стоит отметить, что вопрос не относится к реальному проекту, а скорее теоритический,
потому, можно взять любую несовпадающую конструкцию. Скажем решение квадратного уравнения
