In article <3EF8FADA.2030905 (AT) adelphia (DOT) net>, Ed Prochak
<edprochak (AT) adelphia (DOT) net> writes
Well, play with MV. You still have the file-space problem, true. But
RAM? Conceptually, the ENTIRE database can be treated almost as if it's
in virtual memory and accessing a record (what sql would call a row) is
normally order 1 (on average requires just over 1 head-seek pre record).
Coupled with the fact that a record is actually not just a row, but what
MS calls a chaptered rowset, then data access will toast SQL for speed
if you can't cache the database in real RAM.
And even more trivial in MV? Okay, I'm inexperienced in MS-SQL/C#.NET,
but I'm taking over a system written by "experts", and it seems horribly
complicated. By the way, I'm responsible for the system it's replacing
so I CAN compare the two - they are meant to do the same job...
MV's flexibility will beat relational hands down :-)

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

bbadour (AT) golden (DOT) net (Bob Badour) wrote in message news:<cd3b3cf.0306280729.6a0944b1 (AT) posting (DOT) google.com>...
Geez Bob. You are an an annoying S.O.B.

Do everyone a favour will you and restrict your comments to those
topics on which you possess some knowledge - ie. that which doesn't
exist.

You have demonstrated a remarkable ignorance of MV and you continue to
say it's inflexible, lacks power, etc., etc., when, as people with far
more patience than mine have attempted to explain to you, what you are
saying could not be further from the truth. The only reason I feel
compelled to respond to your nonsense is that some innocents might be
led astray in the badly mistaken belief that you are sane and/or
knowledgable.

Mike.

"Mike Preece" <michael (AT) preece (DOT) net> wrote

I tend to think the same about the Pick crowd, so I guess it's mutual.


I always do. I don't why you would find making the suggestion worthwhile.


Mike, apparently you were not paying attention because Albert clearly
demonstrated that MV lacks power, that it is inflexible, that unrelated
changes to the physical structure change the meaning of existing queries.
Some folks keep pretending that the demonstration never happened (or maybe
they lacked the cognitive ability to understand the demonstration), but the
demonstration did happen.

Some folks like Anthony go around making all kinds of idiotic "Rah! Rah!",
wild, absurd assertions that have already been proved false. They can live
their lives in denial if they want to, but I will continue to call them on
it when they ask others to share their delusions.

Bob Badour wrote:
Thanks, Bob for the followups. Maybe the best we can do is point the
"innocents" to that thread. (I forget the topic it was under, so I'm hoping
that you can toos it into this thread.)

Later,
ed

--
Ed Prochak
running http://www.faqs.org/faqs/running-faq/
netiquette http://www.psg.com/emily.html
--
"Two roads diverged in a wood and I
I took the one less travelled by
and that has made all the difference."
robert frost

Ed Prochak <edprochak (AT) adelphia (DOT) net> wrote

{snip]

See Bob. That's why I find you so very very annoying. All that
discussion proved is that you are beyond reason. Part way through that
thread you fixed doggedly to the notion that you had somehow proved
something and nothing anyone said would shift your view. It really got
irritating. I've waded through the morass of that thread and I can't
find how or where you formed your absurd notion. I myself attempted to
restore some sanity to the discussion but to no avail. If you're so
sure of your ground I beg you to please state clearly and concisely
exactly what your big "proof" was - just to clear up any and all
confusion. What was it that you think the MV model is incapable of?
And please, I entreat you, spare us the patronising tone, insults,
invective and references to "incoherence principles" or what ever the
hell it is you love to go on and on about.

Mike.

"Mark Preston" <usenet (AT) noemailaddress (DOT) co.uk> wrote

Denial of the obvious and denial of what has already been conclusively
proved does not contribute anything worthwhile and says more about you than
about the topic under discussion.

See news:UJVwa.65$DG4.13592667 (AT) mantis (DOT) golden.net and its followups for a
simple pick file structure that clearly demonstrates the weakness of the
product. Alternatively:
http://groups.google.com/groups?dq=&...Vwa.65%24DG4.1
3592667%40mantis.golden.net


See news:M9Kva.312$0N3.67253409 (AT) mantis (DOT) golden.net for Albert's demonstration
that the same query asks two different questions depending on the underlying
physical structure. Alternatively:
http://groups.google.com/groups?q=g:...=&ie=UTF-8&sel
m=M9Kva.312%240N3.67253409%40mantis.golden.net


Pick and mv databases are not in 1NF--by definition. Your suggestion that
they are always in 1NF demonstrates profound ignorance of the concept.


