Re: For those interested in the CRM/Entity management

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

Just adding a point about normalization here.

On 6/21/07, David Tangye <..hidden..> wrote:
> See below.
>
> On 6/22/07, Joshua D. Drake <..hidden..> wrote:
> > David Tangye wrote:
> > > Its not crazy at all. Its correct analysis. And its not necessarily a
> > > case of duplicate data. Its a snapshot of an event whose information is
> > > often represented by the same data values each time. That is not
> > > duplicate data.
> >
> > No it is entirely incorrect. Proper normalization with proper keys and
> > proper revisioning will allow distinct and exact representations of the
> > invoice data (if not the template which is actually irrelevant)
> regardless.
>
> While what you are saying is correct, here ...

With all due respect, I side with Josh here, but admit that people may
be talking past eachother.  People refer to normalization as two
things:  1)  Following of "best practices" of data modelling and 2)  a
mathematical process of ensuring that the relational data will be both
meaningful and capable of representing any data you can possibly need
to store.  For purposes of this post, please see normalization as the
latter.  "Best practices" in my opinion occasionally require violating
and as long as this is done in mathematically sound ways, I do not see
that as breaking normalization.

In this case, normalization is absolutely essential and denormalizing
*always* adds more problems than it solves.

However, there are two other possible issues that are also being discussed.
1)  How does the invoice data need to be stored relationally (and it
*does* need to be stored relationally)?
2)  Do we need document management capabilities in the software?

I would vote "yes" for the second, though it may be some time before
we have it.  There are a few corner cases where not storing the
document as the document itself could be problematic.

For example, regulation-wise, you have to have a copy of the invoice.
After an invoice is issued you discover a typo in the address.  So you
correct that typo in the db.  The invoice as reprinted would have the
corrected address.  I don't know whether this is sufficient for all
regulatory purposes.

Making document management a core part of the application makes a lot
of sense.  However, at the moment, I think the first approach is to
get the code and basic data model under control first.  This is an
immense undertaking already.  And while I certainly would like to see
this on the road map, I would not want to see it detract from our
ability to get rid of the more brittle parts of the application first.

Of course, if others want to help, that would obviously expedite
things.  At the moment, my suggestion would be to try to help get this
moving *after* we get the financial logic nailed down in 1.4.

In short, it is not a matter of if I think it is good or required but
rather when it is likely to be best to undertake this.

Best Wishes,
Chris Travers