Re: [SQL-Ledger-users] Q. on the TO-DO list. (Payroll update)

[R. R. <ri...@me...>]

On Thu, 10 May 2001, Linas Vepstas wrote:

> On Thu, May 10, 2001 at 03:23:21PM -0400, Wayne was heard to remark:

> > One enity that is present is a "Party", a party is
> > a person or and organization. One then associates
> > a relationship to a "Party". This will help to reduce
> > data redundancy. For example, if I have an employee
> > that happens to be a vendor, then the party is in
> > my DB only once , as a person, and I only have to
> > establish the relationship this enity has. That

> Bad example.

Bad idea, too.

The typical example would be a combined vendor &
customer.  The administration and logic involved doesn't 
seem to warrant the normalization.  Think about it.
Whose "owns" the data, the A/R or the A/P people.

When you normalize this junk you end up with a useless 
entity{ id, name, canonical_address }
which may be duplicated anyway, if there are variations
in name or address.

If A/P and A/R data are purged sometime, what happens
to the empty-nested entity.  If the canonical address
is not the same as the childrens, no one may be sure
who this is.  Yes this may be eased by sharing
the "id", but this has its own problems.


> employee is paying you kickbacks, I think that may 

More usual is putting someone on a payroll
as a kickback.

rob                     Live the dream.