Re: foundations of relational theory?

#31

Something that I can only reference by my conversations with many of the
"old timers" that have been in the mv model since it's inception. "Triad",
from what I understand, was invented by Don Nelson and the name was coined
by him. (look at the WITHIN modifier and the V correlative in the original
ENGLISH doc). Mr. Nelson's orignal notes are floating around but I have not
seen them. (Jon, have you? Frosty, have you? Chandru, have you?)

"Mikito Harakiri" <mikharakiri (AT) iahu (DOT) com> wrote

Quote:

"SixFtWabbit" <dragoninbabylon (AT) cox (DOT) net> wrote in message
news:HQXib.34578$La.22247 (AT) fed1read02 (DOT) ..

The relational model is applied mathematics. Pick is applied religion.
Your
thinking is as confused and idiotic as Dawn's.

The "Pick" data model was developed by a think-tank within TRW (I think
it
was the actual brain-child of Don Nelson) based on an arithmetic
algorithm
called a triad. It was specifically designed to handle a "Christmas
tree",
that is a bill of materials explosion, efficiently and easily.

That is the most valuable post in the thread, but could you please be more
specific with references? Googling "arithmetic algorithm triad" and alike
leads nowhere.

#32

No, sorry. Maybe Henry has a copy of the original document. The triad
term was used iirc and the document was pretty formal though opaque. Chandru

SixFtWabbit wrote:

Quote:

Something that I can only reference by my conversations with many of the
"old timers" that have been in the mv model since it's inception. "Triad",
from what I understand, was invented by Don Nelson and the name was coined
by him. (look at the WITHIN modifier and the V correlative in the original
ENGLISH doc). Mr. Nelson's orignal notes are floating around but I have not
seen them. (Jon, have you? Frosty, have you? Chandru, have you?)

#33

"Mikito Harakiri" <mikharakiri (AT) iahu (DOT) com> wrote

Quote:

"Albert D. Kallal" <NOOSSPAMkallal (AT) msn (DOT) com> wrote in message
news:hqXib.97458$pl3.65922 (AT) pd7tw3no (DOT) ..
Actually, in a MV system you will find that existing queries that search
for
a phone number will now actually include the new numbers in the search.
Further, reports that display phone numbers will now display those
additional phone numbers. In a far greater number of cases no
application
logic needs to be changed.

What if you don't want certain phone types to be displayed? Hint:
security.

Sure, no doubt that we would have to come up with a solution for the above.
However, you would have to deal with this problem in either system in some
way anyway. I mean, yea, sure lets add another column and place a yes/no
value in the field if it is to be displayed. This would mean that old code
would have to be modified to take into account this extra requirement.
However, once again implementing this extra requirement is going to be easer
in a MV environment in place of splitting out the data to another table. If
we already have this extra related table in the sql system, then I would
certainly say that there is probably no difference in the effort in either
system to implement the above feature.

--
Albert D. Kallal
Edmonton, Alberta Canada
kallal (AT) msn (DOT) com
http://www.attcanada.net/~kallal.msn

#34

"Albert D. Kallal" <NOOSSPAMkallal (AT) msn (DOT) com> wrote

Quote:

"Bob Badour" <bbadour (AT) golden (DOT) net> wrote

With all due respect, you do not yet understand normalization. A
relation
with attributes for each of a main voice phone, a fax number, a cell
number
and a modem might be in 5NF.

Yes, it *might* be. And then again, it might not be? Thus, I don't
understand your point here?

Without full knowledge of all the business requirements, it is impossible to
determine the level of normalization of a relation. Having two or more
attributes drawn on a phone number data type says nothing about the level of
normalization. As such, a relation might have attributes for each of the
numbers mentioned above and be fully normalized contrary to your earlier
assertion.

Quote:

My point is that most existing systems out there are not 5nf.

With all due respect, without demonstrating any understanding of 1NF let
alone 5NF, you lack credibility in regard to what exists in most systems
with respect to normalization.

Quote:

My point is
that most existing systems out there would requite the modifications that
I
said.

Are you telling me that the average system out there right now is 5nf?

