Re: Modeling Address using Relational Theory

Marshall Spight wrote:
> dawn wrote:
> > Marshall Spight wrote:
> > >
> > > 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.
>
> The stuff that you're describing above I consider user interface
> issues. Say we have datum A and datum B, and widget A and widget
> B. Whether we put widget B below widget A or beside or on another
> page doesn't affect the semantics of datum A and B.

I'll agree with "below" being a matter of representation, so I should say "after" instead. It is not the representation, but the "what is this?" question. If you are satisfied with clues to the what-is-this being in the names of the attributes so that developers know to code algorithms accordingly, then that seems like a trade-off for something suboptimal, so I hope you are getting something for it.

>
> When I said "operations" I meant functions: you have a bunch of
> functions that take lists as operands (and possibly return lists.)
> Think java.util.List. If we found ourselves doing insert, delete,
> etc. on address lines, THAT would be a case for calling them a list.

Because "order" is inherent in an ordered list, the operand on the list is simply the identity that corresponds to what would otherwise have to be coded as order(addresLine1, addressLine2). The fact that it is an exceedingly simple function that replaces the hand-coded (not even coded to the dbms!) ordering function you would have with addressLine1, addressLine2 should not cause you to disregard it. That is the beauty of it, brother!

>
> Much earlier in the thread:
>
> > > You don't ripple delete on
> > > address compononents,
> >
> > Maybe not done frequently, but if you do have 3 addressLines and you
> > change an address when someone moves from an apartment, for example, it
> > does happen.
>
> This would be an example of a good justification for calling
> address lines a list.

I agree, but even more compelling is that the function f(a) = a gives you so much. How cool is that?
>
> > > If there were, then a list would make sense;
> >
> > good, so do you agree now?
>
> I think we have significant common ground at this point. In
> fact, the only area we seem to be far apart on is whether
> address lines are likely to require list operations, which
> is application-dependent anyway and maybe therefor not
> very interesting.
>
>
> > > (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?
>
> Simple screen layout is not sufficient to qualify.

I agree. It is the ordering (in the abstract).

> Consider that
> *every* structure that was ever presented on a screen had to
> have some layout to it; that doesn't mean the fields of the
> structure have some natural order.

I'm good with that. But in this case, we are not talking about a decision that really has to be made every single time someone is working with addressLine1 and addressLine2 where they choose some ordering for the two values. There is an ordering in the meaning of these data.

>
> > 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
>
> I think I have. I think we're in agreement that it's what you
> do with the data that makes the difference, and that that's
> application dependendent. I think we agree on the presence of
> list operations as being a strong indicator that something should
> be of list type; we both agree that insert and delete are list
> operators (I think); we only disagree on whether presentation
> by itself is sufficient to qualify as an operator, and I still
> hope to convince you its not. :-) That's actually a lot of agreement.

Yup, I'll take it. Now I'd like agreement that the identity operator on lists really does help justify their use.

> And don't forget I said:
>
> > > I still agree, though, that SQL suffers for its severely limited
> > > ability to handle ordered data.

And I sure do appreciate that! I haven't checked on Dataphor or even re-read Tutorial D information to find out how they handle ordering. Perhaps they have already figured out how this really SHOULD be handled in relational theory. I don't see anything today that gives me warm fuzzies about how SQL-DBMS's handle addresses and a whole bunch of other things that are more easily identified as list. Plus I have some irritation by the way this has caused youngsters (those only taught relational theory) to do even a conceptual model of such data.

Cheers! --dawn

> HTH
>
> Marshall
Received on Thu Sep 01 2005 - 23:03:19 CEST