Есть у меня одна задумка.
Имеем базу с веб сервисом, там к примеру 3 метода, разберем один из них.
Метод имеет 2 входных параметра, первый дата или число (простой тип), второй некий ОбъектXDTO. На основе этих входных параметров выполняется функция, которая делает десятки запросов к базе по 10 таблицам к примеру, а полученный ответ вкладывает в результат метода web сервиса.
Предпологается что 10 таблиц по которым будут производиться запросы будут меняться раз в месяц к примеру, а запросы по wsdl будут раз в 5 минут к примеру.
В итоге я задумал такую штуку - создать некую константу типом уникальный индентификатор которая меняется при каждом изменении в одной из 10 таблиц (типа версия таблиц), далее создать рег сведений с измерениями : ID wsdl метода, версия таблиц, кеш входных параметров wsdl метода; и один реквизит : ХЗ или просто строка с выходным ОбъектовXDTO в виде xml/
В итоге получаем систему, при запросе к которой она сначала ищет готовый ответ в нашем рег сведений по текущей версии таблиц, если находит то возвращает его, если нет то передает управление нашей мего функции по формированию ответа.

Теперь вопрос: как лучше вычислять хеш входных параметров?
(у меня пока идея : добавлять все входные параметры в массив, потом через сериализатор его в строку xml, затем сохранить в файл и через ХешированиеДанных получить к примеру CRC32, ну чтоб тип хеша был число а не строка).

зачем делать хэш? Лучше заведи доп регистр в котором будут находиться нужные данные. Двигай его документами

(1) там используются только справочники и регистры сведений. В реализации будет методов 8, значит чутли не под каждый свой РС, а значит при записи справочника надо изменять каждый регистр сведений для метода. Так чтоли?

(2) Можно и один регистр на всех с доп. измерением Объект.

(1) Ну вот и будет в регистре в одном измерении хэш входных параметров, а в ресурсе результат

Универсально - значение в строку и результат

(3) У меня в 1 самом сложном методе будет как-то так :
По определенному условию выбираются элементы справочника, по пути особо группируются, затем используя полученный результат входим в цикл где по каждой строке выборки идёт другой запрос не менее простой (наверно). В итоге wsdl метод возвращает не просто какуюто специфическую таблицу а систему вложенных таблиц, где также некоторые атрибуты элементов на уровне 1С расчитываться будут тоже отдельными запросами. Короче дофига запросов по 10 таблицам и особый вид их компоновки для выгрузки и передачи как ответ на wsdl метод.

И вообще mistеr, acsent имел ввиду если есть некий запрос по 5 таблицам с выборкой к примеру 5 колонок , то сделать 6 таблицу с 5 колонками (регистр сведений) и при каждом изменении элемента из тех 5 таблиц апдейтит соот. данные 6 таблицы, а wsdl метод будет запросы делать только к 6 таблице.
Я в своей реализации такое не очень представляю, так результат у меня есть таблица с вложенными таблицами и ещё со всякой мелочью (1 запросом не обойтись вроде как).

(3) Ты опиши свою идею мож я тя не так понял.

(6) Это я не так понял. :)
Ответ (3) относился к тому, как хранить текущие версии таблиц. Одна версия на все не годится, иначе кэширование не будет эффективным. Не в каждом методе ведь все 10 таблиц участвуют.

(7) Ну мне типа лучше знать, но можно сказать в каждом методе треть или половина а в одном и 7 из 10 учавствуют. Смысл в том что по моим расчетам они будут почти статичными, так как они содержат инфу ну что то вроде тарифных планов, кои естественно не меняются каждый день.

Поднимаю тему к понедельнику.
Все таки пока вопрос остался, как лучше делать кеш входных параметров?

(9) А запросов будет много? Если много, я бы рассмотрел вариант рассчитывать все результаты регламентным заданием.

(10) Предлагаешь в цикле фигачить к примеру от 01.01.2000 до ТекущаяДата() и это только 1 параметр, а в нем цикл по второму, а в нем цикл по третьему. Учитываем что мы переберём скорее всего только частые варианты ибо хз чо там запрашивать будут (но этого конеш я думаю будет достаточно). И конечно какимто неведомым образом  мне надо запускать рег задание именно тогда когда поменялся один из элементов 10 таблиц, ставя блокировку на них пока наш мего зверь не сделает все возможные варианты (конеш можно организовать константу, типа вкл/выкл работы с wsdl, когда выкл меняем чо хотим, а перед вкл запускаем мего зверя).
Корочь идея чот мне не очень понравилась. Ты мож опиши на более низком уровне, мож чото я не вижу.

(11) Нет, не цикл в цикле, а несколькими запросами сформировать весь нужный результат, для всех возможных входных данных. И записать в регистр.

Запускать каждый час, если раз в час данные меняются. Судя по условиям, данные на начало часа потребителей устроят.

(12) я конеш подумаю над этим вариантом, но чот пока он меня не привлекает, есть свои и не мало подводных камней.

И ктонить всетаки хотябы для интереса ответит на мой вопрос - как лучше считывать кэш входных параметров (их типы разные).

АПП

(14) Входные параметры в структуру, структуру в строку (ЗначениеВСтрокуВнутр), от строки вычисляем хэш и его и используем для поиска в кэше по входным параметрам

(16) а ЗначениеВСтрокуВнутр быстрее чем сериализатор или нет, или это тоже самое, да и массив мне кажеться попроще структуры

А самому проверить?

(18) В падлу, думал разведу товарища))

Блин еще надо посмотреть чо быстрей, выгружать в файл входные данные затем при помощи ХешированиеДанных, или вызывать ком объект Capicom и через него напрямую считать хеш строки.
Тоже впадлу, мож кто так знает чо быстрей.