|
01.02.2006, 11:42 | #1 |
Участник
|
Имхо если есть счастливая возможность брать остатки из ОЛАП то ей грех не воспользоваться, сам так делал,это сильно ускоряет отчет и разгружает рабочую базу, как програмно обратится к кубу можно посмотреть в хелпе по олапу. Только конечно сфера применения узкая - даные не 100% актуальные (кубы считаются с некой периодичностью)..
|
|
01.02.2006, 13:14 | #2 |
Участник
|
Цитата:
Сообщение от MironovI
Имхо если есть счастливая возможность брать остатки из ОЛАП то ей грех не воспользоваться, сам так делал,это сильно ускоряет отчет и разгружает рабочую базу, как програмно обратится к кубу можно посмотреть в хелпе по олапу. Только конечно сфера применения узкая - даные не 100% актуальные (кубы считаются с некой периодичностью)..
|
|
01.02.2006, 16:23 | #3 |
Участник
|
С какого имено? Примера под рукой сейчас нету к сожалению если вы об этом, давно это было, на пред-пред.. работе, но в общем случае нужно найти в инете odbc-строку подключения.. запрос - можно например посмотреть примеры в mdx sample aplication.. которая в составе olap.. либо ребята с http://www.sql.ru/forum/actualtopics.aspx?bid=26 дожны помоч
|
|
02.02.2006, 10:45 | #4 |
злыдень
|
Хорошая статья про индексный доступ. Интересна с точки зрения понимания принципов работы серверов баз данных. Так как рассматриваемый сервер версионный - есть особенности по сравнению с sql 2000, c другой стороны по сравнению с эскуэль 2005 принципы, по идее, должны быть похожи
описание работы с индексами
__________________
Ибо зло есть лучшая сила человека. "Человек должен становиться все лучше и злее" -- так учу я. /Ф. Ницше/ |
|
02.02.2006, 11:30 | #5 |
Гость
|
Рибята, всем низачот
почему никто не предложил считать суммы по периодам, как реализовано для проводок ГК, просто сделать реализацию аналогично классам LedgerBalances* для складских проводок |
|
|
За это сообщение автора поблагодарили: dn (-1). |
02.02.2006, 12:10 | #6 |
Участник
|
Цитата:
Сообщение от ahtoh
Рибята, всем низачот
почему никто не предложил считать суммы по периодам, как реализовано для проводок ГК, просто сделать реализацию аналогично классам LedgerBalances* для складских проводок |
|
02.02.2006, 12:24 | #7 |
Moderator
|
Цитата:
Сообщение от ahtoh
почему никто не предложил считать суммы по периодам, как реализовано для проводок ГК, просто сделать реализацию аналогично классам LedgerBalances* для складских проводок
Те кто понимает о чем речь и так знают, только вопрос такой - во сколько вы оцениваете трудозатраты на такую модификацию?
__________________
С уважением, kvan. |
|
02.02.2006, 12:48 | #8 |
Гость
|
Цитата:
Сообщение от kvan
А кому нужно было предложить?
Те кто понимает о чем речь и так знают, только вопрос такой - во сколько вы оцениваете трудозатраты на такую модификацию? кому кому, афтару треда а оценка трудозатрат - это уже второй вопрос, кстати я не считаю, что это такая уж сложная модификация, к тому же аналогичная уже есть, можно содрать оттуда |
|
02.02.2006, 12:51 | #9 |
Участник
|
Цитата:
Сообщение от ahtoh
кому кому, афтару треда
а оценка трудозатрат - это уже второй вопрос, кстати я не считаю, что это такая уж сложная модификация, к тому же аналогичная уже есть, можно содрать оттуда |
|
02.02.2006, 13:06 | #10 |
Участник
|
Цитата:
Сообщение от ahtoh
кому кому, афтару треда
а оценка трудозатрат - это уже второй вопрос, кстати я не считаю, что это такая уж сложная модификация, к тому же аналогичная уже есть, можно содрать оттуда Предложенная модификация породит другие проблемы. и совершенно другой подход к программированию. в частности, промежуточные остатки надо закрывать (сводить к нулю) см. http://1c.mazzy.ru/articles/generation1c/#070 |
|
|
За это сообщение автора поблагодарили: dn (3). |
02.02.2006, 12:08 | #11 |
Участник
|
To Recoilme - Начиная с версии 3.0 все запросы без хита forupdate на скуле выглядят как select from table (nolock) - поэтому для отчетов вопросы с блокировками на запись и чтение не актуальны, поправьте если я не прав..
Последний раз редактировалось MironovI; 02.02.2006 в 12:14. |
|
02.02.2006, 12:27 | #12 |
злыдень
|
Цитата:
Сообщение от MironovI
To Recoilme - Начиная с версии 3.0 все запросы без хита forupdate на куле выглядят как select from table (nolock) - поэтому для отчетов вотпросы с блокировками на запись чтение не актуальны, поправьте если я не прав..
Но ведь гораздо интересней, если он прочитает ссылки, разберется с этой проблемой и найдет другие пути её решения, разве я не прав?
__________________
Ибо зло есть лучшая сила человека. "Человек должен становиться все лучше и злее" -- так учу я. /Ф. Ницше/ |
|
02.02.2006, 13:18 | #13 |
Гость
|
необязательно закрывать, да, таблица с итогами будет немаленькой, но все равно это будет работать быстрее, чем считать сумму с начала первоздания (или отматывать с конца)
|
|
02.02.2006, 13:32 | #14 |
Участник
|
Цитата:
Сообщение от ahtoh
необязательно закрывать, да, таблица с итогами будет немаленькой, но все равно это будет работать быстрее, чем считать сумму с начала первоздания (или отматывать с конца)
Вы просто не пробовали. Попробуйте. Как? Просто: Например, заведите по 1000 (например) финансовых аналитик и job'иком разнесите проводки со случайными комбинацияем аналитик. А теперь перенесите начальное сальдо на несколько лет с сохранением аналитики. А потом расскажите во сколько раз таблица промежуточных итогов превышает таблицу проводок. Нет, уж... Если вы не предусматриваете механизмы закрытия в ноль, то лучше советуйте получать итоги с начала времен. Кстати: вы никогда не задумывались ЗАЧЕМ нужна галочка "Не учитывать коды аналитики" при переносе начального сальдо? Подумайте... Подумайте почему ее название начинается с НЕ... Люди!!! Думайте! Пожалуйста. |
|
02.02.2006, 14:37 | #15 |
Участник
|
Цитата:
Сообщение от ahtoh
необязательно закрывать, да, таблица с итогами будет немаленькой, но все равно это будет работать быстрее, чем считать сумму с начала первоздания (или отматывать с конца)
|
|
02.02.2006, 13:23 | #16 |
Гость
|
ну а насчет трудозатрат - тут ведь все относительно, если сильно нужно - то сделать можно
|
|
02.02.2006, 14:42 | #17 |
Участник
|
И может оффтоп конечно - КОМУ ВООБЩЕ НУЖНЫ ОПЕРАТИВНЫЕ ДАНЫЕ ПО ОСТАТКАМ КОТОРЫЕ БЫЛИ ВЧЕРА?? Смотрите наличие, смотрите проводки, нужны АНАЛИТИЧЕСКИЕ отчеты - добропожаловать вон из ТРАНЗАКЦИОННОЙ базы в warehouse, olap и проч. Понимаю конечно что убедить в этом пользователя иногда себе дороже чем по тихому сделать то что он просит и не важно что ему это по сути не нужно.
|
|
|
За это сообщение автора поблагодарили: Recoilme (3). |
02.02.2006, 14:44 | #18 |
Участник
|
Цитата:
Сообщение от MironovI
добропожаловать вон из ТРАНЗАКЦИОННОЙ базы в warehouse, olap и проч.
Но изначальный вопрос был о другом, по-моему. |
|
02.02.2006, 15:55 | #19 |
Участник
|
Цитата:
Сообщение от mazzy
Полностью поддерживаю подход.
Но изначальный вопрос был о другом, по-моему. |
|
02.02.2006, 18:13 | #20 |
----------------
|
Извините, что встрял, этот запрос вообще вернет полную лажу, так как вместо SUM(dbo.INVENTSUM.POSTEDQTY) надо MAX(dbo.INVENTSUM.POSTEDQTY)
а вот с chel не согласен.В запросе нет ограничений на InventSum, а сам он никогда не чиститься, даже если всё = 0. |
|
Теги |
остатки, ax3.0 |
|
Похожие темы | ||||
Тема | Ответов | |||
Остатки на дату InventSumDatePhysical | 6 | |||
Остатки товара на определенную дату | 7 | |||
Скачут остатки | 3 | |||
Цена на дату создания заказа/закупки | 2 | |||
Остатки | 6 |
|