Joe Thurbon wrote:
> Bob Badour wrote:
>
>> Joe Thurbon wrote:
>>
>
> [...]
>
>>>
>>> The first approach I can think of uses some sort of
>>> type-discriminator, in the employee table. This seems fraught with
>>> difficulties: how do you select the table to join on based on the
>>> type discriminator other than using multiple queries? How do you
>>> prevent nonsense data appearing, for example, in the 'commissiones'
>>> table for an employee whos type discriminator is is 'salaries'. So
>>> I'm guessing that a type discriminator does not work.
>>>
>>> The second approach is to have only one sub-type, but have two
>>> columns "Type", "Amount" whereby type gives a clue as to how to
>>> interpret the ammount (i.e. is it salary or commission). This seems
>>> problematic, since , in some sense, the domain of commissions is
>>> different to the domain of salaries (at least, according to my
>>> understanding of chapter 1 of "Practical Issues..."
>>>
>>> The other approach requires some sort of check constraint that
>>> simulates a kind of 'distributed key' (c.f. Darwen's 'Final Null In
>>> Th Coffin'). I can't really work out how this would be done
>>> relationally.
>>>
>>> So I'm stuck. Any hints or clues?
>>
>> What if you had an attribute that was a constant? How might that
>> change your analysis above?
>
> Do you mean that I had an attribute whose domain contained only one
> value, or an attribute that was the value (constant) in another domain?
That depends on what you mean by domain. Suppose an attribute has a
specific type and is constrained to a single value within that type.
Received on Wed Mar 21 2007 - 20:19:33 CDT
