Остатки на дату. - Страница 3 - DAX: База знаний и проекты

MironovI · 01.02.2006, 11:42

Имхо если есть счастливая возможность брать остатки из ОЛАП то ей грех не воспользоваться, сам так делал,это сильно ускоряет отчет и разгружает рабочую базу, как програмно обратится к кубу можно посмотреть в хелпе по олапу. Только конечно сфера применения узкая - даные не 100% актуальные (кубы считаются с некой периодичностью)..

Bars · 01.02.2006, 13:14

Цитата:

Сообщение от MironovI

Имхо если есть счастливая возможность брать остатки из ОЛАП то ей грех не воспользоваться, сам так делал,это сильно ускоряет отчет и разгружает рабочую базу, как програмно обратится к кубу можно посмотреть в хелпе по олапу. Только конечно сфера применения узкая - даные не 100% актуальные (кубы считаются с некой периодичностью)..

а можно с этого места поподробнее)

MironovI · 01.02.2006, 16:23

С какого имено?

Примера под рукой сейчас нету к сожалению если вы об этом, давно это было, на пред-пред.. работе, но в общем случае нужно найти в инете odbc-строку подключения.. запрос - можно например посмотреть примеры в mdx sample aplication.. которая в составе olap.. либо ребята с http://www.sql.ru/forum/actualtopics.aspx?bid=26 дожны помоч

Recoilme · 02.02.2006, 10:45

Хорошая статья про индексный доступ. Интересна с точки зрения понимания принципов работы серверов баз данных. Так как рассматриваемый сервер версионный - есть особенности по сравнению с sql 2000, c другой стороны по сравнению с эскуэль 2005 принципы, по идее, должны быть похожи
описание работы с индексами

dn · 02.02.2006, 11:30

Рибята, всем низачот

почему никто не предложил считать суммы по периодам, как реализовано для проводок ГК, просто сделать реализацию аналогично классам LedgerBalances* для складских проводок

MironovI · 02.02.2006, 12:10

Цитата:

Сообщение от ahtoh

Рибята, всем низачот

почему никто не предложил считать суммы по периодам, как реализовано для проводок ГК, просто сделать реализацию аналогично классам LedgerBalances* для складских проводок

Я думаю не стоит превращать Аксапту с Один-сами знате какая буква

**kvan** · 02.02.2006, 12:24

Цитата:

Сообщение от ahtoh

почему никто не предложил считать суммы по периодам, как реализовано для проводок ГК, просто сделать реализацию аналогично классам LedgerBalances* для складских проводок

А кому нужно было предложить?
Те кто понимает о чем речь и так знают, только вопрос такой - во сколько вы оцениваете трудозатраты на такую модификацию?

02.02.2006, 12:48

Цитата:

Сообщение от kvan

А кому нужно было предложить?
Те кто понимает о чем речь и так знают, только вопрос такой - во сколько вы оцениваете трудозатраты на такую модификацию?

кому кому, афтару треда
а оценка трудозатрат - это уже второй вопрос, кстати я не считаю, что это такая уж сложная модификация, к тому же аналогичная уже есть, можно содрать оттуда

Bars · 02.02.2006, 12:51

Цитата:

Сообщение от ahtoh

кому кому, афтару треда
а оценка трудозатрат - это уже второй вопрос, кстати я не считаю, что это такая уж сложная модификация, к тому же аналогичная уже есть, можно содрать оттуда

спасибо за предложенный вариант, хотя предложенный запрос работает достаточно быстро, все равно варианты еще было бы неплохо рассмотреть.

**mazzy** · 02.02.2006, 13:06

Цитата:

Сообщение от ahtoh

кому кому, афтару треда
а оценка трудозатрат - это уже второй вопрос, кстати я не считаю, что это такая уж сложная модификация, к тому же аналогичная уже есть, можно содрать оттуда

Не верьте.

Предложенная модификация породит другие проблемы.
и совершенно другой подход к программированию.
в частности, промежуточные остатки надо закрывать (сводить к нулю)
см. http://1c.mazzy.ru/articles/generation1c/#070

MironovI · 02.02.2006, 12:08

To Recoilme - Начиная с версии 3.0 все запросы без хита forupdate на скуле выглядят как select from table (nolock) - поэтому для отчетов вопросы с блокировками на запись и чтение не актуальны, поправьте если я не прав..

Recoilme · 02.02.2006, 12:27

Цитата:

Сообщение от MironovI

