Re: Modeling Address using Relational Theory

Marshall Spight wrote:
> dawn wrote:
> > David Cressey wrote:
> > >
> > > It's "principal insurance policy" versus "supplemental insurance policy".
> > > These are frequently stored side by side in a single table. In almost all
> > > cases, the semantic difference between the two columns determines which
> > > column on wishes to use in a query's conditions.
> >
> > Good example. In this one the ordering is not with numbers in the
> > attribute names, but with ordering information in those names.
>
> Sure. But if he'd used the names "policy1" and "policy2" with the
> exact same semantics, would it have been any different?
>
>
>
> > Unfortunately (my opinion), this also seems to make a difference in the
> > conceptual data model. Those who have been trained only in the
> > relational model push that thought process on SMEs, even in cases where
> > the end-users might initially think in terms such as "then we have
> > insurance policies, up to two of them, and we submit to the first and
> > then only submit it to the second only after the first denies payment"
> >
> > Even if we do an implementation in an RDBMS, it seems that the
> > conceptual data model could be well-served with list structures.
>
> This doesn't strike me as a good place to use lists.
>
>
> > Because AddressLines only has a cardinality of 2, it is not a big deal
> > to make it two separate lines, but the only reason I see to do so is
> > that the target environment has no list types.
>
> What would be the motivation to use lists? It would be if
> there were list operations that we were going to perform on
> the data.

Precisely! Pretty much every time we want to provide a representation of these data for users, we want addressLine2 to follow addressLine1. We want to use the ordering operations. Why put such logic in the application each and every time we have a need to represent the data for people to read? It just comes along for the ride in the systems I work in. There are no algorithms in the code that say "if there is a line3, then output that, otherwise output the city line". The developer just says "now the AddressLines" and if there is one line, that's what goes out, if two, then that is what goes out.

> If there were, then a list would make sense;

good, so do you agree now?

> if not,
> then it would be the list advocate that was guilty of having his
> or her preferred data structure intruding into the logical model.

agreed

> (Although here I guess our differing experiences may color our
> perspective, because I haven't seen list operators used on address
> lines

oh yes you have, come on -- haven't you ever seen ordering logic to order the second address line after the first? And you know which one goes first too, because you put that 1 there so you would know how to code your algorithm.

I'm in need of some agreement on this one -- it isn't merely a perspective or definition issue. Can you step in my direction a little? --dawn

> and I think I remember you said you had?)
>
> I still agree, though, that SQL suffers for its severely limited
> ability to handle ordered data.
>
>
> Marshall
Received on Thu Sep 01 2005 - 18:24:38 CEST