andrey_anonymousборщ бруевичНиакого влияния город услуги или город, где контрагент в данный момент находится не несёт.
Как продать пиццу Москвичу в Питере?клинический случай

andrey_anonymousборщ бруевичНиакого влияния город услуги или город, где контрагент в данный момент находится не несёт.
Как продать пиццу Москвичу в Питере?Смотрим город регистрации контрагента (Москва), кладем на сервер М, чтобы далее упомянутый выше app server для репортинга имел все необходимые ему данные для отчётов по городу М только на сервере М.

andrey_anonymousборщ бруевич как они там задизайнили
Простите, а с какого места мы переключились с обсуждения "москвичи на сервер А" на "как задизайнили в ebay"?
Я что-то пропустил?
...да и техничкин что-то притих - лулзы, должно быть, собирает :)Мы и не переключались. Твои вопросы говорят о тотальном непонимании сути шардинга и области применения. Тебе в ответ добрые люди пытаются объяснить на примерах ebay и других.

Техничкин поясняетборщ бруевичпропущено...
клинический случай

Возможно его внутренне плющит тот факт, что на "питерском" сервере не будет данных о "московском" клиенте.
Т.е. client_id будет, а записи в clients - нет.

Такой себе foreign key головного мозгаДа не, всё проще. Он пытается понять как потом делать отчет по продажам в питере на сервере П и не увидим ведь продажу москвичу, она ведь на сервере М.
Андрей, если отчеты и бизнес-логика продаж логически разделены городом продажи, то шардинг буду делать на основе города продажи.

andrey_anonymousборщ бруевичпропущено...
Смотрим город регистрации контрагента (Москва), кладем на сервер М, чтобы далее упомянутый выше app server для репортинга имел все необходимые ему данные для отчётов по городу М только на сервере М.
Минуточку.
У нас вроде как есть сущности:
- услуга
- клиент
Каждая предположительно имеет привязку к серверу.
Сервера разные.
Из процитированного не совсем понятно, что куда "кладём".
Кроме того, до репортинга мы еще не дошли - нам бы для начала пиццу продать, денежку получить, а уж потом - отчитываться.Ты не с той стороны на это смотришь.
Всё спрашиваешь как мы твою модель данных на наш пример шардинга натягивать будем. А мы и не будем.
Сначала ты придумываешь модель, далее смотришь как это всё можно разделить на N серверов, чтобы обработку данных (для данного конкретного бизнеса, а не всех возможных) можно было проводить на одном сервере, не обращаясь к другим.

В твоем примере наиболее близкий признак такого разделения - город продажи.
На крайняк можно синтетическое поле сделать.

Чего далеко ходить - любая филиальная сеть какого-нибудь банка Б сам по себе шардинг. Работают каждый в своей базе и не жужжат. И только ограниченное число управленческих отчетов потребует данных из всех филиалов.

andrey_anonymousдуалотехничкино чем ты? шардинг явно требует редизайн приложения
Общие слова.
Бизнес-требования озвучены.
Каков правильный шардо-дизайн?Это не требования, а чепуха.
Контрагентов можно на отдельный сервер вывести, а данные продаж - шардировать на несколько по городу продажи.

Соломон Кацandrey_anonymousпропущено...

Общие слова.
Бизнес-требования озвучены.
Каков правильный шардо-дизайн?

Не мучай человека, он не шарит.он не шарДит