Many are. Most people designing them or using them have no idea what normal
form their database exhibits. Your own statements are simply a paradigm for
the profound confusion and misconception pervading our industry.

You need to stop dismissing the foundations of your profession as an
unattainable and unimportant ideal. Regardless whether perfection is
attainable, it identifies the direction in which to move.

#35

"Albert D. Kallal" <NOOSSPAMkallal (AT) msn (DOT) com> wrote

Quote:

"Mikito Harakiri" <mikharakiri (AT) iahu (DOT) com> wrote in message
news

jYib.42$It5.200 (AT) news (DOT) oracle.com...
"Albert D. Kallal" <NOOSSPAMkallal (AT) msn (DOT) com> wrote in message
news:hqXib.97458$pl3.65922 (AT) pd7tw3no (DOT) ..
Actually, in a MV system you will find that existing queries that
search
for
a phone number will now actually include the new numbers in the
search.
Further, reports that display phone numbers will now display those
additional phone numbers. In a far greater number of cases no
application
logic needs to be changed.

What if you don't want certain phone types to be displayed? Hint:
security.

Sure, no doubt that we would have to come up with a solution for the
above.
However, you would have to deal with this problem in either system in some
way anyway. I mean, yea, sure lets add another column and place a yes/no
value in the field if it is to be displayed. This would mean that old code
would have to be modified to take into account this extra requirement.
However, once again implementing this extra requirement is going to be
easer
in a MV environment in place of splitting out the data to another table.
If
we already have this extra related table in the sql system, then I would
certainly say that there is probably no difference in the effort in either
system to implement the above feature.

I had hoped the books I sent you would improve your thinking. Sadly, it
appears your ignorance is incorrigible.

#36

"SixFtWabbit" <dragoninbabylon (AT) cox (DOT) net> wrote

Quote:

The relational model is applied mathematics. Pick is applied religion.
Your
thinking is as confused and idiotic as Dawn's.

The "Pick" data model was developed by a think-tank within TRW (I think it
was the actual brain-child of Don Nelson) based on an arithmetic algorithm
called a triad. It was specifically designed to handle a "Christmas
tree",
that is a bill of materials explosion, efficiently and easily.

As I said, Pick is applied religion. In what important way does the history
given above differ from a group of cardinals or bishops sitting down to
resolve dogma?

#37

In article <3F8C6288.2090901 (AT) quest (DOT) with.a.w.net>, cmurthi <xyzcmurthi@qu
est.with.a.w.net> writes

Quote:

No, sorry. Maybe Henry has a copy of the original document. The triad
term was used iirc and the document was pretty formal though opaque. Chandru

SixFtWabbit wrote:
Something that I can only reference by my conversations with many of the
"old timers" that have been in the mv model since it's inception. "Triad",
from what I understand, was invented by Don Nelson and the name was coined
by him. (look at the WITHIN modifier and the V correlative in the original
ENGLISH doc). Mr. Nelson's orignal notes are floating around but I have not
seen them. (Jon, have you? Frosty, have you? Chandru, have you?)

iirc they've disappeared. When Dick was around they were in a filing

cabinet somewhere apparently. They don't seem to have been since (as
evidenced by past conversations on cdp)

