Цитата:
Сообщение от
mazzy
Оно и понятно, что непонятен.
Маззи, это уже хамство.
Ты общаешься в таком тоне, словно твой собеседник дурак, а ты один умнее всех на свете. Если устал или плохое настроение - не пиши. Тебя же никто не обязывает на все сообщения отвечать.
Организация кеша на сервере приложений - это нормально.
То что я предложил - фактически повторение уже работающего в Аксапте кеширования курсов валют. Правда на бОльших объемах. Т.е. разработчики приложения посчитали что для нескольких тысяч записей (примерный объем таблицы курсов валют) - стандартный механизм ядра неприемлем, а RecordSortedList - приемлем.
Про результаты я уже рассказал.
см.выше.
От кеширования решил отказаться. Буду отрубать функционал, который так издевается над базой.
Кстати, по поводу чудика - в некоторых случаях обращение к базе данных может быть быстрее чем использование кеширования средствами аксапты.
см. Книга Inside Microsoft Dynamics 4.0
Chapter 17
Transaction Performance - The EntireTable Cache
Pontoppidan пишет про EntireTable Cache, что
Цитата:
The database search engines have also evolved over time and are faster than the ones implemented in the Dynamics AX application runtime. It might be faster to let the database search for the records than to set up and use an entire-table cache, even though a database search involves round trips to the database tier.
Например в оракле есть инструменты позволяющие держать таблицу всегда в кеше сервера базы данных. Так что еще вопрос, что будет быстрее работать - кеш оракла плюс вызов с аоса на оракл или просто кеша аоса.
Я думаю, что критерием выбора может быть только проведение тестирования.
В случае таблицы UnitConvert и числа записей около 100 тыс - кеширование мапом или при помощи RecordSortedList - неэффективно.