Depth and dimensionality are ill-defined in your statement above. An n-ary
relation describes a locus of points in an n-dimensional space. A relation
describes such a locus very simply by identifying the locus (relation), each
dimension (attribute) and each point (candidate key/1NF). Since a relation
valued attribute contains a single value in each tuple, depth is irrelevant
when discussing relations. Due to closure, the relational logical data model
imposes no restrictions on depth of nesting of operations--including
operations on relation valued attributes.

Pick and MV increase complexity without any compensating benefit. By
discarding logical identity, they actually reduce the power of expression.


The above assertion was already proved false. Asserting it after such proof
demonstrates intellectual dishonesty and/or incapacity.


Again, the above assertion was already proved false. Denial indicates
delusion.


Don't worry: Your fears are unfounded.

"Mike Preece" <michael (AT) preece (DOT) net> wrote

the
on
In that case, I can only conclude you lack the cognitive ability to
comprehend simple concepts.

A query language that lacks the ability to express simple questions from
simple structures containing all the necessary information to answer those
questions is weak and inflexible. Apparently, you do not understand the
concepts of power and flexibility.

See news:UJVwa.65$DG4.13592667 (AT) mantis (DOT) golden.net and its followups for a
simple pick file structure that clearly demonstrates the weakness of the
product. Alternatively:
http://groups.google.com/groups?dq=&...Vwa.65%24DG4.1
3592667%40mantis.golden.net


I did not prove it -- Albert did. Albert demonstrated that the query he
initially proposed as the obvious, easily predicted solution to his
challenge answered the wrong question. At the same time, Albert demonstrated
pick fundamentally changes the meaning of queries in response to logically
unrelated physical changes. By doing that, he also demonstrated the
deficiencies in the query language when MV attributes are involved that
prevent pick from asking simple questions of simple data.

You and others have been quite dogged in your denial of the obvious.

See news:M9Kva.312$0N3.67253409 (AT) mantis (DOT) golden.net for Albert's demonstration
that the same query asks two different questions depending on the underlying
physical structure. Alternatively:
http://groups.google.com/groups?q=g:...=&ie=UTF-8&sel
m=M9Kva.312%240N3.67253409%40mantis.golden.net


The notion is not absurd, but I can understand how someone whose intellect
is so damaged as yours might find all kinds of sensible things absurd. You
do not have to go searching. See the links above. However, I will not be
surprised if you again fail to profit from doing so.


The problem was you focussed on the discussion and not on your own cognitive
processes. Until you comprehend that "simplicity and ease" mean there is no
requirement for expert level skill and until you comprehend that "power"
means unconditional ability, any discussion in which you partake will lack
sanity.


See the link above to the thread where Albert proved 1. his "obvious"
proposed solution asked the wrong question, 2. pick changes the meaning of
queries in response to logically unrelated physical changes and 3. pick
lacks the ability to express simple questions using simple data structures.


Asking simple questions of simple data structures. See both links above.

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

[snip]

Oh bloody hell. Do I have to? I really don't care anymore that you are
deluded but, in order to stop you corrupting the minds of others...

Bob.
Let's take your first link:

Now. What don't you understand?

This is what you had to say:

===
"That looks simple enough for two salesmen who each sold two cars.
Will it
still look simple for a realistic dealership where each saleman has
sold
hundreds or even thousands of cars?

How easy will it be for users to keep the long lists of values
synchronized
when there are thousands of them? After all the 498th colour has to
match up
with the 498th car.

Remember, Albert is arguing for simplicity, ease and power. Devising a
complex, difficult physical layout to show that at least one physical
layout
will answer both questions hardly argues for simplicity and ease."
===

The first sentence is perfectly OK. The question that follows it was
answered in the thread. Did you understand the answer? The answer was
"yes". It will look
exactly the same. Except there will be more data.

How easy to keep the lists synchronised? Very. There are literally
thousands of applications out there running right now that have lists
of associated values - some with vast arrays of multivalues - and
there is no difficulty whatsoever.

Now we get your particular flavour emerging. (Distasteful isn't it
folks?) How the hell did you get from "that looks simple enough" to
that last paragraph? Whatever it was I missed in between the first
sentence and the last paragraph... well I just don't want to go there.
I reckon it's gotta be via a bitter and twisted mind. Where the f**k
is the "complex, difficult" bit?

[snip]

And so we move on...

This appears to be it. This is where you said:

===
"Ah, very good. So, the query you used..."

