История изменений

Статическую трансляции ответов с жестко заданной позицией полей

Дело не в этом. Я уже тут описывал простейший пример. Если ты получаешь полный набор данных в один заход сложным запросом с кучей джойнов, а у тебя изменилось одно единственное поле (ник одного пользователя), то ты замахаешься делать логику изменения запроса так, чтобы получить только это поле без получения всего датасета. С ORM ты можешь вытянуть только то, что реально изменилось.

у нас в данные хранятся в датацентрах Маунтин Вью и Франкфурта, мы должны минимизировать трафик между ними за счет кэширования

Ситуация актуальна практически для любого проекта чуть больше хеловорда. Получение полного датасета каждый раз - это долго. Даже если тебе нужно выполнить сложный запрос который не укладывается в ORM, лучше получить только ID (т.е. только данные из индекса) и потом через ORM вытянуть собственно нужные данные закэшировав объекты. (И есть шанс, что что-то уже будет в кэше, возможно даже всё).

объектов — это кэш объектов, просто объектов, это не ORM

Без кэша объектов в каком-то виде получение объектов не имеет особого смысла. В десктоп приложениях объекты живут всё время его работы. Для веба нужно чтобы объекты выживали между http запросами всё время взаимодействия пользователей с приложением. Иначе не совсем понятно, чем плох обычный map по датасету.

Статическую трансляции ответов с жестко заданной позицией полей

Дело не в этом. Я уже тут описывал простейший пример. Если ты получаешь полный набор данных в один заход сложным запросом с кучей джойнов, а у тебя изменилось одно единственное поле (ник одного пользователя), то ты замахаешься делать логику изменения запроса так, чтобы получить только это поле без получения всего датасета. С ORM ты можешь вытянуть только то, что реально изменилось.

у нас в данные хранятся в датацентрах Маунтин Вью и Франкфурта, мы должны минимизировать трафик между ними за счет кэширования

Ситуация актуальна практически для любого проекта чуть больше хеловорда. Получение полного датасета каждый раз - это долго. Даже если тебе нужно выполнить сложный запрос который не укладывается в ORM, лучше получить только ID (т.е. только данные из индекса) и потом через ORM вытянуть собственно нужные данные закэшировав объекты.

объектов — это кэш объектов, просто объектов, это не ORM

Без кэша объектов в каком-то виде получение объектов не имеет особого смысла. В десктоп приложениях объекты живут всё время его работы. Для веба нужно чтобы объекты выживали между http запросами всё время взаимодействия пользователей с приложением. Иначе не совсем понятно, чем плох обычный map по датасету.

Статическую трансляции ответов с жестко заданной позицией полей

Дело не в этом. Я уже тут описывал простейший пример. Если ты получаешь полный набор данных в один заход сложным запросом с кучей джойнов, а у тебя изменилось одно единственное поле (ник одного пользователя), то ты замахаешься делать логику изменения запроса так, чтобы получить только это поле без получения всего датасета. С ORM ты можешь вытянуть только то, что реально изменилось.

у нас в данные хранятся в датацентрах Маунтин Вью и Франкфурта, мы должны минимизировать трафик между ними за счет кэширования

Ситуация актуальна практически для любого проекта чуть больше хеловорда. Получение полного датасета каждый раз - это долго. Даже если тебе нужно выполнить сложный запрос который не укладывается в ORM, лучше получить только ID (т.е. только данные из индекса) и потом через ORM вытянуть собственно нужные данные закэшировав объекты.

объектов — это кэш объектов, просто объектов, это не ORM

Без кэша объектов в каком-то виде получение объектов не имеет особого смысла. В десктоп приложениях объекты живут всё время его работы. Для веба нужно чтобы объекты выживали между http запросами всё время взаимодействия пользователей с приложением. Иначе не совсем понятно, чем плох обычный map.

Статическую трансляции ответов с жестко заданной позицией полей

Дело не в этом. Я уже тут описывал простейший пример. Если ты получаешь полный набор данных в один заход сложным запросом с кучей джойнов, а у тебя изменилось одно единственное поле (ник одного пользователя), то ты замахаешься делать логику изменения запроса так, чтобы получить только это поле без получения всего датасета. С ORM ты можешь вытянуть только то, что реально изменилось.

у нас в данные хранятся в датацентрах Маунтин Вью и Франкфурта, мы должны минимизировать трафик между ними за счет кэширования

Ситуация актуальна практически для любого проекта чуть больше хеловорда. Получение полного датасета каждый раз - это долго. Даже если тебе нужно выполнить сложный запрос который не укладывается в ORM, лучше получить только ID (т.е. только данные из индекса) и потом через ORM вытянуть собственно нужные данные закэшировав объекты.

объектов — это кэш объектов, просто объектов, это не ORM

Без кэша объектов в каком-то виде получение объектов не имеет особого смысла. В десктоп приложениях объекты живут всё время его работы. Для веба нужно чтобы объекты выживали между http запросами всё время взаимодействия пользователей с приложением.