Shame :-(

Cheers,
Wol
--
Anthony W. Youngman - wol at thewolery dot demon dot co dot uk
Witches are curious by definition and inquisitive by nature. She moved in. "Let
me through. I'm a nosey person.", she said, employing both elbows.
Maskerade : (c) 1995 Terry Pratchett

#38

"Bob Badour" <bbadour (AT) golden (DOT) net> wrote

[snip]

Quote:

Few people want needless
complexity without benefit.

And fewer still respect those that criticise what they don't understand.

#39

Cool post Anthony!

"Anthony W. Youngman" <thewolery (AT) nospam (DOT) demon.co.uk> wrote

Quote:

In article <ba87a3cf.0310131254.66a641ba (AT) posting (DOT) google.com>, Seun Osewa
seunosewa (AT) inaira (DOT) com> writes
Coming from a DBMS background, I was surprised to find that from my
experience, my developers who used PICK-based systems also had a more
agile environment for maintaining applications over time. That,
however, is anecdotal evidence and therefore requires some emperical
evidence or mathematical proof before I claimn that I KNOW it to be
the case that it is always better to persist data outside of the RDBMS
model.
[.....]

Ok, I think what we need to do is come up with an illustrative
example. A particular simple application which Dawn can use to
demonstrate the advantages of the MV model. And then our knowledgeable
relational model advocates can use the same example to "debunk" her
claims. And perhaps I can use it to show how some of my PlayDB
concepts might prove useful.

Okay ... and I think this happened in BOTH Denmark, AND the UK.

A major computer magazine (in the UK it was Computer Weekly) ran a
competition annually for some five years. The brief was, you were given
a spec, and 24 hours later, you turned in your working application for
judging.

In both competitions, the prizes were won EVERY time by teams using MV
databases. I think it was OpenInsight was used by most of them.

Oh - several teams using relational databases failed even to get as far
as getting the basic data layout defined ...

And I can't give any details beyond "Witwatersrand Uni, South Africa",
but apparently they did a study of a load of (presumably successful)
companies, plotting database spend against turnover. There were actually
TWO peaks. Most of the companies in the lower (cheaper - 2% iirc) peak
were running MV databases. The ones in the more expensive peak (4%) were
running relational.

My favourite example is always to quote an invoice. How many tables do
you need in a relational database? One for the invoice itself, one for
the addresses (two at least, billing and shipping), one for the line
detail, a couple maybe for the relationships ...

In MV I would have just ONE "file" (as we call our equivalent to a
table) and I would need just ONE "record" (as we call our equivalent to
a row). Oh - and it's all properly normalised just as it would be in
relational - so I can present it to you as a SQL view no problem. Just
that whereas it costs you a hell of a lot of searching through tables
and indices to pull everything even if you know the invoice number,
presuming I've defined invoice number as the primary key I can retrieve
ALL that information with a single head movement on disk. Given that
disk io is the slowest thing on the system, if you can't store your
entire database in ram I've just kicked the shit out of you for speed
:-)

"How to win at poker - take your weaknesses and bluff that they're your
strengths" - I'm not saying that SQL's abstraction is a bad thing (it
does make ad-hoc queries easier), but by hiding the realities of
implementation from programmers you are basically handicapping them such
that they will NEVER be able to even compete successfully (let alone
win) if one of the requirements is to stretch the hardware to its
limits.

The reason MV is so powerful is that it's easy for us mimic relational -
it's a *subset* of what we have available to us. But in order for you to
match us, you have to implement (using all sorts of SLOW or EXPENSIVE
workarounds) what our model gives us for free - take my "one disk hit
and I can give you an entity view" :-) How expensive is a "many to many"
join in SQL? The chances are we don't need it, and if we do then we can
use an explicit index that costs us bugger all - it'll cost you a major
disk thrash :-)

Cheers,
Wol

#40

Quote:

"SixFtWabbit" wrote:
The "Pick" data model was developed by a think-tank within TRW (I
think it was the actual brain-child of Don Nelson) based on an
arithmetic algorithm called a triad. It was specifically designed
to handle a "Christmas tree", that is a bill of materials
explosion, efficiently and easily.

"Mikito Harakiri" replied:
That is the most valuable post in the thread, but could you please
be more specific with references? Googling "arithmetic algorithm
triad" and alike leads nowhere.

SixFtWabbit answered:

Quote:

Something that I can only reference by my conversations with many of
the "old timers" that have been in the mv model since it's inception.
"Triad", from what I understand, was invented by Don Nelson and the
name was coined by him. (look at the WITHIN modifier and the V
correlative in the original ENGLISH doc). Mr. Nelson's orignal notes
are floating around but I have not seen them. (Jon, have you? Frosty,
have you? Chandru, have you?)

I remember seeing the originals, a long, long time ago. In pencil, on that
green paper with the graph squares on the back, IIRC. Written as flow
charts, with little ovals with all the original mode names: MD10, etc.

I remember Dick looking for the orig's in the later years, but never recall
hearing that they were found. =`:^< Maybe John Bohner has an idea?

-- frosty