On 26 fév, 11:33, Roy Hann <specia... (AT) processed (DOT) almost.meat> wrote:
In a sense, I do think we are actually doomed by ignorance.

No sign seems to indicate that things would recover anyday soon.
Ironically, we may notice that the greatest scientific innovations are
often historically followed by periods of utter darkness...Then these
innovations are rediscovered and corrected by other
civilizations...The most probable scenario is that the relational
model will be rediscovered by other civilizations in a few centuries
but will be forgotten by everybody...Guess that some people become
then guardian of the temple...

Regards

cimode (AT) hotmail (DOT) com wrote:

[snip]

That will be a real case of IT high priests.

Sincerely,

Gene Wirchenko

Computerese Irregular Verb Conjugation:
I have preferences.
You have biases.
He/She has prejudices.

"Roy Hann" <specially (AT) processed (DOT) almost.meat> wrote

Just to take this seriously, if only for a brief moment, here is the
proposition in a nutshell:
"The responsibility of ensuring data integrity falls entirely to the
application."

Two points:

First, this is the way things were before databases began to be used. If
you go back to the 1960s, you'll find that nearly all applications were
written exactly this way. It was the bug prone nature of this way of doing
things that led to the rise of databases to begin with. My choice of the
1960s is arbitrary. In different local environments, the transition to
databases happened much later, or never at all.

Second, note that "the application" is singular. This way of doing business
applies only when a database is embedded within a single application. If a
database is an information nexus allowing multiple applications to provide
and use shared information, the contracts between applications get drawn
into the nexus itself. The author makes much of the supposed superior
scalability of key/value data structures, but there is one way in which
they scale very poorly: the transition from embedded in a single
application to operating as a nexus between multiple applications.

I guess I should acknowledge that majority of today's new databases are of
the embedded type rather than of the nexus type. That means we fight most
of the battles on the other side's turf. Maybe that provides an insight
into how the keepers of the flame can survive the dark ages. I dunno.

Walter Mitty wrote:

A colleague pointed something out to me a few years ago which I have
found very useful ever since. In colloquial usage (i.e. anywhere but
here), the terms "application" and "database" are completely
interchangeable. Our customers and clients simply draw no distinction.
The concept of an "information nexus" would be wholly novel to them.

Consider also that IT is still a very immature field and that most of
its most senior and influential practitioners are the ones who drifted
into it having first been clients.

Things are the way they are because they got to be that way.

--
Roy

"Roy Hann" <specially (AT) processed (DOT) almost.meat> wrote



I think that observation is very useful indeed. It certainly applies, in my
epxerience, to non programmer users of almost any system. They view "the
database" as the stuff that appears on the screen when they click certain
buttons, and/or enter certain keys. In a way, I can empathize with that
point of view a great deal. Why should they be concerned about layers that
are invisible to them? They only know of these layers by hearsay.

However, with regard to programmers, the distinction between "the
application" and "the database" is very important indeed. Some twenty years
ago, I used to teach database programming to programmers whose prior
experience included only files. Their languages included COBOL, BASIC,
FORTRAN, C and a smattering of other languages. A very large percentage of
them viewed interacting with database data as harder and less productive
than using files for the same purpose, to very little benefit. Some of them
were only learning database programming because management told them to.

I think a large percentage of programmers never get beyond this stage. One
reason is that they never get the experience of dealing with a database
whose design is well suited for its mission, whose update processes are well
programmed, whose data is clean, and whose administration is competent.
Until you've had this experience, it's difficult to grasp the "bang for the
buck" that database enthusiasts like myself claim for databases.

Anyway, that's the way things were twenty to twenty five years ago. How
have things changed in the interim? See below.

IT remains immature much longer than many similar fields of endeavor have.
Consider flight. From 1903 to 1953, manned flight progressed from box kites
with moters strapped to them, and one pilot riding on the wing, to the B-52
and the DC-6 passenger liner. The engineering of new aircraft progressed
from complete innovation to a well understood discipline, with design
patterns that were well understood. Innovation built on what had already
been learned, instead of junking all past knowledge.

By contrast, consider the field of programming from 1951 to 2001. 1951 was
the year the first commercial computer was sold. In 2001, programming was
still being viewed as a special "knack" that can't be taught and learned in
a formal setting. Systems engineering, DBA work, and what have you was all
being seen as being in such a state of flux that any knowledge that's more
than 18 months old is seen as suspect.


