Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Подскажите оптимальную формулу
|
|||
|---|---|---|---|
|
#18+
Доброго времени суток всем. Подскажите пожалуйста как преобразовать формулу CM для расчета остатка долга с учетом второго измерения дата - дата долга. sum(Ascendants([Даты].CurrentMember), sum([Даты].FirstSibling :[Даты].CurrentMember.PrevMember,[Measures].[Output]-[Measures].[Input]))+([Measures].[Output]-[Measures].[Input])) Нужно в кубе по расчетам с контрагентами как то разделить погашения долгов и сами долги на категории до 10 дней, до 30, свыше 60-ти. Как мне кажется такие задачи есть почти у каждого. В таблице фактов я сделал поле дата долга и срок. Для выставления долга срок всегда 1. Для оплат он вычисляется исходя из даты оплаты и даты долга. В кубике для погашений все показывается нормально. Долг естествено показывается криво. По идее нужно как то сопоставить текущую дату, и выкинуть все значения в измерении дата долга от эелемента такого же как в дате но - 10,30 или 60 дней. Вопрос в том как это сделать наиболее оптимально, без лишних тормазов на клиенте или сервере. Делать фактическую табличку с остатками на каждую дату не желательно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.10.2004, 09:20 |
|
||
|
Подскажите оптимальную формулу
|
|||
|---|---|---|---|
|
#18+
не ужели никто из читающих не сталкивался с такими проблемами? По поиску я видел что господин Иванов когда то похожую тему поднимал но ответа я так и не увидел. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.10.2004, 17:36 |
|
||
|
Подскажите оптимальную формулу
|
|||
|---|---|---|---|
|
#18+
Ya bi radelil na 2 tablici factov, sootv 2 fizicheskih kuba dolgi i pogasheniya dolgov ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.10.2004, 19:19 |
|
||
|
Подскажите оптимальную формулу
|
|||
|---|---|---|---|
|
#18+
Как вариант: -сделать view где будет каждый день с остатком долга (для кадого клиента) = 365 * n-лет истроии * m-кастомеров -сделать измерение для backet -- 30 дней, 60 дней и т.д. -строить отдельный кубик поверх view ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.10.2004, 04:14 |
|
||
|
Подскажите оптимальную формулу
|
|||
|---|---|---|---|
|
#18+
С фактической табличкой или вьюхой получается, но табличка будет очень большая, кроме кастомеров, дней и срока в кубике еще есть измерения товар, в котором 2,500 листьев. Конечно не у каждого клиента они все есть, но тем не менее запрос отрабатывает слишком долго. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.10.2004, 11:22 |
|
||
|
Подскажите оптимальную формулу
|
|||
|---|---|---|---|
|
#18+
А не проще ли хранить долг не на каждый день, а только на дату его изменения. При этом у вас не будет раздутия таблицы фактов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.10.2004, 15:33 |
|
||
|
Подскажите оптимальную формулу
|
|||
|---|---|---|---|
|
#18+
backfireА не проще ли хранить долг не на каждый день, а только на дату его изменения. При этом у вас не будет раздутия таблицы фактов. Хорошо попробую построить такую табличку. Есть сомнения по поводу перехода долга из одной категории в другую. Ведь непогашеный долг со временем стает все более и более старым. А варианта с MDX ни у кого нет? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.10.2004, 16:18 |
|
||
|
Подскажите оптимальную формулу
|
|||
|---|---|---|---|
|
#18+
У меня готового нет, но думаю что шариками вам самому покрутить получиться. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.10.2004, 01:41 |
|
||
|
Подскажите оптимальную формулу
|
|||
|---|---|---|---|
|
#18+
Евгений КрасновС фактической табличкой или вьюхой получается, но табличка будет очень большая, кроме кастомеров, дней и срока в кубике еще есть измерения товар, в котором 2,500 листьев. Конечно не у каждого клиента они все есть, но тем не менее запрос отрабатывает слишком долго. Тогда храните (или view) только на даты изменения и перехода между buckets. При таком подходе правда ваш calculated member должен будет искать последнее непустое значение. Я не знаю что будет эффективнее -- бОльший объем или calculated member с поиском not empty. Ну и при изменении bucket будет больше работы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.10.2004, 11:02 |
|
||
|
|

start [/forum/topic.php?fid=49&msg=32721109&tid=1872203]: |
0ms |
get settings: |
8ms |
get forum list: |
10ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
48ms |
get topic data: |
7ms |
get forum data: |
2ms |
get page messages: |
32ms |
get tp. blocked users: |
1ms |
| others: | 259ms |
| total: | 371ms |

| 0 / 0 |
