Re: The Paradox of Choice

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.

Ha! Then maybe what I'm picking up on is a difficulty that is specific to people with previous programming experience!

Question: were the analysts doing queries, updates and queries, or schema design, updates, and queries? 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.

> 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'.)

Sure.

> > 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?

For sure! All hail the Tropashko Algebra!

> > 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.

+1.

Marshall Received on Thu Feb 08 2007 - 00:55:15 CET