> Is it logical to assume that any STORED value will not change if NO OTHER FIELDS it was calculated from changes? Yes. Not just logical to assume but assured by the documented behavior. > For example, can I change the algorithm for calculating a STORED field after inserting records, perhaps, by using an ALTER COLUMN command? That is not presently supported. The only column alteration supported is renaming, not adding/dropping/changing column constraints, triggers, or computation. > I'm thinking it better be impossible to do that or the database can become inconsistent. I'm sure you are not alone in such thinking, although I would put it differently: Doing that would be an implementation complication because in no case will database inconsistency be a tolerated side-effect. > Also, the STORED value is written to the database, right? Yes, of course. (There is no better place for it to be STORED.) > So why would I ever use a STORED field instead of a real (persistent) field if the physicals are identical? There would be several good reasons. Perhaps the most important is the clear expression of intent, right in the SQL DDL. The other has to do with enforcing the intended consistency. The DBMS will take care of getting that right across inserts and updates. There is more to the feature's value than just what must be stored. For example, you might change between STORED and VIRTUAL generated columns based on performance measurement, with no other changes on your part (but big changes in what the DBMS must do.)