[ Date Index ] [ Thread Index ] [ <= Previous by date / thread ] [ Next by date / thread => ]
On 22/02/13 13:34, Kevin Peat wrote:
Ah, I should have explained better. In Paradox (and Access as far as I know) calculated fields are never stored anywhere. They appear in a form (not in any table) and are calculated 'on the fly' as you go through the records. Also, when a report is prepared any calculated fields are again calculated as the report is being printed but not stored anywhere. That is why the relevant tables do not include columns for the results of any calculations.I am guessing that Postgres not directly supporting calculated fields in the database is because it is bad form to store derived data in a relational database. Probably the only reason to store calculated data in the db is if the calculation is too slow or difficult to do at the time the data is required. If you are just calculating some percentage of a column or doing some straightforward maths then you should do it when you extract the data and not store it in the db.
I know that it is not a good idea to store calculated data in the DB and this does not happen in Paradox. However these fields are essential in most databases, and they appeared in almost every database I wrote. And, as I said, this was available and working 20 years ago in Paradox. But such a system is still to appear in Linux, as far as I know.
Neil -- The Mailing List for the Devon & Cornwall LUG http://mailman.dclug.org.uk/listinfo/list FAQ: http://www.dcglug.org.uk/listfaq