esProc Isn’t Compatible with SQL

An often-asked question is whether esProc will offer SQL-compatible syntax.

SQL has a huge number of users. Some say if esProc supports SQL and can enhance performance at the same time, they can directly migrate the SQL code and write a program in the familiar language. That sounds tempting.

But it is unfeasible!

esProc can’t implement relational algebra-based SQL. SQL’s difficulty in trying to achieve high-efficiency development and execution is rooted in the theory itself. We can’t solve a theoretical problem through non-theoretical optimization. To achieve high efficiency means to abandon the outdated theory.

Others suggest that we use esProc inner core to interpret SQL. It is theoretically feasible, because either interpretation or migration isn’t very difficult though a lot of workload will be involved. But, this can only lead to syntax compatibility but not high performance. Efficient code is produced according to the characters of a specific type of computation. As SQL syntax can’t express certain characters, we still need to perform a series of optimizations after a direct migration but can’t get the optimal solution. Actually it is hardly possible to interpret and migrate code between two SQL-based database products without compromising performance.

Furthermore, SQL compatibility isn’t necessary. Many programmers have the false impression that SQL is easier to learn. Indeed, SQL is simple to use when handling some basic queries. The easy-to-understand, English-like style also contributes the false impression. The truth is SQL is good at producing extremely lengthy and complicated code, often about three or five hundreds of lines, or even thousands of lines, for one statement when dealing with time-consuming queries and the procedural computations that esProc tries to tackle. It is difficult to understand and maintain, and becomes unintelligible after a time for the programmers themselves. The simple SQL statements of three or five lines only exist in training classes and text books. In realities, complicated SQL programs are measured by K instead of lines.

Seems it isn’t wise to use SQL to handle those computations since SQL is difficult to write and the performance is poor. The smart move is turning to esProc to witness a sweeping efficiency enhancement.

Yet undoubtedly, SQL is convenient in handling simple computations. That is why esProc provides simple SQL compatibility. The simple SQL syntax is non-nested and non-procedural. The syntax is not necessary for handling database data but will be useful in handling non-database data that is beyond the SQL database’s reach. In that case, esProc can leverage its simple SQL compatibility to perform simple SQL queries over the non-database data.