Re: does a table always need a PK?

Paul G. Brown wrote:

>Lauri Pietarinen <lauri.pietarinen_at_atbusiness.com> wrote in message news:<bj0da9$ue8$1_at_nyytiset.pp.htv.fi>...
>
>

[snip]

> Trouble is, you can't build systems for the most of the time. If you're
> going to implement something it has to cater to the nasty corner cases: the
> ones where it isn't clear where to add the duplicate discard operations but
> where it is clear you're going to need a lot of 'em. (Queries sans keys).
>
>
You could also argue that current SQL-implementations miss lot's of corner cases as the now stand. So you would perhaps be trading some corner cases for other ones, i.e. we would gain some things and perhaps lose
others...

[snip]

> First, you're going to have to design a query optimizer that does the
> right thing. This is not a trivial undertaking. Then you're going to have
> to write a non-trivial system to run some experiments on. And *then*,
> whatever your results, someone will say it had everything to do with the
> quality of the implementation, not the data model. (See the comments
> reproduced in an earlier post.)
>
> Could a system using a set algebra be built and have similar performance
> properties to one built using a bag algebra? I don't know. If someone were
> to claim that they had one I would want to look at their work very
> carefully because such a result would fly boldy in the face of conventional
> wisdom.
>

Paul, I see where you stand now, and your arguments are valid. However,  those are just about the same
arguments that were given against the Relational Model in the early 70's  (the great debate, Codasyl<-->RM),
that being that relational DBMS's could NEVER overcome hierarchical and network DMBS's because
all addressing was by values, i.e. there were no POINTERS and that would slow the systems down.
And, of course, it took until the late 80's until the SQL-databases were up to speed. And, if
you continue to code with SQL like you did with Codasyl it would not be such an improvement. So it was really
an apples and oranges comparison because with SQL you have so many other advantadges, e.g. you
can push part of the application logic into SQL-statements, you have this and that kind of independence
etc...

Sooo, in the same spirit, I would claim that just comparing a "true" (or set-based) DBMS with current 'R'DBMS's in terms of doing the same thing is not necessarily fair, because (presumably) you get lot's of new
possibilities that are not available in current 'R'DBMS's.

best regards,
Lauri Pietarinen Received on Tue Sep 02 2003 - 09:11:56 CEST