Радикальное увеличение скорости

[Александр]

хотя наверно лучше юзера включить в роль DB_DataReader и читать напрямую без view - буду работать от уволившейся учетной записи....
есть ли тут какие нибудь подводные камни - никто не скажет?

[Disillusioned]

Можно написать целый ряд собственных ХП, которые будут выполнять часто используемые функции:
-получение значение атрибута;
-поиск объекта по значению атрибута;
-получение списка кодов дочерних объектов;
-получение списка кодов документов
....
....
и т.д.
Потом эти ХП легко и приятно использовать где угодно. Плюс в случае необходимости оптимизации, меняем только ХП, все вызовы (которые могут быть очень многочисленными) остаются без изменений.

P/S Таких ХП общего назначения я у себя насчитал 48 штук.

[Александр]

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

поработаю пока в такой комбинации - посмотрим оправдает или нет

[Александр]

получилось шикарно
комбинация
скрипт + User (роль Party_Users+DB_DataReader)+recordset
оправдала себя на 100 %

ps
кстати одиночные переменные также шикарно укладываются в рекордсет и нормально разбираются скриптом
в общем - вот оно - счастье !

[Старик Крупский]

Александр, а скажи, плиз, как ты пишешь данные в базу? Тебе же и записывать надо быстро. В твоей форме, например, 2000 строк, 10 из них поменялись. Ты каждую сразу записываешь действием, или в конце все сразу в цикле, или как-то еще? Я извиняюсь, но если ты уже об этом писАл, то дай ссылочку.

[Александр]

Читать мне нужно большие массивы это да, но слава богу записывать в базу мне нужно не более 10-15 строк состоящих не более чем из 10 столбцов, поэтому использую штатные средства.
например на форме многомерные массивы под чтение 2000х3 и под запись 15х10 (15 объектов по 10 атрибутов на каждый)
работаю по дочерним объектам (15 дочерних объектов)

т.к. массивы на форме Workwflow - теряются до сих пор (как-то сами собой пропадают с экрана) - для нас первичны физически существующие объекты а не непонятно как ведущие себя переменные Workflow
1. Прочитали Оччень большой массив для чтения - чисто визуальный...
2. Из данного массива берем строчку и на ее основе создаем и записываем новый дочерний Party объект действием т.е. в другой массив для записи
3. Инициализируем массив работы по новой перечитывая огромный массив под чтение и мелкий (дочерние объекты) под запись
т.к. массивы на форме Workwflow - живут отдельной от формы WorkFlow жизнью - мы при изменении каких либо внешних переменных
1. Полностью перерасчитываем и перезаписываем и перечитываем весь массив поз запись и читаем под чтение
...
при удалении также - разорвали связь дочернего объекта - перечитали весь массив по новой и тот и другой
т.е. одиночным действием или действием в цикле и так и так.
и т.д. как видишь - чтения больше чем записи поэтому ее пока не оптимизировали
...
алгоритмом конечно можно вытянуть и чтение и запись - но из за непредсказуемости поведения переменных на форме работы - это все под большим вопросом.

[Старик Крупский]

Ну, понятно. Я так и подумал, что записываешь ты мало, иначе "плач Ярославны" мы бы услышали уже давно
Не то, чтобы пишет медленно, но тебе точно не понравилось бы