Я вот думаю, что если оставить в PostgreSQL все как есть, но при запросах закидывать, к примеру, в Redis (используется для некоторых нужд). Прошел запрос на 1-ую строчку, закинул туда, дальше берется из Redis. Так и с другими строками. Если что-то не будет запрашиваться, не попадет, не будет ресурсы тратить.
Ну и через cron раз в сутки очищать данные в Redis, чтобы в случае изменения каких-либо данных в таблице PostgreSQL не было различий.
Или это уже как-то...?
Cach: если не связаны, то лучше полностью вместе с логикой разделить по компонентам, где будет сама форма, обработка формы и запрос на back с информацией. А в нужном компоненте просто подключить. Таким образом кроме легкого чтения кода у вас всё находится по, так называемым, "полочкам" и в любой момент можно перекинуть форму из одного раздела в другой, путем перемещения селектора
Николай Купстас: мне он тоже не до конца нравится, конечно...но в одном из проектов использую и всё неплохо работает. Скорее всего вы RC версию использовали, потому что я по глупости тоже вначале поставил её, увидел кучу багов, расплевался на нее. А потом увидел версию в зависимостях и поправил.
Ладно, постараюсь набросать
Николай Купстас: баги? вы скорее всего использовали версию primeng? Которая RC? Естественно будет багнутая) 2.*.* версия стабильная. Много переплетений и прочего, потому что большой функционал, который и на сортировку и на фильтры на пагинацию и то же самое только для серверной пагинации
Николай Купстас: Посмотрите вот это - PrimeNG (datatable). Попробуйте, почитайте. Удобная реализация. Я не говорю использовать этот пакет, а взять для себя вариант и принцип реализации