To Recoilme - Начиная с версии 3.0 все запросы без хита forupdate на куле выглядят как select from table (nolock) - поэтому для отчетов вотпросы с блокировками на запись чтение не актуальны, поправьте если я не прав..

"другимисловамидлярешенияпроблемыуказаннойchelнадочтениеинвентсамаивычитаниеинвенттрансаделатьводнойтранзакцииспараметромforupdateприэтомповесиввсюсистемунапрочь"

Но ведь гораздо интересней, если он прочитает ссылки, разберется с этой проблемой и найдет другие пути её решения, разве я не прав?

02.02.2006, 13:18

необязательно закрывать, да, таблица с итогами будет немаленькой, но все равно это будет работать быстрее, чем считать сумму с начала первоздания (или отматывать с конца)

**mazzy** · 02.02.2006, 13:32

Цитата:

Сообщение от ahtoh

необязательно закрывать, да, таблица с итогами будет немаленькой, но все равно это будет работать быстрее, чем считать сумму с начала первоздания (или отматывать с конца)

Вы просто не пробовали. Попробуйте.

Как? Просто: Например, заведите по 1000 (например) финансовых аналитик и job'иком разнесите проводки со случайными комбинацияем аналитик. А теперь перенесите начальное сальдо на несколько лет с сохранением аналитики.

А потом расскажите во сколько раз таблица промежуточных итогов превышает таблицу проводок.

Нет, уж... Если вы не предусматриваете механизмы закрытия в ноль, то лучше советуйте получать итоги с начала времен.

Кстати: вы никогда не задумывались ЗАЧЕМ нужна галочка "Не учитывать коды аналитики" при переносе начального сальдо? Подумайте... Подумайте почему ее название начинается с НЕ...

Люди!!! Думайте! Пожалуйста.

MironovI · 02.02.2006, 14:37

Цитата:

Сообщение от ahtoh

необязательно закрывать, да, таблица с итогами будет немаленькой, но все равно это будет работать быстрее, чем считать сумму с начала первоздания (или отматывать с конца)

Могу еще добавить что такой механизм БЫЛ реализован на одном из проектов (крупная оптово-розничная компания ) и от него отказались в результате, поскольку база начала сильно тормозАть.. что отчетам хорошо - то для разноски документов смерть..

02.02.2006, 13:23

ну а насчет трудозатрат - тут ведь все относительно, если сильно нужно - то сделать можно

MironovI · 02.02.2006, 14:42

И может оффтоп конечно - КОМУ ВООБЩЕ НУЖНЫ ОПЕРАТИВНЫЕ ДАНЫЕ ПО ОСТАТКАМ КОТОРЫЕ БЫЛИ ВЧЕРА?? Смотрите наличие, смотрите проводки, нужны АНАЛИТИЧЕСКИЕ отчеты - добропожаловать вон из ТРАНЗАКЦИОННОЙ базы в warehouse, olap и проч. Понимаю конечно что убедить в этом пользователя иногда себе дороже чем по тихому сделать то что он просит и не важно что ему это по сути не нужно.

**mazzy** · 02.02.2006, 14:44

Цитата:

Сообщение от MironovI

добропожаловать вон из ТРАНЗАКЦИОННОЙ базы в warehouse, olap и проч.

Полностью поддерживаю подход.
Но изначальный вопрос был о другом, по-моему.

Bars · 02.02.2006, 15:55

Цитата:

Сообщение от mazzy

Полностью поддерживаю подход.
Но изначальный вопрос был о другом, по-моему.

тем не менее много полезного

Wamr · 02.02.2006, 18:13

Извините, что встрял, этот запрос вообще вернет полную лажу, так как вместо SUM(dbo.INVENTSUM.POSTEDQTY) надо MAX(dbo.INVENTSUM.POSTEDQTY)

а вот с chel не согласен.В запросе нет ограничений на InventSum, а сам он никогда не чиститься, даже если всё = 0.

Похожие темы
Тема	Автор	Раздел	Ответов	Посл. сообщение
Остатки на дату InventSumDatePhysical	Raven Melancholic	DAX: Программирование	6	10.05.2007 15:29
Остатки товара на определенную дату	Lucky13	DAX: Программирование	7	27.03.2007 14:27
Скачут остатки	Def	DAX: Программирование	3	03.05.2006 14:27
Цена на дату создания заказа/закупки	George Nordic	DAX: Функционал	2	29.06.2005 15:56
Остатки	dog37	DAX: Программирование	6	02.06.2005 11:25