Некоторые мысли по поводу ...


[ Пpишедшие ответы ] /www.hdru.com/wwwboard/faq.htm">Help ]

Posted by Рустем Мухаметшин on November 15, 1998 at 07:45:15:

In Reply to: Re: Автоматическое завершение месяца posted by Сергей Холево, фирма Централь Минск on November 14, 1998 at 13:16:10:

    Прежде всего о сервере - перейдите на версию 2.32, она не добавляет first.rpt ко всем отчетам и ф/к. Получите существенную экономию памяти на дереве и ф/к, формах.
    Далее.
    1) На мой взгляд использование оператора TOTAL не допустимо даже в отчетах, а уж в ф/к ТЕМ БОЛЕЕ. Трудно придумать форму или ф/к в котором пришлось бы использовать TOTAL не в теле цикла (в дереве в #-ветви). Это очень и очень не оптимально по времени. К примеру на моих базах форма оборотной товарной ведомости (остаток,приход,расход,остаток) на операторе TOTAL срабатывал за время более 15 минут (раньше клиентская часть "умирала", справочник товаров на 1500 позиций), после введения однопроходного по фактам механизма с формированием таблицы она исполняется за НЕСКОЛЬКО СЕКУНД !!! (менее 5). Вспомните недавнюю работу системной формы аналитических корреспонденций за неровный интервал месяцев :) - это была просто смерть, всем строго-настрого запрещали нажимать F6 в форме корреспонденциях :). То же самое можно отнести и к дереву операций. Скорее всего приходиться использовать конструкцию типа
#Счет     Операция авто закрытия
...
  X    X      WORK
...
Применять TOTAL, SEARCH, NEWS, ... крайне не экономно в смысле быстродействия. Мне кажеться, что применять #-ветви нужно только в крайнем случае - когда нужно делать проводки на #-счета (тут уж к Аркадию просьба о генерации проводок без листьев, а напрямую из ф/к). К примеру расчеты по книге покупок делаются без цикла (ведь всего одна проводка Д68 К19). Конечно используеться перемотка фактов за соответсвующий период, но в один проход (это очень быстро, к тому же перебираються сами записи, а не весь список контрагентов к примеру)
    2) Насколько я могу судить по статистике, Вы мало пользуетесь экстрапараметрами. Безусловно, факт самая экономичная, в смысле памяти, конструкция. Что не скажешь об экстрапараметрах, сами то значения храняться комактно, а вот под индексы отводиться буфер фиксированной длины. Тем не менее если Вы используете в операциях где необходимо знать текущее состояние объекта учета перед его модификацией механизмы фактов (NEWS) - рекомендую отказаться и перейти на экстрапараметры.Это даст весьма ощутимый (в разы) выигрышь в быстродействии. Когда-то, я использовал настройку на базе ХД, где остатки товаров хранились в фактах. Ну и естественно в любой операции прихода-расхода нужно было использовать NEWS. Поначалу было не заметно. Но потом был кошмар. Теперь там где нужно в дереве знать текушее состояние объекта оно храниться в экстрапараметрах. В факты записывается то для чего они собственно и нужны - факты изменения состояния объекта. Конечно следует ожидать увеличения потребности в памяти :(. Но это по моему единственный реальный способ повышания быстродействия (а его как мне кажеться можно значительно повысить). Конечно есть способ записи проводок в EXTRD, но я его не приемлю.
    3) Без увеличения ОЗУ не обойтись, но это того стоит. Я все таки не понимаю как Вы умещаетесь на 64М если сервер с одним месяцем в DUAL занимает 13М (или у Вас в каждый момент времени работает только один месяц ???)
    4) Посмотрите мою программу шлюза (http://www.mi.ru/downloads/fbpgate.zip 17K) Она позволяет адресно установить права на возможность изменения месяцев в журнале.
    5) Если пришлете, к примеру, какую нибудь ветвь с автооперацией, то можно поговорить конкретнее.


Пpишедшие ответы: