From: Chris Sonnack on
topmind writes:

>> In fact, I've been doing in reality what you've been claiming (but
>> in reality failing) to do: arguing against zealotry. Yours.
>
> Yeah right. The problem is me. Sure indeed.

[shrug] Seems so. I'm not the one who just used an entire post to
tender little but childish insults. I'm not the one who's utterly
failed to understand basic programming principles or simple examples
(your failure to grasp basics is once again evident in the other
post to this thread).

> [snip of irrelevant material, dogma and insults]
>
> Your examples did NOT demonstrate any inharent tree-nees to the
> world and often I found flaws that you sweeped under the rug.

The few you actually understood you waved your arms and CLAIMED there
were flaws, but you didn't do much towards providing any proof. (See,
it takes more than assertions to make a point--it takes examples and
analysis to back it up. That's what you repeatedly fail to provide.)

The others you never understood despite repeated attempts to make them
clear. Not surprising, I guess, now that we've established that you
never were a programmer in the first place.

For example:

> For example, the function calls. They bust your damned tree
> into a graph yet you refuse to acknolege that.

If you actually understood what a run time call graph was you'd
realize instantly it's a tree--even a pure tree by your twisted
definition of "pure tree".

But since you never did understand it, the best you can do is
act like a 12-year-old:

> Graph graph graph! Eat it!

Whatever.


>> and don't understand the value of trees--particularly as data
>> structures.
>
> Until I see them donstrated to have real value in my domain, I
> will avoid them except on a small scale.

As I've said before, for a report writer--as opposed to a real
programmer--there probably ISN'T much value in tree-shaped taxonomies,
although there might be in tree-shaped data. I know I've created
reports that returned hierarchical data. Perhaps you never have.


>>> Anyhow, report writing is not necessarily simpler or harder than
>>> other domains.
>>
>> I know you want to believe that, but--and we've covered this point
>> before--it's just not true. REAL programming is harder. A lot
>> harder.
>
> You are coming across as an arrogant prick.

At least I know what I'm talking about. You so obviously don't.

> How the hell do you define "real programmer"?

Someone who actively writes code. Someone who understand analysis
and design. Someone who understands data structures. Someone who
knows AT LEAST three or four languages well.

You fail on all counts, report writer.


>> Exactly. And a huge amount of it is. My group deals with a major
>> application *designed* for businesses to use out of the box.
>
> Why not point us to its website?

All our installations are internal, so you can't access ours, but if
you go ogle for major CRM vendors and pick the top one, you'll probably
have it.


>> As I've said before, the only thing that could possibly intimidate
>> you is being challenged to demonstrate that you do know what you
>> are talking about. You've dodged every time.
>
> No, YOU have.

You're doing it again in this post. Wasting time being a child.

> You have failed to present anything that is natural tree at a
> large scale in the biz domain. You have simply not showed it.

Sorry, I just don't know how to explain "red" to a blind man.

> Your "event-driven" startup drivel was laughable.

Failing to understand it, you laugh at it. Typical.

> You conveniently redefined "sequence" as being hierarchical.
> "A" happening before "B" does NOT make anything hierarchical.

Which just demonstrates how badly you misunderstood the example.
As I recall, I had to explain several times before you even got
close to an understanding, but close was the best you could do.

>> I've challenged your knowledge.
>> YOU'RE the one who's turned to personal insults several times.
>
> An independant audit would show that you started it first.

I very much doubt that, since it's not at all my style.


>>> You have not presented a very good case that trees are the ideal
>>> data structure for almost everything.
>>
>> If you think that's been my position at any time during this thread,
>> you've understood even less of it than I've suggested.
>
> Then what are some examples where they fail and why do they fail in
> those circumstances? I don't see any careful analysis from you, only
> dogma.

You've never heard word one of dogma from me--that also is not my style.
I challenge you to go find something I said you consider dogma.

I'm not the one with the "Life is not tree-shaped" mantra.

>> Nope. Not an issue. For one thing, I don't have any complaints
>> about sets as sets. I use them as I do any tool--when they are
>> appropriate.
>
> Which is?

Why am I bother to explain this to someone who apparently doesn't even
grasp basic set theory (or at least whined about intimidation when I
challenged you)?

But, once more, sets are fine when the data is sequential or unordered.
When the data is table-like, a table or matrix is a good bet.
And when the data is hierarchical, trees are a natural.

> TREES JUST PLAIN DON'T SCALE.

See, now THAT is just dogma.

--
|_ CJSonnack <Chris(a)Sonnack.com> _____________| How's my programming? |
|_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL |
|_____________________________________________|_______________________|
From: Christian Brunschen on
In article <71n3j19r9fpj6ij591a2pj7vacj2h80cau(a)4ax.com>,
Chris Sonnack <Chris(a)Sonnack.com> wrote:
>topmind writes:
>
>> The term "relational" has nothing to do with keys and their
>> referencing stuff. I used to think it did, but like you now,
>> I was wrong. You lost this one.
>
>Heh, so you say, but I say Michelle Pfeiffer secretly adores me.
>So, as you see, saying something has no connection with reality.
>
>EVERY resource I checked agrees. You have yet to produce anything
>other than arm waving to support your point. If you are right and
>I'm wrong, where's the proof? Should be easy enough to find.

Let me quote from "An Introduction to Database Systems, Volume 1, Fifth
Edition" by C. J. Date (Addison-Wesley, 1990) - this book, in its various
editions (which include several ones thhat are newer than the one I own,
of course), is often considered _the_ textbook on databases - on page 112,
just at the beginning of section 4.2:

<quote>

<emphasis> A relational database is a database that is percieved by its
users as a collection of trables (and nothing but tables) </emphasis> .

</quote>

And later on, starting at the bottom of page 115 and continuing onto page
116:

<quote>

At this point, the reader may be wondering why relational databases are
called "relational" anyway. The answer is simple: "Relation" is just a
mathematical term for a table (to be precise, a table of a cedrtain
specific kind - details to follow in Chapter 11). [ ... ] In this part of
the book, in fact, we will generally use the terms "relation" and "table"
interchangeably, as if they were synonymoss. [ ... ]

If it is true that a relation is basically just a table, then why not
simply call it a table and have done with it? The answer is that (as
already indicated) we very often do. However, it is worth taking a moment
to understand why the term "realtion" was introducecd in the first place.
briefly, the explanation is as follows. As already mentioned, relational
systems are based on an underlying set of theoretical ideas knows as the
<emphasis> relational model </emphasis. The principles of the relational
model were originally laid down by one man, Dr. E. F. Codd, at the time a
member of the IBM San Jose Research Laboratory [ ... ] . it was late in
1968 that Codd, a mathematiccian by training, first realized that the
discipline of mathematics could be used to inject some solid principles
and rigor into a field - database management - that, prior tothat time,
was all too deficient in any such qualities. Codd's ideas were first
published in a now classic paper, "A Relational Model of Data for Large
Shared Data Banks") [ ... ] .
Mow, the relational model as orginally formulated by Codd very
deliberately made use of certain terms - such as the term "relation"
itself - that were not familiar in data processing circles at the time,
even though the concepts in some cases were. The trouble was, many of the
more familiar terms were very vague and fuzzy. They lacked the precision
necessary to a formal theory of the kind thaat Codd was proposing. For
example, consider the term "record". At different times that single term
can mean either a record <emphasis> instance </emphasis> or a record
<emphasis> type </emphasis> [ more examples deleted ] . The formal theory
therefore does not use the term "record"at all; instead, it uses the term
"tuple" (short for "n-tuple"), which was given a precise definition by
Codd when he first introduced it. We do not give that definition here;
for our purposes in the present part of the book, it is sufficient to say
that the term "tuple" corresponds approximately to the notion of a
<emphasis> flat record instance </emphasis> (just as the term "relation"
corresponds approximately to the notion of a table). [ ... ]

</quote>

The Codd paper refered to in the quoted text is:

E. F. Codd. "A Relational Model of Data for Large Shared Data Banks." CACM
13, No 6 (June 1970). Republished in 'Milestones of Research - Selected
Papers 1958 - 1982' (CACM 25th Anniversary Issue), CACM 26, No 1 (January
1983).

In Chapter 11, 'Relation Structure', the book introduces formal definition
for each term, which I will not quite here; but I will quote form the
introduction to the chapter, on page 249:

<quote>

[ ... ] We explain each termver informally here [ ... ] :

* A _relation_ corresponds to what so far in this book we have generally
been calling a table.
* A _tuple_ corresponds to a row of such a table and an _attribute_ to a
column. The number of tuples is called the _cardinality_ and the number
of attributes is called the _degree_.
[ ... ]
</quote>


So, without attempting to validate or invalidate anything else on any side
of any argument, according to what I have quoted above, it should be
fairly clear that the term 'Relational' in 'Relational Database' has
_nothing_ to do with relationships between different tables: The term
'Relation' is instead a different, more precise term for the type of
tables used in Relational databases. So, even a database with only a
single table, is a relational database.

