Здравствуйте, elmal, Вы писали:

E>Семантика может быть любой.
План запроса может оказываться разным, в зависимости от желаемой семантики.

E>Если к одной накладной привязано много городов, это может означать что затраты накладной нужно разносить на разные города.
В зависимости от того, как именно разносить, мы строим конкретные агрегатные функции, и применяем различные порядки группировок/джойнов.

В оригинальном примере — одной накладной соответствует много (ну не совсем много, а порядка 10 максимум) услуг и много событий (тоже порядка 10 максимум), связанной с накладной. И нужно сгруппировать накладные по конкретным услугам, каждой услуге может быть привязана доля затрат, которая в сумме сходится к 1, и эту сумму после группировки нужно умножить на затраты на 1 накладную.
Ну вот в исходном примере этого нет, из-за этого непонятно, что можно оптимизировать.
Крайне желательно показать пример данных. Раз у нас везде "многие к одному" — давайте начнём с ровно одной накладной. Заполним списки услуг и событий для неё, и покажем, какой выхлоп ожидается при выполнении этого запроса.

E>Или пример — накладная эта кассовый ордер. В чеке пришло 100 рублей прибыли. У меня 10 работников — уброщицы, кассир, грузчик и т.д. С ними договорились, что им не будут платить зарплату а они будут получать определенный процент от прибыли. И я хочу в запросе получить информацию сколько мне заплатить уборщицу и грузчику, если их доля в прибыли 5 процентов. Одновременно у меня куча разных услуг, и у них тоже доли уже в собестоимости. И я, как дворник, хочу поинтересоваться, как изменилась бы моя зарплата в проглом месяце если бы мы смогли перестроить услуги. И такое может хотеть уборщица, кассир, менеджер, топ менеджер и т.д.
Ну, пока понятно, что ничего не понятно
Нужен наглядный пример. Потому что без него и так понятно, что нужно просто умножить прибыль чека на 0.05 чтобы получить "сколько мне заплатить уборщице и грузчику", безо всякой агрегации.

Здравствуйте, elmal, Вы писали:

E>Семантика может быть любой.
План запроса может оказываться разным, в зависимости от желаемой семантики.

E>Если к одной накладной привязано много городов, это может означать что затраты накладной нужно разносить на разные города.
В зависимости от того, как именно разносить, мы строим конкретные агрегатные функции, и применяем различные порядки группировок/джойнов.

E>В оригинальном примере — одной накладной соответствует много (ну не совсем много, а порядка 10 максимум) услуг и много событий (тоже порядка 10 максимум), связанной с накладной. И нужно сгруппировать накладные по конкретным услугам, каждой услуге может быть привязана доля затрат, которая в сумме сходится к 1, и эту сумму после группировки нужно умножить на затраты на 1 накладную.
Ну вот в исходном примере этого нет, из-за этого непонятно, что можно оптимизировать.
Крайне желательно показать пример данных. Раз у нас везде "многие к одному" — давайте начнём с ровно одной накладной. Заполним списки услуг и событий для неё, и покажем, какой выхлоп ожидается при выполнении этого запроса.

E>Или пример — накладная эта кассовый ордер. В чеке пришло 100 рублей прибыли. У меня 10 работников — уброщицы, кассир, грузчик и т.д. С ними договорились, что им не будут платить зарплату а они будут получать определенный процент от прибыли. И я хочу в запросе получить информацию сколько мне заплатить уборщицу и грузчику, если их доля в прибыли 5 процентов. Одновременно у меня куча разных услуг, и у них тоже доли уже в собестоимости. И я, как дворник, хочу поинтересоваться, как изменилась бы моя зарплата в проглом месяце если бы мы смогли перестроить услуги. И такое может хотеть уборщица, кассир, менеджер, топ менеджер и т.д.
Ну, пока понятно, что ничего не понятно
Нужен наглядный пример. Потому что без него и так понятно, что нужно просто умножить прибыль чека на 0.05 чтобы получить "сколько мне заплатить уборщице и грузчику", безо всякой агрегации.