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 <[EMAIL PROTECTED]> 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
[email protected]
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
--
The Last Great Frontier is in Your Mind
-------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
