вадяskyANAА насчёт того, что разные потоки, то не заню как в Java, а в .Net уже есть готовые thread safe классы, например: MemoryCache .
в этот MemoryCache данные загрузились из базы - кэш в базе +MemoryCache, уже дублирование
Стоп, Вы изначально это называли дублированием?

Тогда и кэш базы также можно назвать дублированием, и денормализацию дублированием, и хранение горячих данных в отдельной таблице дублированием. Но зачем?

Задача обеспечить быстрый доступ к нужным данным и кэширование - это один из распространённых способов.

вадяиз этого MemoryCache тыберёшь для сортировки в один поток, второй в свой поток....
или ты сортируешь в MemoryCache, а второй получает что получает?
А, я походу Вас понял. Вы за память потока беспокоитесь. По разному бывает, зависит от задачи.

вадяавторСтоп, Вы изначально это называли дублированием?

Тогда и кэш базы также можно назвать дублированием, и денормализацию дублированием, и хранение горячих данных в отдельной таблице дублированием. Но зачем?

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

Но Вы согласны, что если в памяти есть необходимые и актуальные данные, то скорость работы с ними ни фига не ниже хранимок, а выше? :)

вадяавторА, я походу Вас понял. Вы за память потока беспокоитесь. По разному бывает, зависит от задачи.
если это оценивать грамотно, и понимать что получаешь и что за это заплатил.
Ну если оценивать грамотно, то Вам в первую очередь на стоит делать заявлений типа этого: "в итоге в памяти получается куча дублирования".

Два потока обращаются за данными.
Рассмотрим случай, когда нет MemoryCache. Каждый поток получит свой набор объектов, итого два набора объектов в памяти.

Рассмотрим случай, когда есть MemoryCache. Каждый поток получит либо свой набор объектов, либо будет использовать тот, что уже в памяти, зависит от задачи.

То есть без MemoryCache имеем N наборов объектов, где N - это количество потоков, а с MemoryCache в лучшем случае имеем ровно один набор, а в худшем N + 1.

Простите, но если всё грамотно, то нет никакой кучи дублирования.

вадяавторНо Вы согласны, что если в памяти есть необходимые и актуальные данные, то скорость работы с ними ни фига не ниже хранимок, а выше? :)
да
Что и требовалось доказать :)
вадяно если это актуальне данные на клиенте, а не на сервере, где таких данных (одинаковых для каждого клиента) множество.
т.е. для каждого клиента хранится его набор объектов. это хорошо когда клиентов мало, а когда сотни тысяч?
и стоит одному изменить - актуальность у остальных пропадёт
Вы опять ошибаетесь. При грамотной реализации ничего не пропадает.

И кстати тут надо бы уточнить, кого Вы называете клиентами? И почему данные одного клиента вообще влияют у Вас на данные другого клиента?

Вот у нас к примеру клиенты - это некоммерческие организации. Их данные по большей части не пересекаются.
Но у этих организаций есть свои пользователи, свои клиенты, что заходят к ним на сайт.

вадяавторВы опять ошибаетесь. При грамотной реализации ничего не пропадает.
правильно, если в этой реализации отслеживается изменения..а это дополнительные операцииС точки зрения бизнес-логики никаких дополнительных операций. Прилетели изменения, вызывается метод Save, и то, что при этом обновляется кэш, остаётся за кадром.
При желании кэширование можно отключить, изменив одно свойтво в конфиге.

вадяавторИ кстати тут надо бы уточнить, кого Вы называете клиентами? И почему данные одного клиента вообще влияют у Вас на данные другого клиента?

клиент это браузеры, десктопы, андроиды.
у меня данные не влияют, а будут влиять у вас если вы сортируете один обект, а он используется несколькими клиентамиЧто значит "у меня данные не влияют, а будут влиять у вас"? Каким образом и на что влиять?
У тебя N клиентов получают данные из БД с разной сортировкой, то есть в какое-то время имеем N объектов в памяти.
У меня N клиентов получают данные из кэша с разной сортировкой, то есть в какое-то время имеем N + 1 объект в памяти.
Ну на один объект в памяти больше, зато быстро.

вадяавторВот у нас к примеру клиенты - это некоммерческие организации. Их данные по большей части не пересекаются.
Но у этих организаций есть свои пользователи, свои клиенты, что заходят к ним на сайт.
ну вот такой трактовки я от тебя не ожидал.А что такого в такой трактовке?

вадяPS
мне интересно обсуждение, и я хочу для себя найти все стороны моего подхода. и я согласен продолжать, если мы будем обсуждать без обвинения друг друга в незнании, дополнять знания друг другу.Принимается.

вадяавторС точки зрения бизнес-логики никаких дополнительных операций. Прилетели изменения, вызывается метод Save, и то, что при этом обновляется кэш, остаётся за кадром.
При желании кэширование можно отключить, изменив одно свойтво в конфиге.

