Sufficient reason to de-normalize a field?

From: Earl (brikshoe_at_newsgroups.nospam)
Date: 06/15/04 

Date: Tue, 15 Jun 2004 01:27:55 -0500

One for the gurus:

I've got a great database design. Normalized as well as I can in any event.
However, I have a form where I save payment information and the payee might
be an ad hoc individual -- that is, it may be someone who does not exist in
the database until such time as the payment is made. Thus, they could not be
bound with say, a customerID or an employeeID, as I might do in any other
circumstance. On the other hand, the payee will probably -- in most cases --
actually be an employee.

Furthermore, I have a stored procedure which spits out a SUM of payments
made to employees. Thus, I need to pass in as one of the parameters the name
of the payee when it is an employee. Yet the payee must be precisely named
or else the input parameter would not find a match.

My plan is to use a combo populated with the employees, yet allow the user
to input ad hoc names also and save the text value of the combo into the
field in the payments table. Unfortunately, this still sticks me with the
string search parameter.

In all other instances I've been able to tightly hold to the design of only
saving ID numbers into subordinate tables. Is this a situation that would
allow the likely redundant data that I propose?

Relevant Pages

  • Re: design problem
    ... Revealing the existence of strategies, both interface and each ... and the fact that employee has only one payment model ... that you need to have many payment models active at the same time for the ... need to move employees from one payment model to another, ...
    (comp.object)
  • Re: use expression as field name in query
    ... Employee As E ... You will have to type out this query ... Database Normalization Tips by Luke Chung ... This article covers the basics of database design including normalization, ...
    (microsoft.public.access.queries)
  • Re: A funny thing happened...
    ... one only shows what the payment was for and not who made the purchase on ... reimbursing against a receipt, the "proper way" is to 'look through' who ... For example an employee may buy stamps, ... providing the employee with either earnings or expenses because the employee ...
    (uk.rec.scouting)
  • Re: Downcasting - whats the problem?
    ... In order to regain that static type information later, ... The employee holds an object that describes it's pay classification. ... One represents a salaried payment, ... HourlyClassification holds on to a set of time cards. ...
    (comp.object)
  • Re: A funny thing happened...
    ... recording in the books who the payment goes to, ... reimbursing against a receipt, the "proper way" is to 'look through' who ... I record who I actually paid, who the supplier was and what it was that was purchased/ paid for. ... For example an employee may buy stamps, ...
    (uk.rec.scouting)