можно не сбрасывать кэш, а обновлять тот элемент, о котором сообщил триггер. В 1С, например, можно оповещать об изменении только одного элемента
если реализовывать встроенную СУБД придется либо отказаться от этих возможностей (то есть выплеснуть вместе с водой и ребенка, как сделал 1С), либо все же реализовывать их
А Вы смотрИте на эти вещи проще. Если кому-то нужен локальный функционал, и мы даем такому клиенту возможность не разворачивать на машине полноценную СУБД, то пусть наше решение будет попроще. Ничего страшного в этом нет. Клиент согласится на урезанную версию, лишь бы не нагромождать у себя весь стек технологий.
Дело не в том, что никто не захочет, а что это будет достаточно не часто
Ок, принимается. Зачастую, проектируя какой-то фрагмент функционала, приходится отталкиваться от прогнозов относительно его нагруженности. И если предполагается, что вот в этой, грубо говоря, таблице будет много данных, но листать их вверх-вниз «будет достаточно не часто», то — да, кэши нужно отключать. В общем, фреймворк должен быть достаточно гибок, чтобы позволять использовать ту градацию функциональности, которая нужна в том или ином случае.
данные могут меняться и тогда они будут не актуальными
Для таких случаев должны быть тригеры, оповещающие кэши об устаревании при необходимости. Но соглашусь, что кэширование целесообразно не всегда, и в 1С, например, кэширование на сервере можно не использовать.
<СУБД сами имеют кэши>
Ну… можно, конечно, и отдать этот вопрос на откуп СУБД. Это уже тема выбора СУБД, которые поддерживает фреймворк. Другое дело, что вообще далеко не всегда есть желание/возможность у конечного пользователя разворачивать на локальной машине отдельную СУБД для использования локальной системы учета. Хорошо, что есть платформы, где это не обязательно.
пользователь не так часто листает вверх, потом вниз, потом опять вверх, потом опять вниз, чтобы cache hit ratio был высоким
А вот тут в корне не соглашусь. В случаях, когда в некоей таблице хранится действительно большое количество записей, наивно надеяться, что никто никогда не захочет плотно поработать с записями, листая таблицу и в хвост и в гриву.
Было бы интересно вернуться к вопросу динамического вывода на форму списка номенклатуры при подборе в Заказ. И 1С, и lsFusion позволяют пользоваться обычным браузером как клиентом (веб-клиентом) для подключения к собственно серверу (т.н. серверу приложений, главному, наверное, из механизмов платформы). Рассмотрю этот способ для наглядности.
Понятно, что для вывода списка номенклатуры сервер должен запросить этот список весь или частично у СУБД и отдать на клиент. Хотелось бы знать: если список большой, и клиент получает список порциями по мере того, как пользователь движется по списку вниз, кэшируется ли на клиенте какое-то количество позиций? А на сервере?
В 1С, насколько мне известно, клиент имеет только ту часть списка, которую в данный момент отображает. А вот на сервере можно при желании хранить в кэше некоторое количество данных. Чтобы не запрашивать у БД еще раз первые порции, если, к примеру, пользователь захочет вернуться к началу списка. А как с этим дело у lsFusion?
можно не сбрасывать кэш, а обновлять тот элемент, о котором сообщил триггер. В 1С, например, можно оповещать об изменении только одного элемента
А Вы смотрИте на эти вещи проще. Если кому-то нужен локальный функционал, и мы даем такому клиенту возможность не разворачивать на машине полноценную СУБД, то пусть наше решение будет попроще. Ничего страшного в этом нет. Клиент согласится на урезанную версию, лишь бы не нагромождать у себя весь стек технологий.
Ок, принимается. Зачастую, проектируя какой-то фрагмент функционала, приходится отталкиваться от прогнозов относительно его нагруженности. И если предполагается, что вот в этой, грубо говоря, таблице будет много данных, но листать их вверх-вниз «будет достаточно не часто», то — да, кэши нужно отключать. В общем, фреймворк должен быть достаточно гибок, чтобы позволять использовать ту градацию функциональности, которая нужна в том или ином случае.
Для таких случаев должны быть тригеры, оповещающие кэши об устаревании при необходимости. Но соглашусь, что кэширование целесообразно не всегда, и в 1С, например, кэширование на сервере можно не использовать.
<СУБД сами имеют кэши>
Ну… можно, конечно, и отдать этот вопрос на откуп СУБД. Это уже тема выбора СУБД, которые поддерживает фреймворк. Другое дело, что вообще далеко не всегда есть желание/возможность у конечного пользователя разворачивать на локальной машине отдельную СУБД для использования локальной системы учета. Хорошо, что есть платформы, где это не обязательно.
А вот тут в корне не соглашусь. В случаях, когда в некоей таблице хранится действительно большое количество записей, наивно надеяться, что никто никогда не захочет плотно поработать с записями, листая таблицу и в хвост и в гриву.
Понятно, что для вывода списка номенклатуры сервер должен запросить этот список весь или частично у СУБД и отдать на клиент. Хотелось бы знать: если список большой, и клиент получает список порциями по мере того, как пользователь движется по списку вниз, кэшируется ли на клиенте какое-то количество позиций? А на сервере?
В 1С, насколько мне известно, клиент имеет только ту часть списка, которую в данный момент отображает. А вот на сервере можно при желании хранить в кэше некоторое количество данных. Чтобы не запрашивать у БД еще раз первые порции, если, к примеру, пользователь захочет вернуться к началу списка. А как с этим дело у lsFusion?