I've waded through Albert's Red and Blue car lot 'til I'm blue in the
face. Even Albert, possibly the most long-winded (and patient, bless
him) guy who ever contributed to comp.databases.pick, gave up on the
thread. Quite frankly, asking me to wade through all that s**t
again... well, it ain't gonna happen!

You obviously jumped to an incorrect conclusion. Describe the jump to
me. I know Pick and I know AQL. Now Bob, please o please don't post
another link. Give it to me straight. Tell me what Pick AQL can't do.
Describe a Pick file and tell me what I can't do with it. You could
even go back to the "attempt to restore sanity" thread and take the
file structure from there if you like. In fact, I'd rather like you to
do that. And by the way, there is still an unanswered question in that
thread. Albert seems to have moved on to discuss other things in other
newsgroups - and who can blame him? - so maybe you could answer it in
his absence. We all (the guys in comp.databases.pick) fail to see how
you ended up with such a warped view of Pick.

Mike.

"Mike Preece" <michael (AT) preece (DOT) net> wrote

Nothing. I understand everything said in that thread.


The person who answered lied--blatantly. It no longer looks quite so simple
when someone has to match up the 498th colour with the 498th car among lists
of thousands. Only the deluded would claim otherwise.


Tell that to the human being who is trying to figure out which two items
from a list of thousands are transposed or who is trying to match 1000
entries in one list with 1001 in another list. It ain't easy to do no matter
how often and how loudly the pick crowd proclaim otherwise. Only the deluded
will believe you.


"That looks simple enough for two salesmen who each sold two cars" is a far
cry from "that is simple enough period" and from "is simple". After all,
looks deceive--especially when examining trivial volumes of data. No doubt,
your inability to perceive the difference contributes to your profound
confusion.

The last paragraph you quoted above, which is far from the last paragraph in
the referenced post, speaks for itself. However, I notice you did not even
acknowledge the simple file structure I gave in the linked message that
clearly demonstrates the weaknesses of pick. Was the omission an intentional
and cynical attempt to mislead others? Or was it simply a symptom of your
delusion?

For the convenience of readers, I repeat the simple file structure here:

It was clear from all of the answers to the question above that it is
impossible to write a query to ask both questions in pick. Of course, anyone
who truly understands the limitations of aql and the problems inherent to mv
will recognize the inability without needing to see all the failed attempts
proposed by actual pick experts.

Asking both questions requires a programmer to write procedural instructions
describing step by step how to calculate the answer to at least one of the
questions. What's more, the procedural program offered was not a complete
solution thus requiring any user of the program to have sufficient knowledge
and understanding of the implementation of the algorithm to sort the input
data correctly for the program to function.


It was right in front of you in the part you denied and refused to accept.
Your denial leads you to delusion as denial always does.


And nobody needs to wade through anything to see the key points--I provided
links to them. I notice you do not really address anything from the linked
message and you had to cut the excerpt very short to eliminate the relevant
context:

Since single valued attributes always work and multivalued attributes do not
work, what should we conclude about the use of mv attributes? What's more,
the pick product changes the logical meaning of data and hence the meaning
of existing queries in response to unrelated physical changes, which is why
the following query asks (at least) two fundamentally different questions:

list <filename> Salesman
with color = "Red" and with color = "Blue"

A user must have expert level knowledge of the underlying physical structure
to reliably predict the meaning of the above query.

Does the query mean "Which salesmen sold a red and blue car?" or does it
mean "Which salesmen sold both a red car and a blue car?"

In the simple example I gave above and at the first link above, aql simply
cannot ask both questions--it can only ask one of the questions.


You obviously ignore the correct answers when they are right in front of
your face. Denial->delusion as I said earlier.


I repeat yet again the simple file structure here for the convenience of
readers so that you do not even need to page back up to where I repeated it
above. AQL cannot ask the two questions identified:

Pick AQL cannot express both of the questions above for the simple file
above.


Already done.


Oh good, this should be fun then. Are you hinting that after a month and a
half the entire community of expert pick practitioners has finally scratched
up an answer they think addresses the trivial challenge? Well, that should
certainly teach me how simple and easy pick is!


Since my view of Pick and specifically of mv attributes is not warped but is
entirely accurate, your failure is unremarkable.

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

You don't know anything about Pick - obviously. I presume you are
refering to the answer given by Mark Brown? You call him a liar? You
presume to know more about the subject under discussion than him? Do
you know who he is? Do you know what he's been doing these past
several years? You're talking drivel Bob. More than that - it's really
very offensive drivel.

use computers.

Oh I'm sick of this. You're an ignorant arsehole and I've wasted
enough time on you. Go to hell.
[remainder snipped]