Re: VAT rate or VAT amount as a column?

Emily Jones wrote:
> Customers are charged for a service (a training course) and at the moment
> always plus VAT.
>
> At the moment I've got, something like:
>
> CustomerCourse:
> ID, name, ... Fee, Vat
>
> where vat is an amount calculated using the current rate. I'm not storing
> the total, as that's derived.
>
> Maybe I should store the VAT as a %, because the amount is really derived.
> And if I've got the capability to have a different VAT rate for each
> CustomerCourse record, then there's the flexibility that I might need, if,
> for instance there is a reason to charge a particular customer a different
> rate of VAT.
>
> Opinions please.
>
> Emily Jones
Considering we are in the process of *easing the pain* on SQL DBMS miserable implementation perspective, your best shot is to keep you base table with NO computed columns and add a view with virtual function based computed columns...(forget about triggers BS applicative solutions they are hell to maintain, debug and troubleshoot)

When the response time gets hindered to an unbearable point, then consider using the schema binding mechanisms to store the views physically for faster retrieval .. In ORACLE, they are called materialized views and in SQL Server indexed views...They totally break logical independence but at least they can be easily identified for troubleshooting. At least you can keep your initial schema intact for modification and evolution...Hope this helped... Received on Sun Aug 06 2006 - 18:25:42 CEST