So, can we please put this particular issue to rest?

Best wishes,

>--
>|_ CJSonnack <Chris(a)Sonnack.com> _____________| How's my programming? |
>|_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL |
>|_____________________________________________|_______________________|

// Christian Brunschen
From: Dusty Bin on
Christian Brunschen wrote:
<snip>
</snip>
> So, without attempting to validate or invalidate anything else on any side
> of any argument, according to what I have quoted above, it should be
> fairly clear that the term 'Relational' in 'Relational Database' has
> _nothing_ to do with relationships between different tables:
true
The term
> 'Relation' is instead a different, more precise term for the type of
> tables used in Relational databases. So, even a database with only a
> single table, is a relational database.
The relationship is the relation between the columns of a table.
hth... Dusty
<snip>
From: Chris Sonnack on
Ah, at last, an intelligent answer from someone who appears to know
what they're talking about! Cool!!

Christian Brunschen writes:

>>> The term "relational" has nothing to do with keys and their
>>> referencing stuff. I used to think it did, but like you now,
>>> I was wrong. You lost this one.
>>
>> EVERY resource I checked agrees. You have yet to produce anything
>> other than arm waving to support your point. If you are right and
>> I'm wrong, where's the proof? Should be easy enough to find.
>
> Let me quote from "An Introduction to Database Systems, Volume 1, Fifth
> Edition" by C. J. Date (Addison-Wesley, 1990) -
>
> <quote>
> At this point, the reader may be wondering why relational databases are
> called "relational" anyway. The answer is simple: "Relation" is just a
> mathematical term for a table (to be precise, a table of a cedrtain
> specific kind - details to follow in Chapter 11).

Ah ha. A certain specific KIND of table. Okay, let's skip to Ch.11....

(Given what you say far below, it appears the next bit isn't from the
vaulted Chapter 11, so I'm trimming without mercy here....)

> The principles of the relational model were originally laid down by one
> man, Dr. E. F. Codd, at the time a member of the IBM San Jose Research
> Laboratory [ ... ] . it was late in 1968 that Codd, a mathematiccian
> by training, first realized that the discipline of mathematics could be
> used to inject some solid principles and rigor into a field - database
> management - [...]. Codd's ideas were first published in a now classic
> paper, "A Relational Model of Data for Large Shared Data Banks") [ ... ]

You know, maybe we should just go to the source:

http://www.acm.org/classics/nov95/toc.html

> The formal theory therefore does not use the term "record"at all;
> instead, it uses the term "tuple" (short for "n-tuple"), which was
> given a precise definition by Codd when he first introduced it. [...]
> it is sufficient to say that the term "tuple" corresponds approximately
> to the notion of a <emphasis> flat record instance </emphasis> (just
> as the term "relation" corresponds approximately to the notion of
> a table).

You notice the use of "approximately" twice?

> In Chapter 11, 'Relation Structure', the book introduces formal definition
> for each term, which I will not quite here;

Aw, why not?

> but I will quote form the introduction to the chapter, on page 249:

Hey, better'n nothing!

> <quote>
> [ ... ]
> * A _relation_ corresponds to what so far in this book we have generally
> been calling a table.

Ahem, "have GENERALLY been calling a table."

> * A _tuple_ corresponds to a row of such a table [...]
> </quote>

And the meat of this lies in the definition of a tuple. And, after reading
Codd's paper (link above), I'll agree that his definition of a "relation"
does show a single table that--from his example in section 1.3--containing
records not **obviously** linked. However, I suspect this is similar to
a code fragment and only shows a partial picture of the whole. After all,
I don't know any suppliers named "1", "2" or "4".

(A few paragraphs later he talks about "relationships", so I think there's
still some wiggle room here! :-)

> So, [...] it should be fairly clear that the term 'Relational' in
> 'Relational Database' has _nothing_ to do with relationships between
> different tables:

Which I never claimed it was. I had to go read the back thread to recall
how this started, but it began over a disagreement whether SQL was a
"relational language". I suggested it would work perfectly well in a
non-relational database containing a single (non-related) flat table.

And turned into a mini-war from there.

I stand by the original seed: SQL is not a "relational language".
I also stand by the idea that "relational", in "Relational Database"
is about *relationships* between records. I claim that if there are no
relationships, there's no Relational.

> The term 'Relation' is instead a different, more precise term for
> the type of tables used in Relational databases.