There are serveral reasons things got to be that way. One of them is that
mature workers in the field get fired so young, and can't find new work.
The culture surrounding IT values youth even more than I do. I hasten to
add that I don't think the field should stagnate, and that overemphasis on
the mature worker could cause that result. But the field is tilted too far
in the other direction.

There are other reasons, but I'll stop for now.

Dieter Noeth (in comp.databases.theory):

Indeed HP is continuing the Non-Stop technology it bought along with Compaq
(which had bought Tandem). I would love to see a chance to work with it
some time.

Joachim

Walter Mitty wrote:
That's the data perspective and no doubt the tacks of any progress are
affected by the situations people find themselves in. But Codd's 1970
paper (I'd say it was the one that got the most attention) made its
points with examples from 'singular' (if you will) apps and showed how
a small set of operations had somewhat universal application when a
certain logical organization for data was followed. One of the main
consequences being that two different 'singular' apps should not
invent their own database operations. As of today this has not
occurred to many people on the 'dark side' even though they take it
for granted that it's quite sensible to factor out all the operating
system functions which the 1950's apps embedded.


By the early 1970's, some other fans were touting Codasyl doctrine for
shared/'nexus' dbs. They had an 'enterprise' message (like so many of
the so-called technology chatter these days, executive summary bumpf
and so on) that dodged the nuts and bolts issues that Codd confronted
head-on and he went out of his way to discount the use of network
structures for such dbs, ie., they were almost as big a distraction
and impediment to the sharing of data as the file systems they
replaced, eg., needing just as much navigation. The recent Sara B
post doted on another persistent distraction - the big dbms vendors
are pre-occupied with concurrency, persistence, and hardware failure
problems, not relational problems. In their turn, practitioners are
pre-occupied with SQL problems and not relational problems. In other
words, in the last fifty years very little attention has been paid to
what I would call the pure application problems like inferencing and
computation.


A no doubt minority attitude about concurrency is that while notable
people like Jim Gray have described the problems concisely, most
implementers confuse such descriptions with solutions. Here's another
minority attitude - Codd's almost total emphasis on the database as
the application of relational theory encouraged today's limited use of
the theory. One could substitute relational notions for practically
any of today's programming artifacts, eg., as Date implies, one could
treat a machine language operator like '+' as a relation. An so and
so on, relational theory potentially allows a specification language
that is also executable (and machine transformable, eg optimizable),
but has anyone here ever seen a relational schema that models the
required concurrency for a given application? It is laughable how
many people, such as the Entity-Relationship fans, took it for granted
that the precision of RT needed to be superimposed with a
specification language, especially one as fuzzy (and mostly irrelevant
to apps) as E-R. XML is even more distracting. Taken to an extreme
(which I think it should be), this attitude says that there is no such
thing as a 'relational application' if that app uses a
procedural/imperative language and/or limits its use of RT to persistency.


That's my little diatribe for today - basically I think most IT/CS
progress has been derivative, plodding and over-sold and as usual in
human affairs, very few people are willing to 'stretch the envelope'
or 'step out of the box', which is what real progress always needs.
Codd's invention remains reminiscent of the light bulb, the first
efforts to manufacture it were overtaken when Edison realized that the
missing ingredient was a power distribution system. Not to say I
class Codd with the inventor of the faucet attachment for dispensing
Mott's Clamato Juice!

"Walter Mitty" <wamitty (AT) verizon (DOT) net> wrote

Those who fail to learn from history are doomed to repeat it. But look at
the bright side: it means more work for those who can fix the inevitable
screw-ups. More work is a good thing in today's economy (Thank you, Nancy
Pelosi, Harry Reid, Barney Frank, and Chris Dodd, and let's not forget to
thank their new rubber stamp, Barack Obama.).

On 1 Mar, 03:34, "Brian Selzer" <br... (AT) selzer-software (DOT) com> wrote:

I'm _tired_ of fixing screwed-up systems where someone let the Head of
Marketing define the architecture because they had the biggest space
in the carpark / had been with the company the longest. 8-(

How about getting this discipline to the state that Victorian bridge
and boiler builders achieved? We're at a point where "best practice"
is now pretty good, but lack of financial responsibility in our
clients (and the fact that most branches of software kill fewer people
than bridges or boilers) means that a liar in a suit still wins the
contract, even when everyone knows they're going to fail to deliver
it.