4 ms·
I've worked in an environment where 3 applications accessed the same database, one of the applications wasn't really maintained. Having computed (stored or vir
by perlgeek 1y ago
I've worked in an environment where 3 applications accessed the same database, one of the applications wasn't really maintained.
Having computed (stored or virtual) columns would've been awesome.
The use case isn't really "multiply a value by 12", but more like "we have a single boolean is_active column, and want to migrate to a more extensive status model" or "migrate from an is_active column to a (begin, end) timestamp tuple" or so.
With a virtual column, you can present a read-only, compatible column to the legacy application, while the other applications can use the more detailed, new columns, without having to keep the legacy column in sync.
- chao- 1y agoSimilar experience here. I have used it to make several legacy migrations much smoother.
- matt-p 1y agoI think it /can/ also be to 'multiply a number by 12'. For example lets say I'm a supermarket, who gets their order data out of a 20 year old IT system and as a result I've got a orders table which has a id, user_id and data column with an array of 'sku, price and qty'. If I regularly want to query/sort/filter based on total order value the easiest and most performant solution absolutely is to use a computed column.
- tux3 1y agoIf you need to retrieve the values, the fastest would probably be a stored generated column, not a virtual computed on the fly. In case you only want to filter without returning values, you could also index directly on the expression without needing to add a stored generated column with an index on it