История изменений
Исправление
Legioner,
(текущая версия)
:
Т.е., по сути, всё, над чем бились творцы баз данных SQL, и что, собственно и представляет из себя их основную ценность, выбрасывается на помойку. А именно, понятие изолированных параллельных транзакций.
Это из чего такой вывод следует?
Если этот кеш хранится на сервере, то для обычной СУБД это особо не нужно. При правильно построенных индексах часто используемые данные находятся в дисковом кеше, и время доступа к ним очень мало. Если же кеш хранится на клиенте, сервер должен собирать от коннектов и рассылать клиентам информацию об устаревании данных в кеше. Как минимум, при этом возникает ещё один показатель производительности, за которым надо следить, а предсказуемость производительности приложения на клиентской стороне сильно снижается. Хотя эта проблема менее значима, чем потеря понятия изолированных транзакций.
Один сервер БД, один клиент БД (серверное приложение). Один клиент в смысле один процесс клиентский. Соединений в потоках может быть хоть 10, это ничему не мешает, т.к. кеш первого уровня общий между всеми потоками. Речь идёт о классической трёхзвенной архитектуре: БД-Сервер-Клиент. Если серверов несколько, это уже кластер и тут свои проблемы могут вылазить, но ORM вполне подходит.
Исходная версия
Legioner,
:
Т.е., по сути, всё, над чем бились творцы баз данных SQL, и что, собственно и представляет из себя их основную ценность, выбрасывается на помойку. А именно, понятие изолированных параллельных транзакций.
Это из чего такой вывод следует?
Если этот кеш хранится на сервере, то для обычной СУБД это особо не нужно. При правильно построенных индексах часто используемые данные находятся в дисковом кеше, и время доступа к ним очень мало. Если же кеш хранится на клиенте, сервер должен собирать от коннектов и рассылать клиентам информацию об устаревании данных в кеше. Как минимум, при этом возникает ещё один показатель производительности, за которым надо следить, а предсказуемость производительности приложения на клиентской стороне сильно снижается. Хотя эта проблема менее значима, чем потеря понятия изолированных транзакций.
Один сервер БД, один клиент БД (серверное приложение). Речь идёт о классической трёхзвенной архитектуре: БД-Сервер-Клиент. Если серверов несколько, это уже кластер и тут свои проблемы могут вылазить, но ORM вполне подходит.