Application Model

To better understand how a SQLstream application is structured, it is helpful to contrast it with the familiar model of a database application.

Conventional database applications generally follow this model:

  • A procedural programming or scripting language (e.g., Java, C++, Perl, PHP) has control.
  • SQL is embedded (using JDBC, ODBC, SQLJ, or other technique) for database access.
  • The application executes record-by-record processing of inputs and results.

A SQLstream application has several key differences:

  • SQL has control.
  • A programming language (such as Java or C++) is embedded (using - UDF*/ - UDX*) for complex calculations or specialized system connectivity.
  • The application creates a processing pipeline or network using adapters, streams, and views to process set-based inputs and results.

SQLstream applications are characterized by continuous processing, with pipelined architectures in which each processing step serves both as an inspection/debug point and as a source of intermediate data to be repurposed or redirected to output files or other systems.

SQLstream inherits many of the benefits of relational database design:

  • A focus on metadata
  • Schemas and catalogs to partition applications, allowing many to coexist on the same server
  • Security and declarative access control
  • Views as a form of data abstraction, so that you can change applications one at a time
  • Data independence, that is, logical/physical separation, allowing you to write your application and tune it without breaking it. (See https://en.wikipedia.org/wiki/Data_independence for more discussion of this concept.)

To summarize, we can say that a SQLstream application is constructed declaratively, using SQL to define required outcomes for sets of data, rather than being constructed procedurally, defining each step for each record.

See also the topic Application Design Considerations in this guide.