Tag: ORM

Programmers have been trying to use the ORM technique to convert SQL statements between different types of databases. The issue is that the technique is only suitable for translating simple SQL statements in OLTP scenarios. Complicated SQL statements in OLAP cases are still hard to migrate. esProc SPL, however, (Structured Process Language) supports a wealth of functions to be able to describe various algorithms and thus handle a rich variety of computing scenarios.

Business logic consists of database read & write, structured data computation, and procedural control. The first two parts are what SQL was designed for and thus easy to handle. But SQL lacks procedural control statements (loop and judgement), it cannot achieve the whole business logic on its own. In order to address this issue, database vendors invented a new language based on SQL and procedural control statements. That is stored procedure. The stored procedure has more complete functionalities to achieve business logics independently The language combines SQL and procedural control statements. Their cooperation gives the stored procedure complete functionalities to

Business logic usually involves complicated procedures and computations and database writing and reading. Stored procedures are not suitable for handling many scenarios due to various reasons, including complex privilege granting, potential security risks, code un-migratability, high technological threshold, programming difficulty, and so on. Being not good at handling complex procedures, SQL is not fit for implementing business logic alone. It has to work with a high-level language like Java to get the job done. Yet, SQL and high-level languages have disparate syntax styles and data structures. Their cooperation is hard, and development efficiency has been low. In view of this,