прилетели изменения-> начинаются дополнительные действия -метод save должны также обновится все объекты у каждого Объекта сервера приписанного к клиенту. это всё за кадром , но оно должно быть сделано.
Ну да, должен быть реализован как минимум репозиторий + декоратор для кэширования.
Но это же широко известные шаблоны проектирования, пишутся быстро, по сранению с разработкой основного функционала продукта.
Так что если Вы намекаете на то, что на это надо время потратить... То да, надо.
Но не много и это инвестиции в развитие проекта, пользы от которых в итоге как правило больше, чем потраченного времени.

вадяавторЧто значит "у меня данные не влияют, а будут влиять у вас"? Каким образом и на что влиять?
это "образно" т.е. если бкдет один объект привязан ко всем клиентам...
авторУ тебя N клиентов получают данные из БД с разной сортировкой, то есть в какое-то время имеем N объектов в памяти.
да получают , но не объекты , а набор( небольшая тонкость времени существования), в памяти как буфер обмена. передали (отправили клиенту) - тут же освободилось для другого.Набор - это и есть те N объектов.
У тебя набор, у меня View Model - одна фигня. Как ты и написал: передали (отправили клиенту), - и их считай больше нет.

вадяавторУ меня N клиентов получают данные из кэша с разной сортировкой, то есть в какое-то время имеем N + 1 объект в памяти.
Ну на один объект в памяти больше, зато быстро.
время жизни объектов в твоём варианте больше многократно. т.е пока клиент находится на странице -на сервере приложения существуют объекты с его данными. занятая память ограничивает число возможных подключённых клиентов. своп на диск - время, кторорое лучше отдать базе для своей работы с диском.
Опять делаешь не верные выводы. Время жизни объектов ровно такое же, как и в твоём варианте.
С чего вдруг многократно больше? При чём тут своп на диск? Откуда вдруг своп?
Плюс я уже говорил, что одним параметром в конфигурации можно отключить кэширование, то есть от моего варианта перейти к твоему.

вадяпрактически клиент плучил данные (из базы + серверное приложение произвело небольшую обработку для упрощения пказа на клиенте) и клиенту не нужна копия этих данных на сервере. полученный набор клиент может сам сортировать, фильтровать .
любые изменения отправить на сервер - необходимая (при необходимости ) обработка и внесение в базу. это минимут кода, минимум памяти для хранения . вопрос актуальности решается при необходимости актуальности данных именно не клиенте. т.е. клиент "подписывается" (почти , но не совсем метод Save) на получение изменений. и ему передаются только изменённые данные.А при чём тут кэширование? Я могу в твоём предожении заменить "из базы" на "из кэша", потому как у меня логика не меняется в зависимости от того, где хранятся данные. Такая вот гибкость.

вадяэто не большой объём. таким обрахом на сервере нет "постоянных" объектов для каждого клиента, сохранённых на время сесси. память выделяется по максимуму для сервера субд.
данная структура/методика реализована и работает.В моём варианте тоже нет "постоянных объектов для каждого клиента, сохранённых на время сесси", потому как я не о кэширование на время запроса писал.
Хотя short-term cache приветсвуется там, где есть возможность лишний раз не дёргать базу.

Сервер СУБД - это вообще отдельная от веб-сервера машина, так что память считай вся для БД :)

вадякак грубый пример - изменив ячейку в таблице - я предаю на сервер код команды, id записи, новое значение, метод=команда вызывет хранимку, которая и записывает/обновляет поле в таблице.У меня тоже есть подобные команды. Я вообще за CQRS :)

вадято же самое относится и к данным запрошенным из сторонних источнков - (как вариант действий) поиск в своей базе, при отсутствии (или по другой причине ) обращение к сторонним сервисам, получение от них , обработка , отправка в свою базу, отправка клиенту. на сервере нет объектов клиента, кроме данных о его сессии.
Вот если это завернуть в репозиторий + декоратор для однообразия вызова и обеспечения гибкости, то в первом приближении получится мой вариант :)

вадяавторНабор - это и есть те N объектов.
У тебя набор, у меня View Model - одна фигня. Как ты и написал: передали (отправили клиенту), - и их считай больше нет.
если это и их считай больше нет у тебя и есть, то мы просто говорим об одном на разных языках, всё остальное - дело вкуса и конкретной задачи.
Хм. Скорее я пытаюсь объяснить Вам, что Вы ошибаетесь в своих выводах, используя Вашу терминологию.

вадяавторУ меня тоже есть подобные команды. Я вообще за CQRS :)
тут есть разные методы работы с данными, моменты их сохранения в базе.
их надо применять по месту.
Это очевидно.