Relational and non-relational engines

Is Progress OpenEdge a Relational Database Management System (RDBMS)? Professionals ask this question many times. OpenEdge has 2 engines – ABL and SQL. ABL engine is not relational. SQL engine is relational. So, let’s begin to understand why it is difficult to answer this question right away.

Relational Database

Different sites describe relational databases differently.

One property of a relational database engine is its ability to manage and protect relationships such as a parent-child relationship. An OrderHeader table with a corresponding OrderLineDetails table is an example of parent-child relationship. OrderLineDetails allows detail when parent order has is present.

Another property defining relationship is check constraints. For example, gender column’s check constraint ensures that users enter either Male or Female. Therefore, users confidence of entering data will increase.

So, can OpenEdge do relationships?

Yes, OpenEdge supports foreign key constraints and check constraints with SQL. While OpenEdge is relational, ABL’s model is different. ABL will not obey foreign key constraints set by SQL’s parent-child relationship. Using ABL, you can enter an order line item when no parent order exists – despite the existence of an active foreign-key constraint. This behavior is not in error; ABL is working as designed.

With ABL one can write code to prevent order line from being written when order is not present. It’s upon the developers to correctly set up application layer to cater for parent-child relationships.

On the other hand, SQL will be very respectful of parent-child relationship. An attempt to enter order line will error out if order header is not present. SQL is also very respectful of check constraints.

Should I use only SQL to build robust applications?

It depends. SQL will promote the building of DB and application level safety.However, with ABL you will have to build the safety-net yourself. You can write ABL code to apply application-level constraints. It is likely that your legacy code in ABL will have to be re-written to build higher safety into your applications. If you have a team that’s already SQL-centric and your ABL developers are open-minded about SQL, try out SQL for a few projects.

So, if you are starting a new project with SQL-centric team and ABL team that will work with you, give SQL a try. If you are building upon existing ABL application, just build robustness in ABL as much as you can. Long-time Progress users will lean towards ABL. My background is SQL-centric and I’ve been quite successful at using SQL with Progress OpenEdge. So, I lean towards SQL. My appreciation for ABL remains high despite my leaning towards SQL for new application development.