Re: Do we always have to update or insert? Why can't we just relate?

>i can't prove it but i suspect the typical INSERT behaviour is either an
>echo of the mainframe days (at least the ibm mf days) when disks and
>channels actually had some hardware support for keys (which many of the
>sql designers would have been at least unconsciously imbued of) or the
>mistaken foresight typical of many language designers who want to
>anticipate programmer errors. either way, even if i can't prove it, the
>language ends up preventing as many useful techniques as erroneous ones.

To me it looks like a failure to recognize the benefits of declarative programming. It's almost like there was a battle in every programmer's mind to talk about things sequentially or declaratively.

I see postings on this thread talk about primary keys. in a table relation that contained states in the US. The state name field could very well be the primary key, duplication is strictly prohibited in this case. This example is more or an exception, most primary keys are "artificial" and in this tables data duplication can happen even when the primary key was in fact unique. In this cases to update instead of insert based on the presence of a primary key wouldn't necesarily have that much of an impact on the uniqueness of the records. This also makes database rules more important.

Arturo Hernandez Received on Wed Oct 19 2005 - 18:54:02 CEST