>Hello! Generally speaking, regarding performance, is "expensive" having >calculated fields?
>Not complex ones, I mean this type of thing: > >... COMPUTED BY (cast(qty * price * tax / 100 as money 2)) >So far I don't notice any difference but I'd like to hear opinions about >whether is a good >idea using them. > >Probably having a real field, maintained with a trigger is better? I don't >like having redundant >data in my database, but I'm note sure what is the better option: waste a bit >of space or >(probably) decrease performance?? ? I've heard (don't remember who said it, and since I don't use calculated fields much myself, I cannot tell how reliable this information is) that calculated fields ought only to refer to the current record, i.e. not a different table or different record in the same table. So, as long as qty, price and tax all are part of the same record as your COMPUTED BY value, this ought to be fine. If they are stored in different lookup tables, then a view or a trigger maintained field may be preferrable. Hopefully, others will verify this or tell that I'm wrong. Set
