Динамическая селекция фактов в ФБП



Posted by Анатолий Анимица on June 10, 1999 at 03:04:51:

In Reply to: Эффективное использование "быстрых фактов" posted by Бутченко Игорь on June 09, 1999 at 02:30:41:

AAA


Игорь Бутченко предложил интересный, на мой взгляд, механизм формирования строки отбора фактов, позволяющий более эффективно использовать накапливаемые в системе ФБП данные, упрощая программы селекции фактов по динамически формируемым условиям отбор|поиск.
В некотором "прародительском" виде мы такую динамику используем уже сейчас, подменяя строку search или ее аватары news, total, nerase группами таких строк.

В моих системах, например, в формах оперативного учета и контроля движения ценных бумаг, подобный механизм применяется как стандартная функция уже года три или четыре в следующем виде.

Например, есть факт:
fact FACT документ1 егодата1 документ2 егодата2 контрагент что сколько почем НДС комментарий штамп,
порождаемый строкой

fact FACT a,b,c,d,e,f,g,h,i,j,k.

В отчетной форме (а в ряде случаев даже в файлах-коэффициентах) сначала создается комплекс признаков отбора в виде строковой переменной st=x1x2.., где x1..xn - символы переменных строки search. Затем несколько троек строк вида


if <условие> (например, [ps 'a',st]&[ps 'c',st].....)
search a,?b,c,?d..
goto eofsrch
elseif
...
endif
:eofsrch

сделают точно то же, что предлагает Игорь. Путем явной передачи управления нужному селектору. Сказано: "не порождайте сущностей без крайней нужды в оных". То, что я предложил на замену, пока существенно быстрее, чем компиляция строки search на этапе исполнения, а также разумно ограничивает программиста, требуя от него эффективного кода. Например, не 2 в 15 степени, а три..пять строк селекции кодируются легко и приятно, и читать такую программу внешнему читателю намного проще. Легко догадаться, что динамическая строка search потребует компиляции на этапе непосредственно исполнения, а это сильно замедлит ФБП. Тем не менее, в обозримом будущем (я оцениваю его так - когда 2..5 гигафлопс будет у Вас на столе), к идее разумно будет вернуться.

Пользуясь случаем, хочу поделиться еще одним способом разумного использования фактов

Допустим, некоторые операции порождают факты определенного вида. А другие операции, в том числе и находящиеся в других датах, производят их поиск и модификацию, используя nerase.
Факт модифицируется и записывается снова. Легко видеть, что в этом случае исчезнет этот факт в старой дате, и формы, которые его ищут, там уже не найдут. Эта задача возникла у меня в следующем виде: например, некоторое событие записано в виде факта, по которому после акцепта его необходимо пометить как обработанный, чтобы исключить повторное его использование. Поскольку обработчик находится в другой дате, пересоздание такого факта с модификацией поля разрушит временнУю структуру фактов. Я использовал сначала дополнительное поле "дата факта", которое записывалось при его первом создании, но потом пришел к выводу, что надежнее, проще и экономичнее создавать факт в двух копиях - одна не изменяется и служит для представления структуры в исходном виде, а вторая модифицируется как описано выше. Копии отличаются одним полем, например, значение поля -1 обозначает "факт не будет изменяться", 0 - факт к поиску для nerase, 1 - факт обработан и модифицирован. Это принято сейчас в моих системах как стандартное решение. Можно придумать новые операторы edit и nedit - эквивалентов search и nerase с редактированием полей. Алгоритмы с использованием edit и nedit тоже потребуют динамической компиляции, поэтому я пока отказался от просьбы о создании таких механизмов.

AAA



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