Exactly. Pay attention to the words: "...the TYPE of tables." Not just
you plain old tables, but (as quoted above), " table of a cedrtain [sic]
specific kind".

VERY important distinction. Here's what I wrote over a month ago:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Here's a table (first row headers):

NAME UID COLOR DATE TYPE
Alice - Blue 5-3-1948 BG45
Bob - Red 5-3-1948 XL220
Carol 3345 Red 12-7-1955 E30F
Dave 7709 Green 9-14-2000 -

I dispute your "relational==table" definition, so I see not
one thing that makes this table "relational". It's just a
(what I'd call) "flat table".

Given something containing this table that also supported
SQL, you could write:

Select NAME,COLOR from TABLE order by NAME
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

> So, even a database with only a single table, is a relational
> database.

Only if it's a certain *specific* *type* of table. (-:

--
|_ CJSonnack <Chris(a)Sonnack.com> _____________| How's my programming? |
|_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL |
|_____________________________________________|_______________________|
From: topmind on


>
> > For example, the function calls. They bust your damned tree
> > into a graph yet you refuse to acknolege that.
>
> If you actually understood what a run time call graph was you'd
> realize instantly it's a tree--even a pure tree by your twisted
> definition of "pure tree".


NOT! It has to turn reference into duplicate nodes to force tree-ness.
Normalized, it would NOT be a tree. If you don't see the duplication,
you are stubborn or blind.


>
> But since you never did understand it, the best you can do is
> act like a 12-year-old:

A 12-year-old who happens to be correct. Neener neener tree f8ck!

> >> and don't understand the value of trees--particularly as data
> >> structures.
> >
> > Until I see them donstrated to have real value in my domain, I
> > will avoid them except on a small scale.
>
> As I've said before, for a report writer--as opposed to a real
> programmer--there probably ISN'T much value in tree-shaped taxonomies,
> although there might be in tree-shaped data. I know I've created
> reports that returned hierarchical data. Perhaps you never have.


The hierarchical nature of such reports is a particular *view*. The
arrangement of the tree can often be changed. For example, one can nest
products sold by region, or regions per product.

Region A
product 1
product 2
product 3
Region B
product 1
product 2
.....

OR

Product 1
region A
region B
region C
Product 2
region A
...

In the old days (read about IMS) the databases hard-wired the
hierarchies into its structure. If a particular report was by the same
tree, it was okay. If not, you had to bend over and scratch your back
with your tongue.


> >> Exactly. And a huge amount of it is. My group deals with a major
> >> application *designed* for businesses to use out of the box.
> >
> > Why not point us to its website?
>
> All our installations are internal, so you can't access ours, but if
> you go ogle for major CRM vendors and pick the top one, you'll probably
> have it.

I have worked with the databases of companies that have tens of
millions of customers, and generally they base their classification
systems on sets. In fact, some of the biggest problems happened from
hierarchical arrangments set up in the days when they were much
smaller. The trees failed to scale and they had to overhaul them. For
example, they are shifting from "levels" to prequisites based on sets
to match which products must be sold together. Levels were sufficient
when their product base was small. However, customers want more
al-la-carte choice.


>
> > Your "event-driven" startup drivel was laughable.
>
> Failing to understand it, you laugh at it. Typical.
>
> > You conveniently redefined "sequence" as being hierarchical.
> > "A" happening before "B" does NOT make anything hierarchical.
>
> Which just demonstrates how badly you misunderstood the example.
> As I recall, I had to explain several times before you even got
> close to an understanding, but close was the best you could do.


Let's leave it to the reader to decide whither sequences are
hierarchical. I am tired of debating somebody who cannot show inharent
treeness but insist it is there. I will agree that one *can* implement
start-up events as a hierarchy. But it is *not* the only way, and not
the way I would choose.


>
> Why am I bother to explain this to someone who apparently doesn't even
> grasp basic set theory (or at least whined about intimidation when I
> challenged you)?
>
> But, once more, sets are fine when the data
> is sequential or unordered...

You just don't get it. It is not that they are "unordered", it is that
they don't hard-wire in ONE-and-only-one order, because the "proper"
viewpoint is relative to user needs rather than universal. Relational
is the best known relativity tool out there.


> --
> |_ CJSonnack <Chris(a)Sonnack.com> _____________| How's my programming? |

-T-

First  |  Prev  |  Next  |  Last
Pages: 65 66 67 68 69 70 71 72 73 74 75 76 77 78
Next: Use Case Point Estimation