Benefits of Schemas

Benefits of the schema architecture described above include the following:

• Abstraction of user code (on client and middle tier) from actual data access.
• All user code is database agnostic.
• Data access and updates can be handled completely by the library.
• No SQL code needs to be written and maintained (unless you want to).
• Application can be changed to use different back-end database types without code changes.
• Application can be adapted to database changes by only adjusting the schema.
• Easy access to different database systems from the same code base.
• RAD Schema Modeler™ application for designing and maintaining schemas.

Let's explore some of these points in more detail:

Abstraction of User Code from Data Access

As already outlined above, in a typical Data Abstract application, all code is written to talk to the data tables as defined in the schema. The code does not need to know what database system is used on the back-end, how to generate SQL code to talk to that database, or what data access components are needed.

Compare this to ADO.NET, where components need to be dropped that are specific to – say – SQL Server and contain (whether hand written or wizard generated) SQL strings. If you later want to target an Oracle backend instead of (or in addition to) SQL Server, none of these can be reused. Similar concepts apply to DataSnap or other third party solutions on the Delphi side.

In contrast, Data Abstract middle-tier code does not need to care (and in most cases will not even know) what type of database it is talking to and what low level data access components or providers might be involved in the actual communication with the database. If user code is involved at all (and in many cases there is no need for that), it uses classes provided by the Data Abstract library that abstract this away.

All User Code is Database Agnostic

Because a Data Abstract middle tier does not know or care about these things, the same application can run against any variety of data base systems, with only making minimal (if any) adjustments in the schema. In many cases, simply defining a new connection string will suffice to target a different database type.

Data Access is Handled by the Library, No SQL Code Needs to Be Written

The Data Abstract library handles all retrieval and updates of data. Because the schema contains all information that maps the data tables to the underlying database, Data Abstract can generate the necessary SELECT, INSERT, UPDATE and DELETE SQL statements on the fly whenever it needs to fetch data or update it.

The library (or the individual database drivers) know about varying SQL dialects and can, where needed, generate different SQL based on the database type. It can also account for field or table names that might differ between back end and schema.

Of course this does not mean that a Data Abstract middle tier must rely on auto-generated SQL code. Schemas can contain customized or fine-tuned SQL for data retrieval and updates, and they provide flexible options for providing different custom SQL code for different databases, where needed.

Applications Can be Changed to Use Different Back-End Database Types

For these same reasons, Data Abstract makes it very easy to switch database types on the fly. Because none of the code written is tied to or knows about one particular database type, but uses the abstracted data tables from the schema, changing database vendors can be as easy as defining a new connection string or – in more complex scenarios – making some additional adjustments in the schema to account for differences in the databases.

No user code needs to be changed, unless it explicitly and purposely contained database-vendor specific code.

Applications Can be Adapted to Database Changes

Because schemas provide an abstraction layer on top of the structure of the physical database, applications can easily be adjusted to database changes by merely adjusting mappings in the schema. For example, simple changes such as the renaming of a field or table can be applied in the schema – the application code never has to change to use the new names; the application will work as it is.

This can not only save work for updating the application code, but can also relieve the need to deploy new client applications to all users for these changes.

Access to Different Database Systems from the Same Code Base

Even more powerful than the idea of easily switching between database types (or structures) is the concept of using the same code base to talk to different databases simultaneously. Because Schemas can have explicit support for different connections and mappings at the same time, a schema can be designed so that the same application can be deployed against different databases, without even recompiling. One customer might run your middle-tier server against Oracle, while another uses DB2 or Microsoft SQL Server.

It is also possible to support more than one back-end database in a single running server instance – one client might be working on data from one database, while another accesses a second database of different type or structure.

This also makes it very easy to migrate up from legacy databases; a middle-tier server might be written to talk to an old CRM database that is in production, while the database administrator is migrating data to a new, better structured, database. End-users could access both the old and new database until the migration is complete.

Schema Modeler for Designing Schemas

Because schemas are such an important pillar of the Data Abstract architecture, the Schema Modeler application is provided to allow developers or database architects to define and design schemas in a RAD way that is intuitive to use.

Schema Modeler integrates deeply with the supported IDEs, but can also be used stand-alone by non-developers. It is available for Windows and Mac. More details about Schema Modeler can be found in the Documentation, here.