Re: Thoughts on payment handling in 1.4.x

["Chris Travers" <..hidden..>]

On 4/27/07, Ed W <..hidden..> wrote:
> Hi
>
> Can I respectfully suggest that you missed the point that David was making?
>
> Sybase wrote some great DB design books that cover this stuff really
> well and no doubt there are other books.  But basically:

<snip>

In general, the process is similar to what you describe, but I would
suggest it is subtly different.  This is my understanding having been
raised by a math geek and having read as many of Chris Date's shorter
papers as I could find.

1)  Understand what information the software needs to work.  Build a
high-level logical model for that information.

2)  Build a relational algebra model for that information.  This is
your base physical model and is highly normalized.

3)  Due to implementation issues and limitations of SQL (which is not
quite semantically equivalent to relational algebra) some workarounds
may need to be applied.  However, many of these either a) break
semantic clarity or b) break the mathematic model and so should be
used sparingly.

Summary tables and fields are a good example of workarounds.

You are almost certainly correct about orders, invoices, and
quotations as being cases of the same object because they are
essentially phases of the same document.  There are some issues that
need to be addressed  in doing this merging, but that is the general
plan.

Personally, I would love to get to the point where we could enforce
NOT NULL constraints on most fields.  That may not be practical,
however.

Best Wishes,
Chris Travers