Re: 3 value logic. Why is SQL so special?

From: Bob Badour <bbadour_at_pei.sympatico.ca>
Date: Tue, 19 Sep 2006 14:39:17 GMT
Message-ID: <piTPg.22879$9u.274316_at_ursa-nb00s0.nbnet.nb.ca>


Roy Hann wrote:

> "Chris Lim" <blackcap80_at_hotmail.com> wrote in message
> news:1158656458.843298.310190_at_m73g2000cwd.googlegroups.com...
>

>>>The compexity doesn't go away.  Any additional tables merely reveal the
>>>complexity that is otherwise hidden, lying in wait but still very much
>>>there.  If you don't resolve it with a complex query you have to resolve 
>>>it
>>>with complex code somewhere else.  As horrid as it is, SQL is still 
>>>almost
>>
>>Isn't it better to hide complexity then, assuming that you end up with
>>the correct result?

>
>
> I have no problem hiding irrelevant complexity. But it has to be
> understood, and hidden in an appropriate way so that your assumption that
> the result is correct will always be safe.
>
> In an ideal DBMS much complexity could be safely hidden inside suitable
> datatypes. Of course many/most SQL implementations have very limited
> support for complex types. But even so, we do seem to have an urge to
> introduce spurious complexity even when SQL doesn't impose it on use. For
> example, I don't think I've ever seen a database where the internal fine
> structure of a postal address wasn't layed out in all it's irrelevant glory.
> I can see why in many businesses you'd want to know the postal code, but the
> rest of it is usually irrelevant to anyone but the posty walking the route.
> (And just to be clear, I am sure that there are obscure applications for
> which one does need to model the fine structure of the postal address,
> perhaps down to the level of the forward sortation area and local delivery
> unit. My point is that much complexity I see is not really dictated by the
> enterprise of interest at all but is either thoughtlessly introduced, or
> introduced "just in case" by rogue designers. Which is ironic since so many
> would probably then also claim to want to minimize the number of tables "to
> reduce complexity".)
>
> Roy
>
> PS: This is a particularly sore point with me because my address is strange.
> As a result I regularly have trouble using Internet shopping sites, the GPS
> in my car can't be told where I live, and I recently had a credit card
> application declined because they couldn't match my address to some register
> or other. In all cases it was because a bunch of database designers got
> right up themselves modelling irrelevant complexities thus making everyone's
> life much harder.
>
> I'm over it now.
>
> Really.

I had a similar problem recently. After I filed my correct address with the IRS, they discarded half of it because it didn't fit their idea of what an address should look like. As a result, I received some very important correspondence from them about nine months after the fact. (I am dumbfounded I ever received it at all.)

They didn't seem to get the fact that from my perspective the address they have on file for me is the address I filed with them on physical documents and not the partial address they recorded in their database. Received on Tue Sep 19 2006 - 16:39:17 CEST

Original text of this message