Re: Dreaming About Redesigning SQL

alfredo_at_ncs.es (Alfredo Novoa) writes:

> pobrien_at_orbtech.com (Patrick K. O'Brien) wrote in message news:<m265ixf4fe.fsf_at_orbtech.com>...
> > lauri.pietarinen_at_atbusiness.com (Lauri Pietarinen) writes:
> >
> > Please allow me to take exception to a few of your points.
> >
> > > If you take a standard SQL-query with sorting and grouping and some
> > > joins and compare it with hand written "navigational" code you will
> > > notice that what can be expressed in SQL in 5-10 lines of code will
> > > require several pages of hand written code for equivalent result.
>
> > In general, I would agree that a declarative language is going
> > to be able to express an operation more concisely than a procedural or
> > object-oriented language. But a language like Python is very powerful
> > and expressive. I can do the equivalent of a simple SQL query in
> > about as many lines of code in Python using the PyPerSyst ODBMS.
>
> Python is a very low level language compared to SQL.

I've already made that point myself. What you are missing is that Python is also a very high level language compared to other imperative languages.

> Lauri was not talking about trivial queries like "select * from A"

Lauri made a blanket statement. I made a clarifying statement. I can think of lots of trivial examples of a "standard SQL-query with sorting and grouping and some joins." The "equivalent result" in Python would not "require several pages of hand written code." I stand by my original statement.

Of course, I'm only trying to clarify the issues, not win a war. I'm not sure what your goal is in these conversations. Perhaps you could help me understand where you are coming from, and why you feel the need to be so confrontational and aggressive.

> PyPerSyst is not a DBMS.

PyPerSyst is still in development, so I wouldn't say that it is a complete DBMS at the moment. But I think it has enough features to qualify. You can argue semantics all you want.

> > It would take an incredibly complex SQL query before I'd get to
> > "several pages of hand written code".
>
> It is completely false.

That's a useful statement. And your evidence to support this is what?

> > PyPerSyst itself is only several pages of hand written code. ;-)
>
> It is one of the reasons because it is ridiculous to compare it with
> an SQL DBMS like DB2 or Oracle. It is only a little toy which takes
> snapshots of main memory object networks in files.

It does quite a bit more than that. And the fact that it does it in so few lines of code is a testament to its design and to the expressive power of the Python language. I think it is foolish to judge the quality of software by the size of the code. More often than not, the smaller code base is better.

And, in any case, I'm not comparing PyPerSyst to DB2 or Oracle. There is plenty of room in the DBMS landscape for solutions of all sorts of sizes and shapes. Not every application would benefit from the use of DB2 or Oracle. The kinds of applications that I create work fine with PyPerSyst. My goal is to have the same integrity enforcement that you get with DB2 or Oracle. That's why I participate in these groups. What is your reason for participating?

> > > The third issue is that the SQL query can be optimised to a much
> > > higher degree than procedural code. Say you add a new index.
> > > The DBMS will/can immediately start using it without any user
> > > intervention (if it decides to). In the procedural alternative
> > > you would have to recode your query.
> >
> > You wouldn't necessarily *have to*. PyPerSyst does not yet have a
> > declarative query capability.
>
> One of the many reasons because it can not be considered seriously.

I'll be sure to put you on the announcement list when the declarative query feature is complete. In the mean time, please live up to your own statements and stop taking PyPerSyst so seriously. ;-)

> > But if you add an index, the same procedural code will now make
> > use of that index (or rather, the procedural code is calling
> > methods of objects that are smart enough to look for indexes to
> > optimize themselves without requiring any changes in application
> > code).
>
> It is something like XBase whith pointers. There is nothing to do with
> optimization.

You seem to have a very limited definition of optimization.

> > I only point this out becase critics of object databases really
> > need to improve their understanding of the capabilities of object
> > languages and object databases.
>
> You are an ignorant. You should educate yourself before trying to
> correct real experts like Lauri.

I'm not aware of Lauri's qualifications. I'm not sure how they are relevant. I'm sure Lauri can speak for herself. As for me, I'm humble enough to know that we are all ignorant to some degree. Thanks for reminding me. Have a nice day yourself.

> > > The optimiser can also take into account the cardinality of
> > > tables (=number of rows) so that it will produce a different
> > > plan for a small database and a big database.
> >
> > PyPerSyst doesn't do this, but it is completely within the realm
> > of possibilities.
>
> It is completely out of its possibilities. It does not have optimizer,
> nor plans, nor declarative query language, etc.

And it is completely out of the realm of possibility that I could add these things to PyPerSyst? Your proof is what? That I'm ignorant?

> > I hope you get the picture that every example you have given can be
> > true about procedural code. Here is a very simple example of the
> > source code for the "find" method of the PyPerSyst Extent class:
> >
> > def find(self, **criteria):
> > """Return list of instances exactly matching all criteria."""
> > instances = []
> > names = criteria.keys()
> > spec = self._makekeyspec(names)
> > if spec in self._altkeys:
> > # Use alternate keys as a shortcut.
> > key = self._makekey(criteria, spec)
> > d = self._altkeys[spec]
> > if key in d:
> > instance = d[key]
> > instances.append(instance)
> > else:
> > # Scan all instances for a match.
> > for instance in self._instances.values():
> > match = True
> > for name, value in criteria.items():
> > if getattr(instance, name) != value:
> > match = False
> > break
> > if match:
> > instances.append(instance)
> > return instances
> >
> > This find method returns a list of instances matching some criteria
> > supplied by the application code.
>
> You are very good discrediting your own product. That code is awful
> and shows many of the limitations of your stone age approach.

You really do amuse me, Alfredo. Nothing is ever good enough for you. Oh well, that's okay. Ignorance is bliss, after all. So I'll just keep plugging away. You'll keep attacking. I'll get stronger. PyPerSyst will get better. Next thing you know, I'll be taking over Oracle accounts. :-)

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