Re: Ah, but who has better parties?

"Leandro Guimarães Faria Corsetti Dutra" <leandro_at_dutra.fastmail.fm> wrote in message news:pan.2004.05.17.20.40.33.462060_at_dutra.fastmail.fm...
> Em Mon, 17 May 2004 13:55:09 -0500, Dawn M. Wolthuis escreveu:
>
> > Nope -- I believed it to be a true statement and still have no evidence
> > that it is not.
>
> Then what I feared is true: you do not know how to think. To
> put it mildly, you never learned to philosophise, and thus your
> argumentation ends up in lying, if unwittingly.

Are you suggesting that because relational theory is "tight" or elegant mathematically that is, therefore, proof of its applicability within the IT profession? You are clearly missing my point, so I'm thinking I'm likely missing yours as well.

> When you state truthfully to 'have no evidence', it is quite
> contrary to the formerly stated 'there is not really'. The first is
> an admission of ignorance, the second is a false statement.
.
> Now
> ignorance may be due to there being nothing there to know, but that is
> quite another story.
>
>
> >> No, I am not aware of specific savings as in less dollars spent. I
> >> never cared for that, since it was simply not necessary. Going SQL --
> >> which is still much more complicated than relational -- enabled us to
do
> >> much it wasn't simply possible before.
> >
> > What was the business able to do (big picture here) that they could not
do
> > before?
>
> Query data without programming.

Perhaps in some cases, but PICK was there with that capability well before relational.

> Changing data volumes, indexing etc without changing programs.

Same response as above.

> Enabling end-user (layman) 'direct' access to data.

Again, same response.

> Declarative programming.

That is not an outcome for the company, but a technique for the developer. I'm not a huge fan of declarative programming but I'm OK with it (which is my opinion re procedural, functional and OO programming as well -- they each have their charm).

> All the OLAP stuff, therefore, and more.

Oddly enough, with the use of functions and virtual fields, PICK systems end up incorporating real-time OLAP as well as being a decent platform for data analysis of snapshot data (without any need for redesigning to a star schema).

> And all this is just half-baked, over-complex SQL.

Yup, not an asset IMO.
>
> >> Kinda like PCs add no productivity, and may even hinder it. But we
can't
> >> just imagine life without one, or even better an X terminal.
> >
> > Maybe similar, but I can certainly imagine things better related to our
> > software applications if we can move away from at least a few of the
> > features of today's SQL-DBMS's -- in particular, the 1NF and rigid
> > constraint management (not to mention SQL itself).
>
> There is a saying in Portuguese, 'the fish dies by his own
> mouth'.

And then there is that story about how the emperor has no clothes.

> 1NF means, data structure is not hidden inside fields but is
> accessible in relations.

Yes, indeed.

> Rigid constraint management means, no garbage out because no
> garbage in.

You are quite naive.

> Take these two, you're toast. Or better, you have the
> software crisis. That due to SQL having substituted the RM we never
> quite left.
>
>
> >> Where I'm working we're finishing a retail and warehousing project for
a
> >> supermarket chain replacing their old xBase system, because that system
> >> can't be data mined except by programming.
> >
> > That would be due to industry standards going in a different direction,
> > and that makes sense to me.
>
> Are you trying to prove besides not being able to think you
> are not able to read?
>
> The anedocte I told is not in any manner about industry
> standards. It is about technical capabilities inherent in general
> data models, in this case navigational (xBase) vs quasi- or
> sub-relational (SQL).

I knew you would think that ;-)
>
> > In the absense of proof, anecdotes are useful. They are not proof,
> > however.
>
> Indeed. Therefore your question is quite OT if well-meaning.

Oh really? If there is a mathematical theory that we find does nothing to advance our use of databases when it is applied to database solutions, then that would be a relevant topic, right? So, how do we know that we have chosen a good model for our database solutions with the relational model? Not only should we be able to show that we are applying the theory properly, we ought to be able to show that applying such a theory is good for our our companies in some way, right?
>
> > I measure a lot outside of the dollar, but I'm using the dollar as
metric
> > that everyone understands. For example, I understand that many more
> > dollars are being invested in SQL-DBMS's and I don't understand why.
>
> Because no one came up with a better alternative yet, besides
> a tiny Utah-based company with an yet immature product running in a
> substandard platform -- yes, that's Alphora Dataphor on MS.Net, and it
> is not meant as an indictment of the product but as an explanation of
> its apparent lack of impact yet.

My hypothesis is that there was a better alternative prior to the implementations, failed as they might be, of relational theory.

>
> > I understand that many more dollars are spent both short and long
> > term in IT when heading from many of the legacy systems to
> > SQL-DBMS-based applications, but perhaps the money is returned in
> > the productivity of the company.
>
> Depends on what is the product of the company. Obvious, eh?
>
> Take my banking anedocte. We weren't improving the
> productivity of the bank. We were making things that weren't possible
> until then. People remained as productive as before, it was IT that
> was more productive -- but ours was not the bank's product -- and
> users that had better informed decisions.
>
>
> > I think relational theory is elegant, but it is not self-evident that it
> > is relevant to my work (information systems).
>
> It will not ever be evident, self-evident or otherwise to you
> until you understand it.

Which aspects do you think I do not understand?

> >> Certainly not... I do not possess neither wide, deep knowledge, nor
> >> striking humbleness. It is just that I don't like the particular
> >> combination of not knowing something *and* pontificating about it.
> >
> > Questioning is part of the search for an answer, but point taken.
>
> No, the problem ain't questioning. It is pontificating, and
> continued misunderstanding. You probably aren't able to realise, but
> your exchange you published with Pascal reflects badly on your powers
> of understanding.

OK.
>
> >> Perhaps because we have been debating precisely an area where you have
> >> problems understanding your limitations?
> >
> > And you?
>
> I will promptly admit I lack social skills, and sometimes
> relish this lack. But I am not discussing myself.

No, you were discussing me -- and that is a common technique to pass on questions that one doesn't like -- talk about the person who asked them instead of answering the question.

>
> >> Perhaps if we were discussing your hobbies instead of mine...
> >
> > Hmmm. Aren't we?
>
> C'mon, there must *something* were you are competent. Perhaps
> programming -- I'm a lousy programmer --, but data certainly ain't it.

How do you know that? What is the criteria on which you base such a judgement. If a software developer were to work in data processing for a quarter of a century, but never work with relational databases and never study such (and that does not describe me, by the way), then would they necessarily be incompetent related to data?

>
> >> Actually thirty.
> >
> > Because the first commercial product came out in ...?
>
> The impact of the RM began before a product existed. This is
> another thing business-blinded US people have a hard time
> understanding.
>
> Do you realise IBM's informal System R papers, bad as they
> were being SQL, was used by Larry Ellison to set up Oracle? While all
> the academic and standards work being done at the time is in the
> dustbin of History, Pick included.
>
> Now to qualify that, I know indeed Pick is live and kicking.
> But so is xBase, and sequential files at that. And that doesn't make
> them relevant anymore than Egypt still being quite a country makes
> them the world superpower they once was.

Agreed.

And I sure wouldn't put any dollars into Oracle stock right now either. smiles. --dawn Received on Tue May 18 2004 - 00:15:02 CEST