Why are DataBlades so important, as opposed to building application logic separate from the database?
Though at first glance it appears that DataBlades and application logic operate similarly, DataBlades are not “application logic.”
When I speak of “application logic” I mean statements such as
“select a from b where conditionsThis type of code is written into your application and determines the functionality and features of the application. Triggers and stored procedures, written with a special language structure called “Stored Procedure Language” (SPL), can be used to enhance and/or standardize processing functions within these applications. While triggers and stored procedures are stored within a database, they are not to be considered a DataBlade. Nor should a DataBlade be considered a stored procedure.
if not found thendo somethingelsedo something else with aend if”
A DataBlade is a separate application used by the Informix Universal Server or the Illustra Server engine to provide additional data elements, or to manipulate data elements, that cannot be done easily using traditional application languages. Think of them as massive and sophisticated shared libraries such as those used in the C and C++ languages. An application can use the functionality provided by the DataBlade to manipulate image data for example, much like a C program uses the appropriate library to output text via the “printf” command. That is as close as DataBlades come to being actual “application logic.”
I must admit that my experience with DataBlades is limited to the Web Blade. My understanding, though, is that Blades you purchase from Informix or a third-party vendor are read-only, so you cannot embed application-specific logic into them like you can with a stored procedure. You can create your own Blades using the Informix DataBlade Developers Toolkit and imbed general application rules that would be appropriate for your enterprise, but I think it would be much faster and easier to maintain, if you used stored procedures instead.