Re: Pizza Example

In message <4Zcic.11391$Jr5.8164_at_newssvr31.news.prodigy.com>, Eric Kaun <ekaun_at_yahoo.com> writes
>"Anthony W. Youngman" <wol_at_thewolery.demon.co.uk> wrote in message
>news:irwPxZDNZwhAFwVT_at_thewolery.demon.co.uk...
>> As I understand it (I may well be wrong), most queries in a relational
>> database are complicated/difficult because of joins.
>
>Joins don't make things difficult, in general. In SQL they're far more
>convoluted than in a general relational algebra, but given the procedural
>code I've seen even in Java, complexity isn't the issue. I think programmers
>are just indoctrinated in procedural methods, rather than declarative ones.
>
>> Viewed from a Pick
>> mindset, the typical reaction is "what do you want a join for?". Pick
>> doesn't have joins in the relational sense because it just doesn't make
>> sense in the Pick world-view.
>
>Sure it does. You never have the need to query for information that crosses
>over several files? You're doing a join - you're just doing it laboriously
>and procedurally.

Normally, it's just used to transform an enum into its description...

The fact that pick stores n-dimensional data means that most of the time joins are unnecessary. And while it may seem laborious, the implementation is extremely efficient.
>
>> A bit like the Feynman story about calculus - Dick was taught an unusual
>> technique and all his colleagues thought he was calculus genius. But as
>> he said, they gave him all the problems they thought difficult, and with
>> his different toolset he solved them easily. But if they'd given him the
>> problems they thought easy, he would have been stumped.
>
>Possibly, but we're not talking about individual problem solving, at least
>not all the time. We're talking about information structures for a business.
>And if you have multiple data models, you're going to have mapping problems,
>probably severe ones. At some point the business has to (or should!) define
>what it means by its data, and it's better to do that in one way, unless you
>can very carefully identify non-overlapping domains which have a need for
>different paradigms. I've never seen such a thing, but that doesn't mean the
>black swan doesn't exist.

Nor was I. I was just saying that Dick's colleagues thought he was amazing when all it was was that he had a different toolkit. Same here - what Pick finds easy SQL may find hard, and vice versa.
>
>> As for the difficult queries, with its different toolkit, would Pick
>> think them difficult? If you could give me an example of a "difficult"
>> query, I would be able to comment. Being a text-based system, Pick
>> *ought* to be a good match.
>
>How does being text-based help that?

Well if your data is text, and your db "thinks" in terms of text, then surely that makes things simpler than if your database "thinks" in terms of something else (abstracts, or numbers, or "you don't need to know that"s).
>
>Anyway, certainly you have cases where you need to combine information from
>several files. How do you do it?

Virtual fields - "here's the table, here's the primary key, get that field for me".
>
>> I got the source of wikipedia on a cover disk this month :-) so I may
>> well take a look at it. Only snag is, "I don't do Perl", which is I
>> believe the language it's written in. But I ought to look at stuff like
>> that :-)
>
>Perl is heinous, or at least (like C++) tacitly encourages heinous
>practices. It can do a lot, but well, so can assembler.

:-)
>
>- erk
>

Cheers,
Wol

-- 
Anthony W. Youngman - wol at thewolery dot demon dot co dot uk
HEX wondered how much he should tell the Wizards. He felt it would not be a
good idea to burden them with too much input. Hex always thought of his reports
as Lies-to-People.
The Science of Discworld : (c) Terry Pratchett 1999