Re: Modeling Address using Relational Theory

Marshall Spight wrote:
> dawn wrote:
> > Gene Wirchenko wrote:
> >
> > And if you want to place an address line between what is current line
> > one and line two, then in the application code, you move addressLine2
> > to addressLine3 and put the new line in addressLine2, right? You are
> > modeling an ordered collection of addressLines that requires operators
> > of insert, "ripple" delete (I'm sure there is a real name for it, but
> > I've been doing some digital video editing and I like that term), etc.
>
> 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.

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

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

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

> or on first name/last name, or on the
> different components of a date, even when they all have the
> same type.

I don't see the different components of a date being similar either -- you are using a single date attribute, not multiple attributes that have an ordering to them (with numbers in the names)
>
> > If it looks like a list and it sounds like a list, it obviously still
> > doesn't need to be implemented as a list -- it can be implemented as
> > individual attributes and you can hand code those inserts & deletes.
> > But that doesn't mean that it is not, logically, a list of values you
> > are modeling.
>
> 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.

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

> 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

>
> Marshall
Received on Wed Aug 31 2005 - 05:41:23 CEST