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