Re: Practical considerations of dealing with two meanings of NULLs

On Aug 9, 2:38 pm, paul c <toledobythe..._at_oohay.ac> wrote:
>
> While looking forward to what Bob B might have to say about this and in
> spite of being rather ignorant of today's class-inheritance and
> life-cycle methodologies (eg., I don't know what a constraint variant
> is), to me it does have the ring of a true tale from the trenches, which
> we don't get much of here.
>
> p

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. Received on Fri Aug 10 2007 - 17:11:27 CEST