I have a use case that some external 3rd party vendor services send our service an item with price and a time range, the data schema includes :
it means the price for this item from this vendor is
$price value during the time interval of
Our service needs to support
- given a item id, query for all the vendors current price
- given a future timestamp, item id, and vendor id, query for the price
I consider to create materialized view of the database because I don't want to hit the database too frequently for a large amount of queries.
From the doc in oracle,
A materialized view is a replica of a target master from a single point in time. The master can be either a master table at a master site or a master materialized view at a materialized view site. Whereas in multimaster replication tables are continuously updated by other master sites, materialized views are updated from one or more masters through individual batch updates, known as a refreshes, from a single master site or master materialized view site,
It looks like I just create a table locally in memory and it's a "copy" of the remote database. The concerns of using view are:
- it takes much memory usage, and
- because the database is updated often with different vendor new feed, and it is updated when the price is invalid (out of the time range), using materialized view means I have to refresh often to get the latest view, so it will not reduce network loads as mentioned in pros of materialized view.
None of the two concerns above is listed as potential cons of materialized view. Does it still fit for my use case then?