Re: Dreaming About Redesigning SQL

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.

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

PyPerSyst is not a DBMS.

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

It is completely false.

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

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

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

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

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

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

> I have also tried to find
> information about the weaknesses of the network model and have not
> found much of value.

Where did you tried?

There is plenty of information on any universitary level database textbook.

<remaining nonsenses snipped>

Regards
  Alfredo Received on Sat Oct 11 2003 - 17:17:21 CEST