Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> comp.databases.theory -> Re: Derived column design question

Re: Derived column design question

From: Gene Wirchenko <genew_at_ucantrade.com.NOTHERE>
Date: Tue, 29 Nov 2005 14:32:02 -0800
Message-ID: <ackpo1hup8gmpdm0gsd27a76d8j0643euf@4ax.com>


On 29 Nov 2005 10:47:00 -0800, ijgla_spamoff_at_clas.ucsb.edu wrote:

>A design problem in my organization similar to the following has
>arisen. (The example below is a bit contrived, as I would prefer not
>to discuss our exact situation).

[snip]

>My feeling is that a more suitable design would be to eliminate the
>GrantDiscount column, and instead create a DiscountOverride column that
>can take three possible values:
> 0 - Default. Grant beer discount only if average is above 200
> 2 - Force. Grant discount regardless of the bowler's average.
> 3 - Deny. Deny discount regardless of the bowler's average.

     I would go with something like this.

>This way, once a bowler has been either allowed a special dispensation
>or specifically denied the discount, their special status is perfectly
>clear. In the original design, there would appear to be some
>uncertaintly as to how to handle the situation when a bowler's average
>crosses the 200 threshold in either direction, as it could be
>potentially unknowable as whether the GrantDiscount column had been set
>manually (perhaps several months earlier) and should continue in its
>present state regardless of current average, or if crossing the 200
>boundary should automatically cause a change to GrantDiscount.

     I agree with your reasoning.

>The designer of the system maintains that since the current data entry
>person knows her customers well enough, this shouldn't be a problem.

     So why is he all for creating the problem?

>The design is that GrantDiscount column would be automatically set
>based on the bowler's average, and that each month it would be up to
>the entry operator to reset GrantDiscount manually as appropriate. But
>my feeling is that a) why introduce potential problems where they are
>not necessary?, and b) what happens when the entry operator leaves the
>bowling alley and is replaced by a newcomer? Basically, it doesn't
>seem desirable to create a column whose semantics are unclear, based on
>the assumption that the user of the system can assign the proper
>meaning based on information extrinsic to the system itself.

     Quite.

>In order to further my discussions with the designer of this system, I
>would very much appreciate:
>
>1) Any comments on the two designs outlined above, or possible
>alternate designs.
>
>2) Any possible references to scenarios of this kind in published
>database design literature, which I might be able to show to the system
>designer. (Is this possibly an example of a well-known design
>consideration that I might be unaware of, such as
>Don't-Allow-Entry-Into-a-Derived-Column?)

     Your name is a bit long, but it will do fine.

Sincerely,

Gene Wirchenko Received on Tue Nov 29 2005 - 16:32:02 CST

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US