Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
MDX - Первый непустой мембер
|
|||
|---|---|---|---|
|
#18+
Нужно найти первый непустой мембер. Вот что родил пока Код: plaintext ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.08.2004, 01:11 |
|
||
|
MDX - Первый непустой мембер
|
|||
|---|---|---|---|
|
#18+
Для foodmart 2000 : Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. Не понял только - почему tail - то у тебя? Нужно найти первый или последний? В чем смысл большей производительности? Если нужно именно по времени, то, имхо, тут оптимизация почти ничего не даст, т.к., например, за 10 лет у тебя во времени будет всего навсего 365*10=3650 дней. Думаю не сильно трудно будет серверу взять из них непустые, а потом первый из них. Другое дело - если время является только примером, а реальное измерение, по которому нужно проделать такую операцию, гораздо больше. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.08.2004, 19:13 |
|
||
|
MDX - Первый непустой мембер
|
|||
|---|---|---|---|
|
#18+
А вот так будет быстрее, как мне кажется, для измерения с большим числом членов и грамотно разбытого на уровни (пример для foodmart 2000, уровней в измерении времени всего три): Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.08.2004, 19:21 |
|
||
|
MDX - Первый непустой мембер
|
|||
|---|---|---|---|
|
#18+
Сорри, опечатался... мне нужен первый с конца :) а 3650 членов не так уж и мало, если учесть что это мне нужно применить в custom rollup формуле, затем на ее основе будет считаться calculated member, а на его основе еще один CM. Причем анализ будет производится в разрезе периодов (месяцев и даже дней). Объясню задачу подробнее: анализ дебиторской задолженности. Измерения: Дата, Контрагент, Подразделение, Вид деятельности, Валюта ну и еще там неважно... Меры (физические): оборот товаров за день (ТОВАРЫ), оборот платежей (ПЛАТЕЖИ) за день, сальдо на этот день. (для тех, кто не знаком с термином сальдо - это остаток, сколько клиент нам должен). Запись в таблице присутствует не на каждый день, а только при изменении сальдо. Нужно получить: оборот товаров за период, оборот платежей, сальдо на начало периода (любого), сальдо на конец, среднее за период ( Avg([Дата].CurrentMember.Children,Measures.[КонСальдо]) ), макс. за период. Это для начала :( - потом добавится еще то-же с просроченным долгом Короче на фактах в кол-ве 100 тыс. наблюдаются приличные тормоза, да и задача еще не решена... Неужели придется впихивать в хранилище комбинации ВСЕХ измерений на каждый день ? Это ж фигня какая-то получится, фактов неск. миллионов станет, да и выгрузка просядет... кто как делает такие задачи ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.08.2004, 22:24 |
|
||
|
MDX - Первый непустой мембер
|
|||
|---|---|---|---|
|
#18+
Если с конца, то да, надо head заменить на tail. Лично я подобную задачу решал для организации инкрементального обновления куба (именно про это мне и говорили, что проще бы было организовать на строне хранилища). Что касается оптимальности - первый непустой мембер по измерению должен находится один раз ведь всего? А сальдо чему равен? Платежи - Товары ? Или он появляется откуда-то еще? Оборот - это сумма определенной меры за период? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.08.2004, 16:37 |
|
||
|
MDX - Первый непустой мембер
|
|||
|---|---|---|---|
|
#18+
uraСорри, опечатался... мне нужен первый с конца :) а 3650 членов не так уж и мало, если учесть что это мне нужно применить в custom rollup формуле, затем на ее основе будет считаться calculated member, а на его основе еще один CM. Причем анализ будет производится в разрезе периодов (месяцев и даже дней). Объясню задачу подробнее: анализ дебиторской задолженности. Измерения: Дата, Контрагент, Подразделение, Вид деятельности, Валюта ну и еще там неважно... Меры (физические): оборот товаров за день (ТОВАРЫ), оборот платежей (ПЛАТЕЖИ) за день, сальдо на этот день. (для тех, кто не знаком с термином сальдо - это остаток, сколько клиент нам должен). Запись в таблице присутствует не на каждый день, а только при изменении сальдо. Нужно получить: оборот товаров за период, оборот платежей, сальдо на начало периода (любого), сальдо на конец, среднее за период ( Avg([Дата].CurrentMember.Children,Measures.[КонСальдо]) ), макс. за период. Это для начала :( - потом добавится еще то-же с просроченным долгом Короче на фактах в кол-ве 100 тыс. наблюдаются приличные тормоза, да и задача еще не решена... Неужели придется впихивать в хранилище комбинации ВСЕХ измерений на каждый день ? Это ж фигня какая-то получится, фактов неск. миллионов станет, да и выгрузка просядет... кто как делает такие задачи ? Парочка вопросов 1. Как устроена таблица фактов, что является ее грануляроностью? 2. Если гранулярность элементарные транзакции, то используются ли snapshot? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.08.2004, 21:21 |
|
||
|
MDX - Первый непустой мембер
|
|||
|---|---|---|---|
|
#18+
2 backfire нет, не отдельная транзакция, а скорее сумма всех отдельных транзакций с группировкой по всем измерениям за день. Вот поля таблицы фактов: Дата datetime - ну это понятно Контрагент int - ссылка на справочник контрагентов ... другие ссылки/измерения Товары - money - на какую сумму клиент взял товара за этот день Платежи - money - сколько денег заплатил клиент за этот день Сальдо - сколько клиент должен на этот день с учетом товаров и денег за этот день = образно Sum(Дата.FirstChild:Дата.Сегодня, Товары-Платежи) Последнее поле можно и не вводить, а считать в olape, но так тормоза еще больше. Если за какой-то день контрагент ничего не брал и не платил, то соответствующей записи в таблице не будет , т.е. будут дырки в фактах, которые нужно заполнять, находя показатель из предыдущего периода. Вопрос: Можно ли при такой схеме реализовать анализ дебиторской задолженности (показатели см. выше) в MS AS (клиент OWC) и если можно, то реализовывал ли это кто-то на практике. Или лучше пойти другим путем ? Тогда каким ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.08.2004, 13:54 |
|
||
|
|

start [/forum/topic.php?fid=49&msg=32670055&tid=1872304]: |
0ms |
get settings: |
5ms |
get forum list: |
8ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
28ms |
get topic data: |
5ms |
get forum data: |
1ms |
get page messages: |
24ms |
get tp. blocked users: |
1ms |
| others: | 212ms |
| total: | 288ms |

| 0 / 0 |
