Re: Anybody for Automated Comparative Normal Form?

Kenneth Downs wrote:
> This is correct but incomplete. The goal actually is to reduce the
element
> <violates constraint> to something that can be specified without
using
> code. Put another way, you are not allowed to automate a column by
> defining a SQL statement or expression for it. The only tools
available
> are the fundamental operations of addition, multiplication and so
forth
> (also functions like coalesce, sin, etc.), aggregation functions, and
pulls
> (where you fetch price from the items table).
>
> Values of arbitrary complexity can be generated through composition.
> Extended_price = price * qty, and line_discount = extended_price *
> line_pct, and line_final = extended_price - line_discount. Then the
order
> header table has Line_total = SUM(details.line_final). Then the
customers
> table has Orders_total = SUM(orders.order_final) and Invoice_total =
> SUM(invoices.invoice_final), and Total_exposure = Orders_total +
> invoice_total. Now you define a constraint that total_exposure may
not
> exceed credit_limit.

Ah, well I am not at all sure that that goal is achievable (or desirable, but that is a matter of opinion!) You are stipulating a simplified subset of SQL: are joins allowed? If not, how do you get the SUM(orders.order_final) for the customers table - by following foreign key trails? If so, what do you do when there is more than one trail?

I would not want to dispense with the full set-processing and query optimising power of the DBMS in this manner. Received on Fri Nov 19 2004 - 16:22:06 CET