I was just spying on our neighbors over at pgsql.advocacy and saw this
rather pathetic plea:

I could try to argue that the natural consequence of an elegant theory
with a minimum number of concepts is obviously going to result in a
smaller number of practitioners being required and hence a smaller
audience for the press. But I don't think that's the reason. The
dilettantes have moved on? We certainly haven't stopped storing data.

--
Roy

UK Ingres User Association Conference 2012 will be on Tuesday June 19 2012.
*NOTE THE CHANGED DATE* See www.uk-iua.org.uk

On Fri, 30 Sep 2011 11:05:10 +0000 (UTC)
Roy Hann <specially (AT) processed (DOT) almost.meat> wrote:

The dilletantes have certainly moved on; no one will argue that
relational theory is fashionable. And I agree it doesn't require 90+
publications. There's no magazine called "Algebra Today", either.

We certainly haven't stopped storing data. Many of us, though, have
given up on the idea (insofar as it could be said we ever embraced it)
that math & logic could be our ally in manipulating data. You, Roy,
answered the "why relational?" question in London with the phrase
"logical inference". As long as we're talking about "storage and
retrieval", the answer is "why, indeed?". The moment the question
turns to "where X is true", the origin and advantage of the relational
model should become immediately apparent. But such moments are
distressingly rare.

It seems we have to re-experience the past in order to re-invent it.
Satayana wouldn't be surprised.

--jkl

I agree that the dilettantes have moved on. And here is a thought for you, I
think the industry has stopped storing data, we have certainly stopped
placing enough value on the internal consistency and meaning of it -that is
what "the middle layer is for". The old name for a database was Data Bank
(still is in German) and one reason for using Banks is that they add value
to what they store (in theory at least). Is this the view today?

Instead, I believe that, more and more, these days data is chucked into a
large bit bucket and is expected to reappear when needed. I strongly suspect
that the reason for this is the prohibitive expense and risk associated with
what used to be termed the "impedance mismatch" between the object world and
the SQL world. For example, we all know that it is not possible to store
something as apparently simple as a person's full name in an SQL column
regardless of the contents of that name and in a way that the parts of the
name can readily be picked apart as needed. Why not? After all, we also all
should know that there is nothing in the relational model that prevents
this, is there?

Jeremy Peel


On Sat, Oct 1, 2011 at 5:34 PM, James K. Lowden <jklowden (AT) schemamania (DOT) org>wrote:

Jeremy peel wrote:

I think you are probably on the right track there, and to complete your
thought, I think the industry is more interested in "persisting" the
state of objects than storing data per se.

To be honest I'm not interested in storing data either. As James Lowden
suggested, you and I (and James) are probably more interested in
gathering assertions (or "testimony" as I prefer to think of it).

Maybe this is harsh or wrong or both, but I get the impression that the
database server and its disciplines are regarded as a nuisance. It's
tolerated because trivial SQL is a nicer way to get at "records" than
coding file I/O.

The relational database is a model of what you can say about the
enterprise of interest. The way object persistence is traditionally
done, it's a model of what you can say about a model of the enterprise
of interest. Daft. I struggle to get one model right; why people
think it's good to give themselves two to deal with is a mystery to
me. No wonder it sucks.

I'd be perfectly happy have classes as domains and instances as
values. Forget about the nonsense of modeling models! The theory of
classes as domains is incomplete but even a half-arsed stab at an
implementation must be better than the current approach and the
"impedance mismatch" goes away.

I admit this question puzzles me. Why would the DBMS care? All the
DBMS needs to care about is that an attribute of type NAME is comparable
to another attribute of type NAME. Maybe I'm misreading this but it
sounds like you're asking to violate First Normal Form. Are you
concerned about domain constraints on NAME columns?

--
Roy

UK Ingres User Association Conference 2012 will be on Tuesday June 19 2012.
*NOTE THE CHANGED DATE* See www.uk-iua.org.uk

Ah excellent! An invocation of First Normal Form. To elaborate on that point
I was making a tiny bit more, before the trail becomes unreadably long, if
you regard NAME as a data type then its internal structure is irrelevant to
any NFs because an NF is appropriate at the relational level rather than the
type level and I hope that we can agree that the two are distinct.

There now, I've gone and said "relational" when really what we are talking
about is "SQL", but I think the principle applies regardless in this
instance.

jo

On Mon, Oct 3, 2011 at 3:01 PM, Roy Hann <specially (AT) processed (DOT) almost.meat>wrote:



--
Jeremy Peel

Jeremy peel wrote:

Absolutely. Completely orthogonal interests. No more relevant than
colour to Euclidean geometry.

I draw the same distinction between an SQL DBMS and a relational DBMS.

--
Roy

UK Ingres User Association Conference 2012 will be on Tuesday June 19 2012.
*NOTE THE CHANGED DATE* See www.uk-iua.org.uk