Re: Dreaming About Redesigning SQL

pobrien_at_orbtech.com (Patrick K. O'Brien) wrote in message news:<m2pth33gj6.fsf_at_orbtech.com>...

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

But decent database languages are not imperative. Python is a very inappropriate language for database management.

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

It is false. A simple SQL query with several joins, extensions and a summarize would be equivalent to several pages of error prone and tedious hand written code, and of course the oportunities for optimization are lost.

See the recent Seun's quote:

"This was as I say a revelation for me because Codd had a bunch of queries that were fairly complicated queries and since I'd been studying CODASYL, I could imagine how those queries would have been represented in CODASYL by programs that were five pages long that would navigate through this labyrinth of pointers and stuff. Codd would sort of write them down as one-liners."

http://www.mcjones.org/System_R/SQL_Reunion_95/sqlr95-Prehisto.html

The Relational Model was intended to solve the problems you want to reintroduce.

> Of course, I'm only trying to clarify the issues, not win a war.

But what you are doing is to pollute the group repeating pseudo-arguments debunked decades ago. Your war was lost in 1974 and you don't want to accept it.

> Perhaps you could
> help me understand where you are coming from, and why you feel the
> need to be so confrontational and aggressive.

It is very anoying to read the same fallacies again and again. You are not very different to other trolls like Neo, Carl and the new incorporations like Dawn.

> > PyPerSyst is not a DBMS.
>
> PyPerSyst is still in development, so I wouldn't say that it is a
> complete DBMS at the moment.

DBMSes are applications. DBMSes can be accesed by applications written in any language.

> But I think it has enough features to
> qualify.

The problem is that you are not qualified for discerning that.

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

All the evidence showed in the database literature you ignore.

For instance you might read the Relational Database Writings series.

Here is a little sample of what you are missing:

http://www.intelligententerprise.com/db_area/archives/1999/991105/online2.shtml

> I think it is foolish to
> judge the quality of software by the size of the code.

What it is foolish is to think that you can replace Oracle, DB2 or even Interbase with a few pages of code.

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

And there are plenty of SQL solutions like Interbase, Firebird, SAP DB, First SQL, Altibase, PostgreSQL, PervasiveSQL, SQL Server, etc, etc.

> My goal is to have the same integrity enforcement that you
> get with DB2 or Oracle.

Then you can't be more misleaded.

> What is your reason for participating?

I want to learn and to share (serious) thoughts with the very good experts of this group.  

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

I don't want to imagine what "declarative query feature" means for you.

> > It is something like XBase whith pointers. There is nothing to do with
> > optimization.
>
> You seem to have a very limited definition of optimization.

It seems exactly the contrary. Without a declarative database language there is not a lot of place for optimization. You have to hardcode all the navigation.

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

I am aware of his qualifications by the quality of his posts.

All of us are ignorant to many degree, but you are posting in comp.databases.theory without having a grasp on data management.

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

Yes, you can throw out PyPerSyst, to buid a RDBMS and to call it PyPerSyst, but it will not be the PyPerSyst we can see now.  

> You really do amuse me, Alfredo. Nothing is ever good enough for you.

There are some good things (in the data management field). See Dataphor for instance. What will not be ever good enough for me is the reinvention of stone age discredited and obsolete approaches (like pointer labyrinths), ignoring all the research done on the data management field in the last 40 years.

Regards
  Alfredo Received on Mon Oct 13 2003 - 14:30:22 CEST