Re: Dreaming About Redesigning SQL

"Mikito Harakiri" <[EMAIL PROTECTED]> writes:

> "Patrick K. O'Brien" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
> > I can also think of report requirement changes that would trigger
> > small changes in the procedural code, and larger changes in the
> > SQL.
> 
> For one thing, I cannot. Could you please support your idea?

Sure.  The problem with the previous examples are that I had to mimic
the SQL query that was given.  To do that, I created a function that
returned certain attributes that were taken out of the objects to
which they were associated.  The result was a list of values with no
context, no object capabilities.  That's not what I would do in a
typical application using PyPerSyst.  Instead, I would return the
actual class instances.  These instances would have attributes and
behavior.  I could add an attribute, or change the instances behavior,
and not have to change the "query" that returned these instances.  The
application code could then make use of the new attribute.  In SQL,
unless I was able to use a "SELECT *," I would have to change the SQL.

In some cases I wouldn't even need to change anything other than the
application code.  Let's say I had a report listing all the orders and
order details.  Let's say I now wanted the customer's city to appear.
In SQL, I would have to add the customer table as a join in order to
select the city.  In PyPerSyst, I would simply add code in the report
to display orderdetail.order.customer.city without changing the query
that returned the list of OrderDetail instances.  To get the same
thing in SQL, I would have to select a lot of columns to ensure I had
everything a report could possibly need.  But that adds overhead
because all of that data is extracted from the database.  In
PyPerSyst, the links between instances are Python references, which
have minimal overhead.  If I never access customer attributes in my
report, it doesn't matter how big a customer instance is, because the
reference never gets resolved.

> > I think your emphasis on "huge changes to your procedural code" is
> > a gross exaggeration.  I know you said "may result in", but you
> > are still exaggerating.  It isn't necessary.
> 
> In the requirement change that Lauri posted, you have to make
> customer as a leading table when c.city = 'London' predicate becomes
> very selective. Or, wait a minute, should it be driven from
> p.prodgroup = 'Screws'? Not only this, but you'll have to introduce
> a key for p.prodgroup, and change nested loop scanning the table
> into associative key lookup. What if there are 2 predicates on a
> single table, how would you accomodate bitmap join index?  What if
> Lauri, while continuing making fan, adds 'or' predicates?

I think there is much that can be done to handle these situations
short of a completely declarative language with an optimizer.  Perhaps
we should just agree to disagree.

> > I think over time Relational implementations (various flavors of
> > SQL) have lost some of the clear advantages they had over
> > languages like COBOL and systems like CODASYL.  In 1974 we didn't
> > have Python, Java, C#, etc.  I'm not saying Relational
> > implementations have no advantage over modern languages and
> > alternative database technologies.  I simply take issue when
> > Relational advocates make blanket statements about other
> > technologies (OO and ODBMS) that are not true, or were once true
> > but no longer are true.
> 
> Yet again, from relational perspective, Java is no different from
> COBOL.  Those little handy improvements (garbage collection,
> exception handling, encapsulation, polymorphism, etc) aren't
> changing the fundamental imperative nature of the language. You
> still have state, assignment, and painfully specify instuctions
> step-by-step. This is light years away from relational.

A light year is a long way.  I happen to prefer Python over Java.  I
think most people would concede that you can accomplish the same
things in Python with half as much code as Java (often much less than
that).  So perhaps Python is only (light years) / 2 away from
relational.  ;-)

-- 
Patrick K. O'Brien
Orbtech      http://www.orbtech.com/web/pobrien
-----------------------------------------------
"Your source for Python programming expertise."
-----------------------------------------------