SQLite Forum

Serious problems with STORED columns
Login
The idea of a generated column is that you have something which can be determined solely from the other columns in that record. So the value doesn't _really_ count as useful data, because it's completely dependent on other fields.

Example: Say for example you have a country table, and one of the fields, "geometry" is the shape of the country. So you're storing the entire outline of the country for display.

Now let's say in the same table you have a "surface_area" field and a "border_length" field. Well, each of those fields can be completely determined by the geometry field, and a bunch of calculations. So you can define them as calculated fields. If geometry gets changed, the calculated fields will change with it, and you don't need separate update statements, and can't accidentally update one and not the other.

You might used a stored field for something like the surface area. You don't want to go through the entire geometry of Russia and calculate the surface area every time you select that record, because it's an expensive operation. So marking it as stored means that the calculated value will get stored in the table/file. So if the geometry field isn't changing then you don't have to do all those expensive calculations again because it was stored for you to look at. But if the geometry field does get changed, then SQLite will again automatically do the calculations and store the new result for quick reference until geometry gets updated again.

The dump command in the CLI doesn't output those stored calculated fields because they're supposed to be able to be calculated from the other fields in the record. So it's "avoiding wasted storage space" if you will. It means it might be slower on a restore, because all those calculations have to be done again, but it's not "lost data" because it's supposed to be completely deterministic from the other fields.