Re: Modeling Address using Relational Theory

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.

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.

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.

> > 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. 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 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.

And don't forget I said:

> > I still agree, though, that SQL suffers for its severely limited
> > ability to handle ordered data.

HTH Marshall Received on Thu Sep 01 2005 - 19:22:05 CEST