[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: For those interested in the CRM/Entity management

On 6/21/07, David Tangye <..hidden..> wrote:

I have followed this thread with amusement. We went through all this 15
years ago, and I am sure others did 15 years before that. The answer is
still the same irrespective of the technology du jour.

Without boring you all with pages of waffle:

1. In system analysis and design, logical and physical modelling: understand
the fundamental differences between summary/current state data, that is the
forte of relational databases and snapshots of events of importance (eg
invoices and other legal documents) that is not. Also think objects and OO,
not relational.


On one level, it is all data.  It is just a matter of structuring it.
I would argue that setting this up so that invoices can be searched
means using the relational model.  Note that addresses are separate
entities in 1.3, so they can be attached to anything.  However, see
below.


2. Beware the hammer mentality. (I got a hammer. I'm good with it, so I even
fasten screws with it.) You CANT put your lunch into a relational database.
(DT 1992)


One of the reasons why we have these sorts of discussions are
important is that we can properly vet ideas.



Invoices are best snapshotted exactly as they were when generated. Currently
their is good technology to do that, eg as Acrobat or postscript or jpg etc.


Actually, I like this idea for a couple reasons.   First, it provides
an ability to reprint the invoice exactly even in the case of, say, a
change of logo.   I.e. invoice-as-document is stored along with the
relational data.  Jpg is a bad format for a printed document.  I would
recommend either PDF or Postscript.

I think we need to try to store all information required to regenerate
the invoice data exactly in the db though.  This is extremely
important for reporting purposes.


So use them, and send and store and later retrieve exactly that. Finding
them via keywords will require links/indices to them.


And of course, being able to do a report on all invoices shipped by
zip code prefix (or city) would require that all the address
information be stored in the db properly anyway.


Designing all manner
of convoluted and amazing relational and non-relational structures in an
RDBMS to handle them is flying in the face of what relational databases can
offer alone.


While I agree with you about the utility of storing invoices as
documents in the db, I would suggest that it is also orthogonal to the
question of address storage.

I.e. I think we really need to ensure that we *also* have access to
all the data of the invoice in the db.

Best Wishes
Chris Travers