Re: Practical considerations of dealing with two meanings of NULLs

A long time ago, in a galaxy far, far away, Doug_McMahon_at_yahoo.com wrote:
> As I understood it Codd envisioned views as a means of achieving
> logical/physical independence. There is therefore considerable
> value in ensuring that to the extent possible view relations and
> base relations are not distinguishable by applications. Sadly, SQL
> databases have traditionally done a poor job of making views
> "writable", leading to view-based reads and base-table writes as
> common industry practice.

There is a further problem, namely that it is nontrivial to ensure closure, that is, that the results of applying relational operations to a set of relations will result in the return of a relation.

It is easy to think of a counterexample, namely with the "select" operator where you essentially are chopping columns off of a relation.

If you do that, you can't guarantee that the results will be a relation; the sticky bit is that of tuples being unique.

For instance, if you chop columns off of a transaction relation, particularly ones that are members of a candidate primary key, you'll presumably find repeats. Two such instances may represent separate transactions, but in this view of things, they are not distinguishable.

As a result, not all views can be relations. And once that strictness is lost (e.g. - we haven't got closure), it seems unsurprising that implementors would get tired of explaining the limitations and give up on really remaining "relational."

-- 
output = ("cbbrowne" "@" "gmail.com")
http://cbbrowne.com/info/slony.html
"The social dynamics  of the net are a direct  consequence of the fact
that nobody  has yet developed  a Remote Strangulation  Protocol."  
-- Larry Wall