Re: The Paradox of Choice

Marshall wrote:

> On Feb 7, 2:05 pm, Bob Badour <bbad..._at_pei.sympatico.ca> wrote:
>

>>Marshall wrote:
>>
>>>Vague thoughts:
>>>[...]
>>>It occurs to me that, while many of us here have no trouble mastering
>>>the SQL schema patterns for things like Master/Detail etc., these
>>>patterns are not immediately accessible to newbies, or to the vast
>>>hordes of dilettante programmers.
>>
>>Quite the contrary. I have known business analysts straight from school
>>who had no background in programming who picked up SQL syntax and
>>relational concepts like a breeze.

Absolutely. Learning and using a programming language affects the way one thinks. Dijkstra seldom if ever wrote anything for no reason at all. When he called the teaching of COBOL and Basic criminal offenses, he was not chattering idly or muttering senseless hyperbole.

> Question: were the analysts doing queries, updates and queries,
> or schema design, updates, and queries?

Some of everything but mostly queries. Due to the amount of data, the types of analyses, and the speed available at the time, the analysts sometimes needed to pull extracts into temporary tables, index the temporary tables and query against those. Plus the final analyses were done in SAS using PROC SQL.

  By and large the
> issue I'm describing has the most significance to schema
> design. It strikes me that it's easier (and requires less
> knowledge) to write a query against a well-designed
> schema than it is to orginate a well-designed schema.

Of course. Because the data originated from a good schema design, the analysts naturally chose good designs for their extracts (in immitation if for no other reason.)

>>What they had difficulty with was the
>>optimizer that arbitrarily chose to translate their perfectly good and
>>valid queries into nested table scans.
>>
>>Why should a dbms handle IN, OR and UNION differently in the first
>>place? (The analysts in question were fond of 'IN'.)

>>>I wonder: might it be possible
>>>to provide these folks some training wheels?
>>
>>How about predicate calculus?
>>
>>
>>>Might we come up
>>>with some approach that lets us encode patterns like master/detail
>>>or many-to-many so that they may be used directly? The idea being
>>>to have a facade over the unrestricted RM that provides the appearance
>>>of there being only one way to do things, to avoid scaring people
>>>with too many choices. I am thinking of some kind of macro system.
>>
>>How about a simpler syntax with less redundancy that SQL?

That's not exactly what I had in mind.

>>>I realize there is a good counter argument about the importance of
>>>mastering ones' tools if one wants to be a master. However, not
>>>everyone wants to be a master. And we should also acknowledge
>>>that there is something to be said for the programmer being able
>>>to focus on the application domain and not on the toolset domain.
>>>I have found that handicapped accessibility features are useful to
>>>me, even though I don't require them.
>>
>>>Thoughts?
>>
>>Good language design helps a lot.