Hi Jim,
OK...let me think this through. Both tables store effective rate. This rate can change so you cannot maintain a simple key lookup. The same data is duplicated. Data-wise, is this not denormalization? I can see where in the entity models that the two physical fields may belong to different domains and, therefore, not falling into the category.
Jeez, just trying for the simple example :-)
>John,
>
>Got it, but you not showing any denormalization at all. A field is not redundant simply because it has the same name and similar data. To be redundant the two fields must have the same domain which includes (in addition to common datatype size etc) a definition. The definition must be duplicated as well.
>
>In your example, the price in the in te Rates table is defined as The curretn rate" and the one in teh calls table is "The effective rate at the time of this call". So, you see there is no redundant data and infact the rate being in bopth tables is normalized because those two fields are different domains.
>
>This is a good example of what I meant when I said that I have seen many situations where a developer claims that normalization is not always good and shows me an example of where normalization would break a system. It invariably turns out that the example was, in fact, normalized.
>
>Your two examples are both fully normalized in regards to the fields you discussed.
------------------------------------------------
John Koziol, ex-MVP, ex-MS, ex-FoxTeam. Just call me "X"
"When the going gets weird, the weird turn pro" - Hunter Thompson (Gonzo) RIP 2/19/05