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

Re: For those interested in the CRM/Entity management



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.
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)

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. So use them, and send and store and later retrieve exactly that. Finding them via keywords will require links/indices to them. 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.

On 6/21/07, Ed W <..hidden..> wrote:
I think we are all agreed that snapshotting the invoice is a requirement.  But:

- lets assume that most invoices contain the same address time and time again,
- hence we start thinking about normalising that address record rather than duplicating it endlessly
- this leads us to something like "address" being some kind of abstract object
- we clearly need to know the "customer" object that this address matches to - otherwise how do we know that this "customer A" is or is not the same as another invoice to "customer A" (or even the same as "customer B", only we changed the name at some point)
- So we now seem to need a bunch of address records which can be linked to by an invoice, and have a foreign key back to the "customer" record.

Seems like if you read back a few emails to my previous post that we are back full circle to a model which looks something like contacts with a structured history trail?  You can look at it from either direction, but I think it's a similar model either way?

Are we all on the same page now?  I think it's helpful to review the kind of "use cases" that I sketched out and perhaps dream up some more - I think it helps figure out if we have got the model right if we see that we can do all the operations which will be finally needed.

Ed W

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Ledger-smb-devel mailing list
..hidden..
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel




--
The Last Great Frontier is in Your Mind