Structured Query Language (SQL), most commonly thought of as the popular relational database query standard, is often touted as the preferred language for Event Stream Processing, and thence by connotation, Complex Event Processing.

There is an interesting correlation on this issue between the CEP technology industry and the Business Rule Engine technology industry of ~15 years ago. In the early ’90s there was a similar promotion of SQL, this time as how best to execute rules for business behavior: the alternative to SQL and triggers to represent business logic in a database was the in-memory “rule engine”. The case for SQL was:

- rule condition statements are queries over some data context: SQL was a standard query language and would be good for this
- rule behavior is made up of updates to data (or invocations of external processes): both are available in SQL
- rule invocation can be handled through DB triggers, based on the content of the condition expressions

However, this approach was not successful (in terms of the market) vs the in-memory approach which had:

- rule condition statements that were custom to general object models rather than relational models
- rule behavior were object-oriented: updates to objects and/or invocations of their methods (as well as external invocations as needed)
- rule invocation was via custom, efficient algorithms such as Rete, not a “re-use” of a query-optimized operational datastore engine

The end result? You have to search far and wide to find a “business rule” vendor using SQL and database engines for rule execution, and even Oracle, the 30,000 lb gorilla of database companies, has licensed an in-memory engine for their customer use.
Of course, there is nothing wrong with re-using parts of the SQL syntax for event stream processing, and few ESP vendors would claim to be based on someone else’s common-or-garden database engine. SQL is by far the most common and mature query language available, although I am not sure that database programmers are the best candidate developers for ESP and CEP applications. When you consider that SQL is designed for data-oriented (as opposed to event driven) systems, against relational information structures (as opposed to event streams or clouds), perhaps using the term “SQL-based” is mainly “marketing” to try and imply some level of technical maturity?

Plus there is of course the issue that ESP is “subtly different” (or maybe “somewhat different”) than CEP: this does not make ESP (or SQL) any less useful of course, but there is a difference… and there are not (as far as I know) any SQL-based rule-driven CEP engines…

No Comments

No comments yet.

RSS feed for comments on this post. TrackBack URI

Leave a comment