Re: Modeling Address using Relational Theory

dawn wrote:
> Marshall Spight wrote:
> >
> > I really don't think it is a list. How often do you delete line2
> > and expect line2 to be replaced with the city?
>
> the city is an altogether different attribute named "city" for example.

Agreed. I would claim that addr1 and addr2 are exactly as related (or not) as addr2 and city, despite the similarity of names.

> > How often do you
> > expect to delete FirstName and have LastName become the new
> > FirstName, and LastName be empty?
>
> FirstName and LastName are not relevant to this as far as I can see,
> although those might be components of addressLine1 if there is not a
> separate stored or derived mailTo attribute.

I likewise see addr1 and addr2 as being exactly as related as firstName and lastName.

> > 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. You can leave it to the user to fix it rather than
> including any code to help them. tion or apartment line and other
> lines move up.

This paragraph didn't come through right; I think I'd understand it better if it did. I don't think I understand the use case as it stands.

> Of course you can have separate attributes for each of the possible
> components of the address lines as with "city", but that is rare.

Really? I've only ever seen it the way you describe as rare. (I do not disbelieve you; I'm just surprised.)

> > I don't think it sounds like a list. I don't think it's logically
> > a list, in part because there are no list operations on the data.
>
> that's a chicken and egg argument. It could be the way they are
> modeled and the implementation environment that lack the operations
> thereby causing people to model this data in a way that it does not
> appear to be a list.

Perhaps, but ...

> > For example, you don't concatenate two addr1 values and get an
> > addr1 and an addr2.
>
> No, but if you have only one attribute of addressLines you simply spit
> out the values and treat it like a list. So, even if you don't
> perceive it as a list, people who work with products that have list
> implementations are likely to think of it that way.

I think if I were writing a Java class to model an Address, I'd be likely to use properties for name, addr1, addr2, city, state, zip. I wouldn't expect to use addr3 and if I did, I wouldn't expect I would have a multivalued property for that. It seems weird to think of modelling a property that way ...

> > Have you ever seen an application where you could insert a new
> > line of text between addr1 and addr2 and have addr2 moved to addr3?
>
> No -- I have seen where you insert a line of text between the first
> value of addressLines and the second value and have the second value
> move to the third value. This approach is pervasive in the
> non-SQL-DBMS world.
>
> > I haven't, and I've gotten my fair share of feature requests for
> > address editing.
>
> Which environments have you worked in that have oft-used list
> implementations? --dawn

The last 9 years or so, it's almost exclusively Java. My #1 data structure in Java is the java.util.List. In fact I hardly use much of anything else.

Of course, writing Java that interfaces to an SQL database is a particular kind of beast ...

Hey, now that you've played the list-handling environment card again (well, halfway, anyway) would you care to list what you see as the most important list manipulation primitives? I always enjoy a good discussion about primitives. I expect if I tried to do the same, I'd just parrot the Java list interface. Too much exposure, you know.

Marshall Received on Wed Aug 31 2005 - 07:11:52 CEST