[perlgeek]

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.

[matt-p]

I 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]

If 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

[chao-]

Similar experience here. I have used it to make several legacy migrations much smoother.