Re: Practical considerations of dealing with two meanings of NULLs

Doug_McMahon_at_yahoo.com wrote:
...
>
> I'm no expert on this either, but you don't really have to be up on it
> to understand the main use cases.
>
> Re. inheritance, if you ignore methods/overrides/etc. and focus solely
> on the data model implied, you have an application model wherein one
> type of data object has all the properties of another type (or types,
> if multiple inheritance is allowed), plus some additional properties.
> For example, there is a basic type of PurchaseOrder, but then there is
> a BlanketPurchaseOrder with additional properties. You map these
> relationally in many ways, but with some unsatisfying consequences.
> One obvious mapping is a distinct relation for each sub-class with a
> full set of attributes, but this requires duplication of the common
> columns and constraints, leaving you with perpetual redundant
> maintenance. You are also oblige to maintain a union view over all
> sub-classes at each level of the hierarchy, in order to "see" all
> instances of that sub-class. This is very painful because the views
> have to be modified whenever a class is added to the hierarchy.
> Another mapping is one relation per sub-class with just the extra
> attributes for that class. The cost here is the need to join
> (possibly many times in a deep class hierarchy) whenever you want to
> recreate whole instances of the sub-classes. Either way you have
> difficulty producing a view that materializes complete instances at a
> super-class level (i.e. a view that not only produces all the
> superclass attributes, but also produces a "raggedy edge" of
> attributes drawn from the instance-specific sets - unless you allow
> nulls.
>
> Re. life-cycle, the issue here is that constraints may vary as an
> object proceeds through various states. For example it may be
> perfectly acceptable for an order to lack a shipping address, payment
> information such as a credit card, etc. when it is at the status of
> just being a quote. But if the customer decides to place the order,
> you now require those attributes to proceed. Now in that simple
> example, you could use multiple relations to assert the correct
> constraints for each state. But now try scaling that approach up to
> a complex business object that has a great many intermediate states,
> and you begin to see the problem.
>

Thanks very much for that detailed reply which explains much of the lingo for me.

p Received on Fri Aug 10 2007 - 17:58:04 CEST