Hello Again,
Yes, you're right. What I am talking about is a material view. Since
I'm not sure yet which would be best (Material View Vs. Normal View) I
will first try a normal view and if it turns out to be too slow I can
always switch to a Material View.
Thanks!
---(en
> Hi Brandon,
>
> Thank you for your response.
>
> Yes, I see what you mean when you say that I can list Qty in signed
> integers and use a view. Good point.
>
> But I'm not sure as to using a view vs using a permanent table updated
> by triggers. It seems we are dealing with the clasic tradeoff
* "Qty")
> END
>, "UserID"
> FROM "Transaction" NATURAL JOIN "TransactionItem";
>
> As far as speed, speed is always an issue. PostgreSQL is going to
> perform better than Access, but don't use good performance as a crutch
> fo
le to take it too far. There is a
time when de-normalizing a database will significantly improve its
performance even if it involves duplicating data. 4NF is not the goal
of DB design, having a usable database is. Knowing when and how to
de-normalize is much more difficult than learning to
Hi Brandon, thanks for answering.
The information regarding a transaction is stored on two separate
tables due to normalization. The first table stores general information
regarding the transaction like Transaction number, date, customer ID,
type of transaction, userID etc... The second table stor
It just occurred to me. The purpose of normalizing the information and
having it stored on two separate tables is defeated if I have another
table that contains the same information but in an un-normalized
fashion. I would end up with two copies of the same information, one
normalized but not ready
Roman --
You can certainly use a trigger to track changes (as well as creating an audit
trail and enforcing rules); performance on inserts,updates and deletes will
suffer accordingly since there's extra operations involved, but it definitely
be a winner on the other end in generating reports an
It's not clear to me how your data is organized or exactly what you're
counting. If I understand you correctly, yes, you could use triggers to
maintain a table in this manner. However, why can't you simply use a
SELECT query using the SUM() or COUNT() aggregate functions? If the
queries are slo
