Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Помогите с MDX, плиз
|
|||
|---|---|---|---|
|
#18+
Смысл таков: существует таблица "Tovar", в которой помимо наименования и ID есть масса единицы товара. В таблице фактов есть остаток этого товара на складе, а точнее движения. Таким образом, остаток я считаю через PeriodsToDate. Можно ли, не добавляя в таблицу фактов массу штуки умноженную на количество, взять остаток из fact table и умножить на массу штуки из таблицы измерения, чтобы получить массу товаров на складе? Проблема в том, что измерение "Товар" - иерархическое. Не могу никак формулу для calculated member написать. Помогите, пожалуйста. Заранее благодарен. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.09.2004, 11:44 |
|
||
|
Помогите с MDX, плиз
|
|||
|---|---|---|---|
|
#18+
Можно ли, не добавляя в таблицу фактов массу штуки умноженную на количество, взять остаток из fact table и умножить на массу штуки из таблицы измерения В принципе наверное возможно, но получится наверняка ужасно медленно. Я делал так что строил куб на View, а во View join c таблицей измерения, что бы мера получилась физическая а не Calculated. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.09.2004, 14:14 |
|
||
|
Помогите с MDX, плиз
|
|||
|---|---|---|---|
|
#18+
Сделать можно. Работать будет с притормаживанием, потому как остаток на складе у тебя это не факт, а CM, в рез-те чего просчет перечня позиий, имеющихся на остатках, будет происходить для всего ассортимента номенклатуры, и те которые есть на остатках будут учитываться в весе. Вот если бы остаток был реальным фактом, тогда перечень номенклатуры на остатках вычислялся бы быстрее и весь CM посчитался бы быстрее. А как реализовать - посмотрим функции Descendants, Sum, функции работы со свойствами измерений. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.09.2004, 14:25 |
|
||
|
Помогите с MDX, плиз
|
|||
|---|---|---|---|
|
#18+
Ага... Спасибо за ответы. Сейчас попробую. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.09.2004, 15:08 |
|
||
|
Помогите с MDX, плиз
|
|||
|---|---|---|---|
|
#18+
ВжикСделать можно. Работать будет с притормаживанием, потому как остаток на складе у тебя это не факт, а CM, в рез-те чего просчет перечня позиий, имеющихся на остатках, будет происходить для всего ассортимента номенклатуры, и те которые есть на остатках будут учитываться в весе. Вот если бы остаток был реальным фактом, тогда перечень номенклатуры на остатках вычислялся бы быстрее и весь CM посчитался бы быстрее. А как реализовать - посмотрим функции Descendants, Sum, функции работы со свойствами измерений. даже если у вас остаток в штуках будет физической мерой, все равно определение весового остатка будет вынуждать нас спускаться по иерархии до самых листьев и суммироать on-the-fly по descendants. все прелесть хранения предрассчитанных аггрегатов летит в трубу. Хорошо если номенклатура маленькая. А если 10E+06 и более??? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.09.2004, 16:17 |
|
||
|
Помогите с MDX, плиз
|
|||
|---|---|---|---|
|
#18+
Конечно все так. Но на моей базе Прибыль упущенна (прибыль, которую не получили в рез-те отсутсвия товара на остатках) с 110000 ассортиментом считается за приемлемое время. При больших объемах и подход другой нужен будет, не только на МДХ построеный. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.09.2004, 16:37 |
|
||
|
|

start [/forum/topic.php?fid=49&fpage=382&tid=1872256]: |
0ms |
get settings: |
10ms |
get forum list: |
20ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
58ms |
get topic data: |
13ms |
get forum data: |
3ms |
get page messages: |
52ms |
get tp. blocked users: |
1ms |
| others: | 262ms |
| total: | 427ms |

| 0 / 0 |
