Re: Conditional Relationships ?

"Henry Craven" <GospodynNiemandt_at_nyet.net> wrote in message news:<5xCQ9.20259$aV5.53648_at_news-server.bigpond.net.au>...
> > At a wild guess, it looks like the Orders entity originally included
> > everything, then someone decided it would be a good idea to track line
> > items individually. This should have converted into to just the
> > reference order info (account no, date etc) in the Orders entity and
> > dynamic items like lines and delivery charges being moved to Order
> > Items. As it is, you have bits of the order value scattered over two
> > entities.
>
> Not in the least, again, as stated the business rules are complex,
> as is the real world model of the business, and the Handling of Orders
> vis-a-vis Invoices via differening methods is both logical and necessary.

Complex business rules are not an excuse for creating a messy data model.

> Not realy, An invoice is an invoice. it serves to do exactly what it
> purports to do. Bill for part or all of an order.
>
> Take Invoices:
> There are three possible scenarios:
> The invoice is based on the Total Order Sales Price.
> The invoice is based on the Sum of the Order Items and Anciliary Charges.
> The invoice is based on *some of* the Order Items and Anciliary Charges

All three cases can be combined together. Could Anciliary Charges be viewed as an extra "virtual" Order Item? Is order Sales Price a sum of the order items? If not what exactly is responsible for the difference? Could it be viewed as yet another "pseudo" Line Item? Next, do you mark somehow (for example, interpreting such a marker as a cupon applied, whatever) the items that don't add to the order/invoice total? If yes, then the order/invoice is always an aggregate of line items, and what is the problem, then? Received on Fri Jan 03 2003 - 03:44:56 CET