Re: [Ledger-smb-devel] For those interested in the CRM/Entity management

Just adding a point about normalization here. On 6/21/07, David Tangye <[EMAIL PROTECTED]> wrote: > See below. > > On 6/22/07, Joshua D. Drake <[EMAIL PROTECTED]> wrote: > > David Tangye wrote: > > > Its not crazy at all. Its correct analysis. And its not necessarily a > > > case of duplicate data

Re: [Ledger-smb-devel] For those interested in the CRM/Entity management

Josh, On reflection, see my previous post about intersects. Your post arrived while I was writing it. I think Chris, you and I are in agreement in this: Invoice addresses cannot be changed. The intersects I described will help ensure that if each address, once linked to almost any entity, invoice

Re: [Ledger-smb-devel] For those interested in the CRM/Entity management

See below. On 6/22/07, Joshua D. Drake <[EMAIL PROTECTED]> 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

Re: [Ledger-smb-devel] For those interested in the CRM/Entity management

See replies below. Actually, the way it will probably work is that there is a location table which includes all address info, a table handling a many-many relationship of locations to contacts Almost: the intersect we need here is between the Address to Customer intersect (as per your descri

Re: [Ledger-smb-devel] For those interested in the CRM/Entity management

David Tangye wrote: > See responses below. > > On 6/21/07, *Stroller* <[EMAIL PROTECTED] > > 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

Re: [Ledger-smb-devel] For those interested in the CRM/Entity management

See responses below. On 6/21/07, Stroller <[EMAIL PROTECTED]> wrote: On 20 Jun 2007, at 22:57, Ed W 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 sta

Re: [Ledger-smb-devel] For those interested in the CRM/Entity management

On 6/21/07, Stroller <[EMAIL PROTECTED]> wrote: > > On 20 Jun 2007, at 22:57, Ed W 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 think

Re: [Ledger-smb-devel] For those interested in the CRM/Entity management

On 6/21/07, David Tangye <[EMAIL PROTECTED]> 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 w

Re: [Ledger-smb-devel] For those interested in the CRM/Entity management

On 6/21/07, Stroller <[EMAIL PROTECTED]> wrote: > > On 20 Jun 2007, at 22:57, Ed W 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 think

Re: [Ledger-smb-devel] For those interested in the CRM/Entity management

On 20 Jun 2007, at 22:57, Ed W 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 dup

Re: [Ledger-smb-devel] 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 physic