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

[Roderick A. A. <raa...@ti...>]

On Thu, 10 May 2001, Wayne wrote:

> Hi  Steve,
> I was going to hold off on offering some suggestion
> until I understand what is going on in the code, but
> if anyone is going to develope the payroll I would
> suggest that we look at the data model a little further.
> The suggertion I'm going to make is not my own. If
> folks like to purchase the book "The Data Model
> Resource Book"  ISBN 0-471-15364-8

There are several others that address the same issues including "Data
Model Patterns : Conventions of Thought", and the whole Case Method
series.  Data design can be a very touchy issue so I tend to avoid it.
It is very tough being a Programmer and a Database Designer at the same
time.  And the people we design for sometimes either can't get over the
hurdle of data normalization or just like their 3x5 cards, file folders,
and napkin notes.

> you can see where I'm coming from.
> This book has good data model for  a business.
> 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
> relationship would be "employee" and  "vendor".
> I know I'm leaving alot of description out, but
> I think if people purchase the book it would give
> the group a good model to follow.

I'll have to look into this one.  I have theoretical books but having a
nuts and bolts will be nice.

> Later.
> Wayne
> P.S. I should also point out that I'm learning Perl
> to convert the system to Python. I hope that
> doesn't offend anyone.

Doesn't offend but I'd suggest you learn Perl then decide if you'd be
gaining anything by going to Python.


Rod
--