вадясами базы имеют возможность держать таблицы в памяти.
и при перезагрузки сервера переписать данные с диска в память нет проблем, да и изменить данные в таблице в памяти и её оригинала на диске тоже нет проблемы.
-1
Т.к.:
1. Кроме БД и скорости на стороне БД есть еще JDBC. Который тоже:
1.1. тормоз еще тот
1.2. в ряде случаев имеет нехилые расходы на ресурсы (например по памяти)
1.2. замусоривает сеть (если БД на другой машине, в случае, например, cloud и аренды серверов может оказаться вполне себе тарифицируемым ресурсом).
2. Ряд популярных СУБД слова Prepared Statement знают только по названию. Ну... или делают вид, что знают, а на самом деле каждый запрос парсят по новой. Что тоже вполне себе работа.
3. Если хранить в ОП Java - ряд операций будет почти мгновенно. Возможно, даже, можно будет не получать java.sql.Connection - соответственно нагрузка на БД и кол-во экземпляров БД в памяти может быть меньше в разы (при connection pool). А экземпляр dedicated потока/процесса БД - нехилая себе нагрузка на ресурсы системы.
etc.. etc...
А насчет "in memory table" это достаточно редко используемый механизм. Т.к. нормальные БД все равно горячие блоки держать в буферном кэше. И ситуации когда их специально нужно закреплять в памяти очень редки.
Мало того, например "in memory" в Oracle - это решение для OLAP . И я не уверен, что использование этой возможности "не глядя" в OLTP системе хорошая идея . Любителей пользоваться фичами не подумав, например создавать Bitmap индексы в OLPT системах - встречал. Когда начальство узнала, кто его создал - человек за пару часов лишился работы.
IMHO & AFAIK
вадятак што кеширование этой прокладки может оказаться излише.
Любая оптимизация может оказаться излишней. И почти любая оптимизация не оказывается бесплатной.
Т.ч. как в анекдоте: "проверил, работает? да... тогда только ничего не трогай"
Valery ShiskinДа и мудухаться с тем, что одни данные в базе, а другие, из той же базы, в каких-то массивах и коллекциях в памяти не очень хорошая идея.
Поддерживаю.
Если проблем с производительностью нет - то не стоит себе и коллегам создавать проблемы на ровном месте. Если есть - тогда нужно думать.
