Re: Modeling Address using Relational Theory

Ha ha! I'm posting on this topic again. Clearly I have some kind of brain disorder.

dawn wrote:
> Marshall Spight wrote:
>
> I might agree if it were the case that you could collect these data
> from a user in any order on an input form. I can put State/Province
> before City and people might have to change their habits, but they will
> be able to adjust much more handily than if I put addr2 before addr1 on
> a form. Gene was right when he said that you could code this as a
> single value and use markup of some sort to identify the second value
> from the first. Putting them in the opposite order would make a whole
> lot less sense than putting other values in an order that is not
> common. It would be more like having the user write a Word document
> with the last line on top.

It is paragraphs such as the above that make me feel that you aren't keeping sufficiently clear the distinction between the UI widgets and the fields of the struct/row/class/whatever. The UI has a canonical presentation order. The struct does not.

> If doing a "dump" of values for almost any purpose, most values can be
> in any order, including PostCode and State/Province, but addr2 must
> follow addr1.

This is not true in any system I've ever worked on. Again the different experience.

> > > Whether it is the UI or a web service or any other target for these
> > > data, the logic taking the attributes values to the target needs to be
> > > hand-coded for the ordering in the one case of two strings, while it
> > > can be a string list in the other case.
> >
> > Could you find a snippet of code where it has to do that?
>
> select addr1, addr2 from Address;

Which returns the identical resultset as:

select addr2, addr1 from Address;

> There might be an analysis of the data that makes use of the city, but
> doesn't include any other data values from the address. Can you think
> of any use for addr1 that is not a use for addr2 or vice versa? They
> are really the same attribute value, just placed into two attributes,
> as best I can tell.

Couldn't we just as well say addr1/addr2/city/state/zip are all just the same attribute, namely "address", but broken down into subparts?

In java.util.Date, datetimes are represented as a single long value, but you can decompose things like month, day, hour, etc. Do those subcomponents form a list?

> > Well, this is the fundamental core of the disagreement. I believe
> > we can resolve the general discussion if and only if we can resolve
> > this specific point. To me, city, state, zip, addr1 and addr2 are
> > all of a kind with respect to intra-attribute ordering.
>
> OK. I think you are right that this is the crux of the matter. addr2
> has meaning to you outside of addr1. So, what is that meaning? It
> isn't just th second line of the address as that would relate it to
> addr1. So, what is it?

Address records have almost no semantics at all. They're just records for printing labels on envelopes. To the extent that they have any semantics, it's about locating a point in space. Note that addr1/addr2/city/state/zip all together specify a single point in space, so they are looking more like the month/day/year of the date.

> > > You see that a list has an ordering function, right?
> >
> > No! There is no function. There is no spoon. There is no
> > mountain. It's only in the head of the human that this
> > order exists.
>
> I think I'm using the term list the way you said you use it. It
> includes a function that maps the positive integers (or the
> non-negatives for many computer languages) to the values. You can call
> them sorted by this index, but that is equivalent for me to saying they
> are ordered. There is a 1st one, a 2nd, and so on.

The mere fact that you can speak of this function indicates nothing. Note
that we can also speak of this function:

1 -> state
2 -> zip
3 -> addr1
4 -> city
5 -> addr2

This function indicates that all five fields have order, and that city comes between addr1 and addr2. I can also write down 119 other functions.

To be indicative of something, the function should have be written down, compiled, and each time we process an address, executed. It should handle addr1 and addr2, but not city/state/zip, if we wish to use it to indicate that addr1/addr2 have order and the others don't.

> Get your head out of the relational implementations and think of this
> not as two attributes, but as a single attribute with the type being a
> "list". That type of "list" comes packaged with an ordering function.

This is again circular. If I agree it's a list, then it's a list. The reason I'm not seeing it as a list is because I don't see that it's a list.

I could say:
"Get your head out of the MV implementations and think of this not as a single attribute with the type being a 'list', but as two attributes. That type of record doesn't come packaged with an ordering function."

But that would be just saying, "agree with me and you'll stop disagreeing."

> > Best I can do: what is some ***operation*** (in other words,
> > some function or method expressed in source code) that you
> > perform on addr1 and identically on addr2, that you *don't*
> > also perform on city/state/zip?
>
> It is a mapping of the number 1 to addr1 and the number 2 to addr2.

Yeah, but isn't that mapping just a consequence of saying it's a list? Would you have written that mapping if it wasn't a list? Do you think anyone's Java code has something like this in it:

public String getAddrLine(int i) {
  if (i==1)
    return addr1;
  else if (i==2)
    return addr2;
  throw IllegalArgumentException();
}

No one's going to write that, because on the client side, where you'd say "getAddrLine(1)" you just say "addr1" instead; the function isn't useful.

> geekier than that -- mountain dew -- they have got to get me a splenda
> version soon or I might just go off the wagon

I just never saw the attraction in Mountain Dew. Probably a good thing! Plenty of things I shouldn't be having that I *do* see the attraction in.

> > The consensus here has been that addr1/addr2 do not form a repeating
> > group. I'm not aware of any other theoretical basis for objecting
> > to them.
>
> I really, really wish I understood that. Can you think of any two
> values that would form a repeating group then?

Sure. How about PhoneNumber1 and PhoneNumber2? Kind of a dorky way to capture phone numbers. It always has space (if only conceptual space) for two when you're likely only to have one typically (true ten years ago anyway) and what if you have 3?

> Is there no such thing
> as a repeating group of cardinality 2? If there is, what does it
> possess that addr1 and addr2 do not possess?

Interchangability.

> > You can't flip them around! Neither can you swap city for state,
>
> I can swap the city & the state anywhere that people use them except in
> representations that require them in a particular order. It is
> intrinsic in addr1 & addr2 that I cannot switch their order, however.

I do not agree that you can swap city and state. Except maybe for NY, NY. Ha ha. <sob>

> We might get there on this one yet. Thanks for your stubborness on it.
> In the next round I might just say "uncle" but I'm thinking you should
> instead.

Uncle!!!

Marshall Received on Mon Sep 05 2005 - 07:06:43 CEST